You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by "Morrison, John" <Jo...@uk.experian.com> on 2001/07/18 12:53:26 UTC
[C2][PATCH] Document spelling corrections
Hi,
I've attached a patch of spelling errors - please note that I'm not trying
to criticize anybody, my spellings just as bad!
If there's been a word _I'm_ not sure of (or it's context) I've tried to
leave it. This is _just_ a spell check, grammar hasn't even entered my
head!
J.
=======================================================================
Information in this email and any attachments are confidential, and may
not be copied or used by anyone other than the addressee, nor disclosed
to any third party without our permission. There is no intention to
create any legally binding contract or other commitment through the use
of this email.
Experian Limited (registration number 653331).
Registered office: Talbot House, Talbot Street, Nottingham NG1 5HF
Re: [C2][PATCH] Document spelling corrections
Posted by Davanum Srinivas <di...@yahoo.com>.
Done. Thanks John. Keep 'em patches coming :)
-- dims
--- "Morrison, John" <Jo...@uk.experian.com> wrote:
> Hi,
>
> I've attached a patch of spelling errors - please note that I'm not trying
> to criticize anybody, my spellings just as bad!
>
> If there's been a word _I'm_ not sure of (or it's context) I've tried to
> leave it. This is _just_ a spell check, grammar hasn't even entered my
> head!
>
> J.
>
>
>
> =======================================================================
> Information in this email and any attachments are confidential, and may
> not be copied or used by anyone other than the addressee, nor disclosed
> to any third party without our permission. There is no intention to
> create any legally binding contract or other commitment through the use
> of this email.
>
> Experian Limited (registration number 653331).
> Registered office: Talbot House, Talbot Street, Nottingham NG1 5HF
> > Index: xdocs/actions.txt
> ===================================================================
> RCS file: /home/cvspublic/xml-cocoon2/xdocs/actions.txt,v
> retrieving revision 1.2
> diff -u -r1.2 actions.txt
> --- xdocs/actions.txt 2001/06/21 13:10:33 1.2
> +++ xdocs/actions.txt 2001/07/18 10:51:09
> @@ -1,6 +1,6 @@
> WARNING: This material is subject to change at anytime and may
> never find a way into the main distribution. It could
> -be removed if it has proven not to be usefull for Cocoon 2.
> +be removed if it has proven not to be useful for Cocoon 2.
>
> This is a proposal for a Action sitemap component. For more
> information look at the javadoc comments in the file Action.java
> @@ -45,7 +45,7 @@
> > > </when>
> > > <otherwise>
> > > <generate src="myapp/{1}/index.xml"/>
> -> > </otehrwise>
> +> > </otherwise>
> > > </select>
> > > <select type="browser">
> > > <when test="netscape">
> @@ -93,7 +93,7 @@
> component in the sitemap so far. Generally speaking I think a Sitemap
> Action is an object that acts upon an application model based on data
> supplied by the environments objectModel (ie Request). It's its
> -responsability to make some data available to the Sitemap engine as
> +responsibility to make some data available to the Sitemap engine as
> further selection/matching criteria (a List object) as well as in the
> objectModel for other sitemap components
>
> @@ -142,14 +142,14 @@
> someone will do it with a sitemap component :/
> Authorisation is more dependant on the application context and there are
> the possibilities to use AuthorisationMatchers, AuthorisationSelectors,
> -AuthorisationActions or a authorisation logicsheeet, what ever suit your
> +AuthorisationActions or a authorisation logicsheet, what ever suit your
> needs best.
>
> > What about form validation ?
>
> Even here, it depends. If you only want to validate form data a Selector
> can be used to achieve that and in the <map:when> elements you
> -regenerate the resource if validation failes or choose an action to put
> +regenerate the resource if validation fails or choose an action to put
> the form data into your application model and generate the next screen
> or whatever.
>
> @@ -203,7 +203,7 @@
> > NoEntry.html type page.
> > ...
> >
> -> So when I designe a sitemap for a web-application I want to somehow be able
> +> So when I design a sitemap for a web-application I want to somehow be able
> > to do the following.
> >
> > * Anything under webapp/ must run SessionValidatorAction
> @@ -211,12 +211,12 @@
> > "admin" role
> > * Then specific resources webapp/a.xml, webapp/b.xml and webapp/admin/c.xml
> > must run FormValidationAction with appropriate form schema and the
> -> apprporiate FormDBEntryAction
> +> appropriate FormDBEntryAction
>
> Didn't get the last one? What is a FormDBEntryAction for? Probably an
> XSP page?
>
> -> * A user can also arbitarily submit an action from any page (via post
> +> * A user can also arbitrarily submit an action from any page (via post
> > request or perhaps a ?action=blah tacked onto URL) that must be executed.
>
> <match type="uri" pattern="webapp/**">
> @@ -263,7 +263,7 @@
> >
> > So what would I want to see in a Cocoon-Application framework ???
> >
> -> Well actions are independent of resources and exist in a seperate namespace.
> +> Well actions are independent of resources and exist in a separate namespace.
> >
> > Each request can in theory result in a action-pipeline.
> >
> @@ -288,7 +288,7 @@
> > to C2 and I suspect many others would too :P.
>
> Implementing the framework to use actions like I've mentioned through
> -out this mail is a matter of an hour or two. But your're right
> +out this mail is a matter of an hour or two. But you're right
> implementing general actions for general usage is another thing.
>
> Giacomo
> Index: xdocs/actions.xml
> ===================================================================
> RCS file: /home/cvspublic/xml-cocoon2/xdocs/actions.xml,v
> retrieving revision 1.4
> diff -u -r1.4 actions.xml
> --- xdocs/actions.xml 2001/07/17 12:31:29 1.4
> +++ xdocs/actions.xml 2001/07/18 10:51:09
> @@ -21,7 +21,7 @@
> at run time, we surmised that sometimes we need to adjust the pipeline
> based on runtime parameters, or even the contents of the Request parameter.
> Without the use of Actions this would make the sitemap almost
> - incomprehensable.
> + incomprehensible.
> </p>
> <p>
> The quick and dirty definition of an Action is "a Sitemap Component that
> @@ -77,7 +77,7 @@
> <p>
> The alternative is to use Actions. Actions handle the pure logic
> handling portions of your site. This allows you to create each page
> - in the multiplage form to handle any logic it needs to for display
> + in the multipage form to handle any logic it needs to for display
> purposes only. Your form handling information is kept separate, and
> can even predictably change the pipeline used in the sitemap.
> </p>
> @@ -162,7 +162,7 @@
> </source>
> <p>
> Using this approach, we will generate the file named "hello_world.xsp"
> - because the value of the Sitemap paramter "{world}" is "hello". Also,
> + because the value of the Sitemap parameter "{world}" is "hello". Also,
> the file "hello_world.xsp" can use the request parameter "hello" to
> produce the value "world".
> </p>
> @@ -183,7 +183,7 @@
> <source>
> <![CDATA[
> <map:match pattern="file">
> - <map:act type="hello-world" src="optinal src">
> + <map:act type="hello-world" src="optional src">
> <!-- and here come the parameters: -->
> <map:parameter name="first parameter" value="test"/>
>
> @@ -208,10 +208,10 @@
> You can arrange actions in an action set. The sitemap calls the
> act method of those actions in the sequence they are defined in the
> action set. It is possible to signal to the sitemap to
> - call an antion only if the Environments getAction method returns
> + call an action only if the Environments getAction method returns
> a String identical to the value supplied with an action attribute.
> In the current implementation of the HttpEnvironment the value
> - returned by the getAction methos is determined by a http parameter
> + returned by the getAction method is determined by a http parameter
> called "cocoon-action". So far let's have a look at at possible
> action set definition:
> </p>
> @@ -273,7 +273,7 @@
> </p>
> <p>
> However, one is not limited to specify distinct values at the action attribute.
> -It is possible and I think usefull to mark several actions with the same
> +It is possible and I think useful to mark several actions with the same
> action attribute value which will then be called in sequence. This allows you
> to choose a granularity of your actions at will.
> </p>
> Index: xdocs/caching.xml
> ===================================================================
> RCS file: /home/cvspublic/xml-cocoon2/xdocs/caching.xml,v
> retrieving revision 1.7
> diff -u -r1.7 caching.xml
> --- xdocs/caching.xml 2001/07/02 09:03:36 1.7
> +++ xdocs/caching.xml 2001/07/18 10:51:09
> @@ -27,7 +27,7 @@
> For more information about configuration see the chapter below.</p>
> <p>The following subchapters describe the available caching algorithms.</p>
> <s2 title="The CachingEventPipeline">
> - <p>The CachingEventPipelineuses a very easy but effectiv approach
> + <p>The CachingEventPipelineuses a very easy but effective approach
> to cache the event pipelines of a request: The pipeline process
> is cached up to the most possible point.</p>
> <p>Each sitemap component (generator or transformer) which might be
> @@ -73,7 +73,7 @@
> <s3 title="Examples">
> <p>If you have the following pipeline:</p>
>
> <p>Generator[type=file|src=a.xml]->Transformer[type="xslt"|src=a.xsl]->Serializer</p>
> - <p>The file generator is cacheable and generates a key which hashesthe src
> + <p>The file generator is cacheable and generates a key which hashes the src
> (or the filename) to build the key. The cache
> validity object uses the last modification date of the xml file.</p>
> <p>The xslt transformer is cacheable and generates a key which hashes
> @@ -86,7 +86,7 @@
> the serializer.</p>
> <p>Only part of the following pipeline is cached:</p>
>
>
<p>Generator[type=file|src=a.xml]->Transformer[type="xslt"|src=a.xsl]->Transformer[type=sql]->Transformer[type="xslt"|src=b.xsl]->Serializer</p>
> - <p>The file generator is cacheable and generates a key which hashesthe src
> + <p>The file generator is cacheable and generates a key which hashes the src
> (or the filename) to build the key. The cache
> validity object uses the last modification date of the xml file.</p>
> <p>The xslt transformer is cacheable and generates a key which hashes
> @@ -129,7 +129,7 @@
> For more information about configuration see the chapter below.</p>
> <p>The following subchapters describe the available caching algorithms.</p>
> <s2 title="The CachingStreamPipeline">
> - <p>The <code>CachingStreamPipeline</code> uses a very easy but effectiv approach
> + <p>The <code>CachingStreamPipeline</code> uses a very easy but effective approach
> to cache the stream pipelines of a request: If the underlying
> event stream and the serializer is cacheable the request is cached.
>
=== message truncated ===> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
=====
Davanum Srinivas, JNI-FAQ Manager
http://www.jGuru.com/faq/JNI
__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org