cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From stef...@locus.apache.org
Subject cvs commit: xml-cocoon/xdocs guide.xml infrastructure.xml technologies.xml
Date Tue, 18 Apr 2000 12:53:35 GMT
stefano     00/04/18 05:53:35

  Modified:    xdocs    guide.xml infrastructure.xml technologies.xml
  Log:
  typos and mistakes fixes
  
  Revision  Changes    Path
  1.2       +5 -5      xml-cocoon/xdocs/guide.xml
  
  Index: guide.xml
  ===================================================================
  RCS file: /home/cvs/xml-cocoon/xdocs/guide.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- guide.xml	2000/01/27 03:46:03	1.1
  +++ guide.xml	2000/04/18 12:53:33	1.2
  @@ -253,7 +253,7 @@
        handles the requested URI and produces an
        XML document. Since producers are pluggable, they work like subservlets
        for this framework, allowing users to define and implement their own
  -     producers. A producer is responsible of creating the XML document which is
  +     producers. A producer is responsible for creating the XML document which is
        fed into the processing reactor. It's up to the producer implementation to
        define the function that produces the document from the request object.
      </dd>
  @@ -262,9 +262,9 @@
        is responsible of evaluating what
        processor should work on the document by reacting on XML processing
        instructions. The reactor pattern is different from a processing pipeline
  -     since it allows the processing path to the dynamically configurable and it
  +     since it allows the processing path to be dynamically configurable and it
        increases performance since only those required processors are called to
  -     handle the document. The reactor is also responsible to forward the
  +     handle the document. The reactor is also responsible for forwarding the
        document to the appropriate formatter.
      </dd>
      <dt>Formatter</dt>
  @@ -282,13 +282,13 @@
      </dd>
      <dt>Loader</dt>
      <dd>
  -     is responsible of loading the formatted
  +     is responsible for loading the formatted
        document when this is executable code. This part is used for compiled
        server pages where the separation of content and logic is merged and
        compiled into a Producer. When the formatter output is executable code, it
        is not sent back to the client directly, but it gets loaded and executed
        as a document producer. This guarantees both performance improvement
  -     (since the producer are cached) as well as easier producer development,
  +     (since the producers are cached) as well as easier producer development,
        following the common compiled server pages model.
      </dd>
     </dl>
  
  
  
  1.2       +2 -2      xml-cocoon/xdocs/infrastructure.xml
  
  Index: infrastructure.xml
  ===================================================================
  RCS file: /home/cvs/xml-cocoon/xdocs/infrastructure.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- infrastructure.xml	2000/02/09 21:11:36	1.1
  +++ infrastructure.xml	2000/04/18 12:53:34	1.2
  @@ -153,11 +153,11 @@
   which other components are called. Whether COM, CORBA, Java or any
   other language is actually called becomes transparent to the user. The
   user only needs to know about the XML API which, by definition, should
  -thrive to be human readable. This makes debugging and maintenance a
  +strive to be human readable. This makes debugging and maintenance a
   lot easier.</p>
   
   <p>This approach to dynamic content generation is quite different from
  -other methods. The typical method prone by SUN and Microsoft is to
  +other methods. The typical method proposed by SUN and Microsoft is to
   generate and XML output from a servlet or ASP page, then process it
   with an XSLT processor. Some of the drawbacks of that method are:</p>
   
  
  
  
  1.2       +5 -13     xml-cocoon/xdocs/technologies.xml
  
  Index: technologies.xml
  ===================================================================
  RCS file: /home/cvs/xml-cocoon/xdocs/technologies.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- technologies.xml	2000/01/27 03:46:03	1.1
  +++ technologies.xml	2000/04/18 12:53:34	1.2
  @@ -337,19 +337,11 @@
     goes further and defines a way of separating content and style from
     the programming logic that drives server side behavior.</p>
   
  -  <p>The XSP language (<connect href="WD-xsp.xml">eXtensible Server
  -  Pages</connect>) defines an XML DTD for separating content and logic
  -  for compiled server pages.  
  -
  -  <!-- FIXME (RAW): I'm finding this sentence hard to parse and, since
  -       I don't yet myself have a handle on what exactly is "source"
  -       and "binary" in this context, I couldn't reformulate it
  -       effectively. -->
  -
  -  XSP is, like XSLFO, supposed to be a <em>final DTD</em>, in that it
  -  is the result of one or more transformation steps and must be
  -  rendered by some formatter into pure source code which can then be
  -  compiled into binary code.</p>
  +  <p>The XSP language defines an XML DTD for separating content and logic
  +  for compiled server pages. XSP is, like XSLFO, supposed to be a 
  +  <em>final DTD</em>. In fact, XSP is rendered into source code and then
  +  compiled into binary code. This allows performance increase since no
  +  parsing or interpretation overhead happens at runtime.</p>
   
     <p>In dynamic content generation technology, content and logic are
     combined: in every page there is a mix of static content and dynamic
  
  
  

Mime
View raw message