stefano 00/08/16 08:30:32
Modified: xdocs cocoon2.xml docs-book.xml fptaglib.xml
site-book.xml
xdocs/dtd document-v10.dtd
Log:
docs improvements
Revision Changes Path
1.6 +20 -76 xml-cocoon/xdocs/cocoon2.xml
Index: cocoon2.xml
===================================================================
RCS file: /home/cvs/xml-cocoon/xdocs/cocoon2.xml,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- cocoon2.xml 2000/04/27 17:55:15 1.5
+++ cocoon2.xml 2000/08/16 15:30:28 1.6
@@ -61,18 +61,18 @@
careful memory use and tuning of internal components is a key issue. To
reach
this goal, an improved API model was needed. This is now identified in the
SAX
API which is, unlike DOM, event based (so <em>active</em>, in the sense
that its
- design is based the <em>inversion of control</em> principle).</p>
+ design is based on the <em>inversion of control</em> principle).</p>
- <p>The event model allows document producers to trigger producing
- events that get handled in the various processing stages and get finally
- formatted in the response stream. This has significant impacts on
performance
- and memory needs:</p>
+ <p>The event model allows document generators to trigger events that get
handled
+ by the various processing stages and get finally
+ serialized onto the response stream. This has a significant impact on both
+ performance (effective and user perceived) and memory needs:</p>
<dl>
<dt>incremental operation</dt>
<dd>
- the response is created
- during document production. Client's perceived performance is
dramatically
+ the response is created during document production.
+ Client's perceived performance is dramatically
improved since clients can start receiving data as soon as it is
created,
not after all processing stages have been performed. In those cases
where
incremental operation is not possible (for example, element sorting),
@@ -96,9 +96,9 @@
</dd>
<dt>more optimizable code model</dt>
<dd>
- modern virtual
- machines are based on the idea of <em>hot spots</em>, code fragments
that
- are used often and, if optimized, increase the process execution by
far.
+ modern virtual machines are based on the idea of <em>hot spots</em>,
+ code fragments that are used often and, if optimized, increase the
process
+ execution by far.
This new event model allows easier detection of hot spots since it's a
method driven operation, rather than a memory driven one. Hot methods
can
be identified earlier and their optimization performed better.
@@ -235,16 +235,16 @@
that is normally much less than its size.</p>
<p>Also, for performance reasons, Cocoon2 will try to compile
- everything that is possibly compilable (pages/XSP into producers,
stylesheets
- into processors, etc...) so, in this new model, the <em>processing
chain</em>
+ everything that is possibly compilable (pages/XSP into generators,
stylesheets
+ into transformers, etc...) so, in this new model, the <em>processing
chain</em>
that generates the page contains (in a direct executable form) all the
information/logic that handles the requested resource to generate its
response.</p>
<p>This means that instead of using even-driven request-time DTD
interpretation (done in all Cocoon1 processors), these will be either
compiled
- into processors directly (XSLT stylesheet compilation) or compiled into
- producers using logicsheets and XSP which will remove totally the need for
+ into transformers directly (XSLT stylesheet compilation) or compiled into
+ generators using logicsheets and XSP which will remove totally the need for
request-time interpretation solutions like DCP that will be removed.</p>
<note>Some of these features are already present in latest Cocoon 1.x
@@ -258,74 +258,18 @@
URI to the proper response-producing pipeline.</p>
<p>The sitemap physically represents the central repository for web site
- administration, where the URI space and its handling is maintained. An
example
- of the sitemap is given below:</p>
+ administration, where the URI space and its handling is maintained.</p>
+
+ <p>Please, refer to the Cocoon2 CVS module for more information on
this.</p>
-<source>
-<![CDATA[
- <sitemap>
- <process match="/press/en/*.html">
- <generator type="file" src="/docs/english/press/*.xml"/>
- <filter type="xslt">
- <parameter name="stylesheet" value="/styles/simple-press-html.xsl"/>
- </filter>
- <serializer type="html"/>
- </process>
-
- <process match="/press/en/*.pdf">
- <generator type="file" src="/docs/english/press/*.xml"/>
- <filter type="xslt">
- <parameter name="stylesheet" value="/styles/simple-press-pdf.xsl"/>
- </filter>
- <serializer type="pdf"/>
- </process>
-
- <process match="/">
- <matcher type="agent">
- <parameter name="name" value="Mozilla/5.0">
- </matcher>
- <generator type="file" src="/docs/root.xml"/>
- <filter type="xslt">
- <parameter name="stylesheet" value="/styles/fancy-XUL-view.xsl"/>
- </filter>
- <serializer type="html"/>
- </process>
-
- <process match="/">
- <matcher type="agent">
- <parameter name="capability" value="text/vnd.wap.wml">
- </matcher>
- <generator type="file" src="/docs/root.xml"/>
- <filter type="xslt">
- <parameter name="stylesheet" value="/styles/WAP-view.xsl"/>
- </filter>
- <serializer type="wap"/>
- </process>
-
- <process match="/">
- <generator type="file" src="/docs/root.xml"/>
- <filter type="xslt">
- <parameter name="stylesheet" value="/styles/normal-view.xsl"/>
- </filter>
- <serializer type="html"/>
- </process>
- </sitemap>
-]]>
-</source>
-
- <note>The sitemap DTD has not yet been standardized and it's not guaranteed
- to solidify until Cocoon 2.0 is out final. So, the above should be
considered
- just as a preview and not a specification or even a working draft. For more
- information dig into the development mail list digests.</note>
-
</s1>
<s1 title="Pre-compilation, Pre-generation and Caching">
- <p>The cache system in Cocoon1 will be ported with no important
+ <p>The cache system in Cocoon1 will be ported with very little
design changes since it's very flexible and was not polluted by early
design
constraints since it appeared in later versions. The issue regards static
file
caching that, no matter what, will always be slower than direct web server
- caching.</p>
+ caching, so Cocoon2 will be the most <em>proxy friendly</em> as
possible.</p>
<p>To be able to put most of the static part job back on the web
server (where it belongs), Cocoon2 will greatly improve it's command line
@@ -351,7 +295,7 @@
</s1>
<s1 title="Development Status">
- <p>Cocoon2 development already started, but should be considered of
pre-alpha
+ <p>Cocoon2 development already started, but should be considered of alpha
quality. If you dare, you might take a look at it on the
<em>xml-cocoon2</em>
CVS branch in the Cocoon CVS module, or, if you are not a CVS expert, this
means
typing:</p>
1.11 +5 -2 xml-cocoon/xdocs/docs-book.xml
Index: docs-book.xml
===================================================================
RCS file: /home/cvs/xml-cocoon/xdocs/docs-book.xml,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- docs-book.xml 2000/07/11 04:42:15 1.10
+++ docs-book.xml 2000/08/16 15:30:28 1.11
@@ -3,8 +3,10 @@
<book software="Cocoon" title="Cocoon documentation" copyright="@year@ The
Apache Software Foundation">
<page id="index" label="Index" source="index.xml"/>
<page id="license" label="License" source="license.xml"/>
+<separator/>
<page id="install" label="Install" source="installing.xml"/>
- <page id="install-case" label="Install Case"
source="installation-case.xml"/>
+ <page id="install-case-solaris" label="Install on Solaris8"
source="installation-case-solaris-8.xml"/>
+ <page id="install-case-windows" label="Install on Win2k"
source="installation-case-windows-2000.xml"/>
<separator/>
<page id="technologies" label="Technologies" source="technologies.xml"/>
<page id="infrastructure" label="Infrastructure"
source="infrastructure.xml"/>
@@ -12,7 +14,8 @@
<page id="dynamic" label="Dynamic Content" source="dynamic.xml"/>
<separator/>
<page id="xsp" label="XSP Processor" source="xspprocessor.xml"/>
- <page id="sqltaglib" label="SQL Logicsheet" source="sqltaglib.xml"/>
+ <page id="sqltaglib" label="SQL XSP Taglib" source="sqltaglib.xml"/>
+ <page id="fp" label="FP XSP Taglib" source="fptaglib.xml"/>
<page id="connection-pool" label="SQL Conn Pool"
source="connection-pool.xml"/>
<page id="sql" label="SQL Processor" source="sqlprocessor.xml"/>
<page id="ldap" label="LDAP Processor" source="ldapprocessor.xml"/>
1.2 +1 -1 xml-cocoon/xdocs/fptaglib.xml
Index: fptaglib.xml
===================================================================
RCS file: /home/cvs/xml-cocoon/xdocs/fptaglib.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- fptaglib.xml 2000/07/25 20:52:07 1.1
+++ fptaglib.xml 2000/08/16 15:30:28 1.2
@@ -172,7 +172,7 @@
<p>I create a <code>label</code> attribute in the
<code>input</code> element, using XSP, but the content comes from reading Text
from the defaults file (I would have had to set this file up previously as a
<code>fp:resource</code>). The default value for the <code>as</code> attribute
is "string", so I am leaving it out. I understand Xerces prefers you to write
attributes before elements.</p>
<p>Next I write, only if someone is POSTing a Form.</p>
<p>Write the contents of the <code>fp:write</code> element, in
this case the value of the POSTed Form field called "title" (this one), to the
<code>title</code> Node of our selected <code>item</code> in the external file,
as Text.</p>
- <p>The <code>fp:write</code> element does not emit anything
into the <input/> tag, except status Attributes. </p>
+ <p>The <code>fp:write</code> element does not emit anything
into the <code><input/></code> tag, except status Attributes. </p>
<p>After finishing the write, we read the info back out, this
is what ends up being the contents of the <code>input</code> element. I am
reading it back out incase I want to display that the user has written etc.</p>
<p>Lastly, only get the default value for the field if someone
is GETting a Form.</p>
1.12 +6 -2 xml-cocoon/xdocs/site-book.xml
Index: site-book.xml
===================================================================
RCS file: /home/cvs/xml-cocoon/xdocs/site-book.xml,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- site-book.xml 2000/06/22 22:36:15 1.11
+++ site-book.xml 2000/08/16 15:30:29 1.12
@@ -7,16 +7,20 @@
<separator/>
<page id="index" label="Index" source="index.xml"/>
<page id="license" label="License" source="license.xml"/>
+<separator/>
<page id="install" label="Install" source="installing.xml"/>
- <page id="install-case" label="Install Case"
source="installation-case.xml"/>
+ <page id="install-case-solaris" label="Install Case (Solaris8)"
source="installation-case-solaris-8.xml"/>
+ <page id="install-case-windows" label="Install Case (Win2k)"
source="installation-case-windows-2000.xml"/>
<separator/>
- <page id="infrastructure" label="Infrastructure"
source="infrastructure.xml"/>
<page id="technologies" label="Technologies" source="technologies.xml"/>
+ <page id="infrastructure" label="Infrastructure"
source="infrastructure.xml"/>
<page id="guide" label="User Guide" source="guide.xml"/>
<page id="dynamic" label="Dynamic Content" source="dynamic.xml"/>
<separator/>
<page id="xsp" label="XSP Processor" source="xspprocessor.xml"/>
<page id="sqltaglib" label="SQL XSP Taglib" source="sqltaglib.xml"/>
+ <page id="fp" label="FP XSP Taglib" source="fptaglib.xml"/>
+ <page id="connection-pool" label="SQL Conn Pool"
source="connection-pool.xml"/>
<page id="sql" label="SQL Processor" source="sqlprocessor.xml"/>
<page id="ldap" label="LDAP Processor" source="ldapprocessor.xml"/>
<page id="dcp" label="DCP Processor" source="dcpprocessor.xml"/>
1.3 +13 -12 xml-cocoon/xdocs/dtd/document-v10.dtd
Index: document-v10.dtd
===================================================================
RCS file: /home/cvs/xml-cocoon/xdocs/dtd/document-v10.dtd,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- document-v10.dtd 2000/04/04 13:42:49 1.2
+++ document-v10.dtd 2000/08/16 15:30:32 1.3
@@ -44,12 +44,13 @@
19991124 Added "fork" element for window forking behavior. (SM)
19991124 Added "img-inline" element to separate from "img". (SM)
19991129 Removed "affiliation" from "author". (SM)
- 19991129 Made "author" empty and moved "name|email" as attributes (SM)
- 19991215 Simplified table section (SM)
- 19991215 Changed "img-block" in more friendly "figure" (SM)
- 20000125 Added the "icon" image (SM)
- 20000126 Allowed "anchor" in all levels (SM)
- 20000404 Removed the "role" attribute from common-xxx.att (SM)
+ 19991129 Made "author" empty and moved "name|email" as attributes. (SM)
+ 19991215 Simplified table section. (SM)
+ 19991215 Changed "img-block" in more friendly "figure". (SM)
+ 20000125 Added the "icon" image. (SM)
+ 20000126 Allowed "anchor" in all levels. (SM)
+ 20000404 Removed the "role" attribute from common-xxx.att. (SM)
+ 20000815 Allowed "code" inside "strong" and "em". (SM)
COPYRIGHT:
Copyright (c) 1999-2000 The Apache Software Foundation.
@@ -243,17 +244,17 @@
<!-- Phrase Markup -->
<!-- ==================================================== -->
+ <!-- Code (typically monospaced) -->
+ <!ELEMENT code (%text;)>
+ <!ATTLIST code %common.att;>
+
<!-- Strong (typically bold) -->
- <!ELEMENT strong (%text;)>
+ <!ELEMENT strong (%text;|code)*>
<!ATTLIST strong %common.att;>
<!-- Emphasis (typically italic) -->
- <!ELEMENT em (%text;)>
+ <!ELEMENT em (%text;|code)*>
<!ATTLIST em %common.att;>
-
- <!-- Code (typically monospaced) -->
- <!ELEMENT code (%text;)>
- <!ATTLIST code %common.att;>
<!-- Superscript (typically smaller and higher) -->
<!ELEMENT sup (%text;)>
