tony 2004/05/26 14:49:19
Modified: src/blocks/tour/samples/bean-editor/docs forms.xml index.xml
javabeans.xml tasklist.xml
Log:
even more typographical fixes -- fun for the whole family!
Revision Changes Path
1.2 +3 -3
cocoon-2.1/src/blocks/tour/samples/bean-editor/docs/forms.xml
Index: forms.xml
===================================================================
RCS file:
/home/cvs/cocoon-2.1/src/blocks/tour/samples/bean-editor/docs/forms.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- forms.xml 11 May 2004 06:52:30 -0000 1.1
+++ forms.xml 26 May 2004 21:49:19 -0000 1.2
@@ -124,7 +124,7 @@
<p>
This model is independent from the way the form
is going to look in HTML (or WML, or XUL, or whatever), and
- also independent of the internal structure of our java beans.
+ also independent of the internal structure of our Java beans.
</p>
<p>
Here we use constants for the widget labels (field names),
@@ -137,7 +137,7 @@
<p>
Here's the <em>binding</em> definition, which allows the Forms
subsystem to automatically move data from our Form's internal
model
- to our java beans.
+ to our Java beans.
</p>
<p>
This looks simple enough: for example, we tell the Forms
@@ -180,7 +180,7 @@
</p>
<p>
Another important feature of the Cocoon Forms subsystem is its
extensibility:
- a clean design makes it fairly easy to add custom java classes
for custom formatting,
+ a clean design makes it fairly easy to add custom Java classes
for custom formatting,
validation and bindings.
</p>
</content>
1.2 +2 -2
cocoon-2.1/src/blocks/tour/samples/bean-editor/docs/index.xml
Index: index.xml
===================================================================
RCS file:
/home/cvs/cocoon-2.1/src/blocks/tour/samples/bean-editor/docs/index.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- index.xml 11 May 2004 06:52:30 -0000 1.1
+++ index.xml 26 May 2004 21:49:19 -0000 1.2
@@ -34,7 +34,7 @@
</p>
<p>
Our Java beans are trivial and uninteresting: what we're looking
for is an understanding of
- how Cocoon Pipelines, Forms and Flow play together with java
code, and for this a very simple
+ how Cocoon Pipelines, Forms and Flow play together with Java
code, and for this a very simple
application is certainly good.
</p>
<p>
@@ -60,7 +60,7 @@
</p>
<h2>Running the application</h2>
<p>
- To run the bean editor application, Cocoon must be able to load
the required java classes.
+ To run the bean editor application, Cocoon must be able to load
the required Java classes.
</p>
<p>
If you're running this tutorial from the standard Cocoon
distribution this should be
1.2 +3 -3
cocoon-2.1/src/blocks/tour/samples/bean-editor/docs/javabeans.xml
Index: javabeans.xml
===================================================================
RCS file:
/home/cvs/cocoon-2.1/src/blocks/tour/samples/bean-editor/docs/javabeans.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- javabeans.xml 11 May 2004 06:52:30 -0000 1.1
+++ javabeans.xml 26 May 2004 21:49:19 -0000 1.2
@@ -26,7 +26,7 @@
<h2>Interfaces</h2>
<p>
Here's the interface of the DatabaseFacade class, which is used
by our
- Flowscript code to "talk" to the java beans:
+ Flowscript code to "talk" to the Java beans:
<pre class="code">
/** access the Database */
public static DatabaseFacade getInstance();
@@ -72,7 +72,7 @@
<h2>Access from Flowscript</h2>
<p>
- Here's a code excerpt showing how Flowscript code can access
java classes.
+ Here's a code excerpt showing how Flowscript code can access
Java classes.
</p>
<pre class="code">
var db =
Packages.org.apache.cocoon.samples.tour.beans.DatabaseFacade.getInstance();
@@ -80,7 +80,7 @@
list = db.getTasks();
</pre>
<p>
- Simple enough. The "official" way of accessing java components
in a Cocoon
+ Simple enough. The "official" way of accessing Java components
in a Cocoon
application would be to use the Avalon lookup mechanisms, but
this wouldn't
add much to our example so we took the easy way here.
</p>
1.2 +4 -4
cocoon-2.1/src/blocks/tour/samples/bean-editor/docs/tasklist.xml
Index: tasklist.xml
===================================================================
RCS file:
/home/cvs/cocoon-2.1/src/blocks/tour/samples/bean-editor/docs/tasklist.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- tasklist.xml 11 May 2004 06:52:30 -0000 1.1
+++ tasklist.xml 26 May 2004 21:49:19 -0000 1.2
@@ -78,7 +78,7 @@
<p>
We're not using continuations here (there's no
<em>sendPageAndWait</em>),
Flowscript serves only as a thin layer of glue
- between our java objects and our JXTemplate view page.
+ between our Java objects and our JXTemplate view page.
</p>
<h2>JXTemplate page</h2>
@@ -98,12 +98,12 @@
<ol>
<li>A request for <em>view/allTasks</em> comes in</li>
<li>
- The <em>query_allTasks()</em> Flowscript function is
called and uses the java <em>DatabaseFacade</em>
- to retrieve a java List of <em>TaskBean</em> objects.
+ The <em>query_allTasks()</em> Flowscript function is
called and uses the Java <em>DatabaseFacade</em>
+ to retrieve a Java List of <em>TaskBean</em> objects.
</li>
<li>
Flowscript uses the <em>cocoon.sendPage()</em> function
to trigger the execution of a sitemap
- pipeline, passing to it some data as javascript
variables.
+ pipeline, passing to it some data as JavaScript
variables.
</li>
<li>
The pipeline uses the JXTemplate generator to
dynamically insert data in an XML template