cocoon-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From vgritse...@apache.org
Subject cvs commit: cocoon-site/site/2.1/userdocs/generators telnet.txt
Date Wed, 21 May 2003 17:47:58 GMT
vgritsenko    2003/05/21 10:47:58

  Modified:    site/2.1 index.html index.pdf license.html license.pdf
               site/2.1/developing/webapps index.html index.pdf
               site/2.1/howto README.txt
               site/2.1/installing updating.html updating.pdf
               site/2.1/plan linkalarm-readme.txt
               site/2.1/userdocs/concepts actions.txt index.html index.pdf
               site/2.1/userdocs/generators telnet.txt
  Log:
  Fixed forrest filtering issue
  
  Revision  Changes    Path
  1.5       +1 -1      cocoon-site/site/2.1/index.html
  
  Index: index.html
  ===================================================================
  RCS file: /home/cvs/cocoon-site/site/2.1/index.html,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- index.html	21 May 2003 15:20:42 -0000	1.4
  +++ index.html	21 May 2003 17:47:56 -0000	1.5
  @@ -371,7 +371,7 @@
   <h3>Where can I find it?</h3>
   <div style="margin-left: 0 ; border: 2px">
   <p>
  -   To download the latest release @released.version@ of Apache Cocoon, go to the 
  +   To download the latest release 2.0.4 of Apache Cocoon, go to the 
      <a href="http://cocoon.apache.org/mirror.cgi">download area.</a>
         
   </p>
  
  
  
  1.2       +70 -96    cocoon-site/site/2.1/index.pdf
  
  	<<Binary file>>
  
  
  1.5       +1 -1      cocoon-site/site/2.1/license.html
  
  Index: license.html
  ===================================================================
  RCS file: /home/cvs/cocoon-site/site/2.1/license.html,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- license.html	21 May 2003 15:20:42 -0000	1.4
  +++ license.html	21 May 2003 17:47:56 -0000	1.5
  @@ -342,7 +342,7 @@
                      The Apache Software License, Version 1.1
    ============================================================================
    
  - Copyright (C) @year@ The Apache Software Foundation. All rights reserved.
  + Copyright (C) 1999-2003 The Apache Software Foundation. All rights reserved.
    
    Redistribution and use in source and binary forms, with or without modifica-
    tion, are permitted provided that the following conditions are met:
  
  
  
  1.2       +22 -22    cocoon-site/site/2.1/license.pdf
  
  	<<Binary file>>
  
  
  1.5       +1 -1      cocoon-site/site/2.1/developing/webapps/index.html
  
  Index: index.html
  ===================================================================
  RCS file: /home/cvs/cocoon-site/site/2.1/developing/webapps/index.html,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- index.html	21 May 2003 15:23:18 -0000	1.4
  +++ index.html	21 May 2003 17:47:57 -0000	1.5
  @@ -220,7 +220,7 @@
     the <a href="portal.html">portal framework</a> is nearly finished. You will
     find these components in the latest CVS version of Cocoon. The documentation
     listed in the menu conforms to the current CVS version.</p>
  -<p>However, the current release @released.version@ contains alpha versions in the
  +<p>However, the current release 2.0.4 contains alpha versions in the
      scratchpad area of these three components. So you can already have a look at them. The
      documentation in the "scratchpad" folder contains the description conforming to the
      scratchpad. But be warned that they are in the scratchpad area and will change in 
  
  
  
  1.2       +26 -26    cocoon-site/site/2.1/developing/webapps/index.pdf
  
  	<<Binary file>>
  
  
  1.2       +10 -10    cocoon-site/site/2.1/howto/README.txt
  
  Index: README.txt
  ===================================================================
  RCS file: /home/cvs/cocoon-site/site/2.1/howto/README.txt,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- README.txt	15 May 2003 04:17:36 -0000	1.1
  +++ README.txt	21 May 2003 17:47:57 -0000	1.2
  @@ -1,10 +1,10 @@
  -Filename conventions
  -How-To files in this directory should follow the following naming convention:
  -
  -    howto-<descriptive-name-here>.xml
  -
  -Use hyphens between any words which follow "howto-". Please make sure your name will be
sufficiently unique to distinguish it from future contributions. For example, if you are committing
a how-to about Actions, don't name it howto-actions.xml. 
  -
  -Multi-page How-Tos
  -If you are adding in a multi-page How-To to this directory please create a subdirectory
with the same name as the main page of your How-To, minus the beginning phrase "howto-" and
the ending phrase ".xml". Add "-<step number>" within filenames for pages which represent
additional How-To steps. See the xmlform-wizard How-To directory structure for more information.
  -
  +Filename conventions
  +How-To files in this directory should follow the following naming convention:
  +
  +    howto-<descriptive-name-here>.xml
  +
  +Use hyphens between any words which follow "howto-". Please make sure your name will be
sufficiently unique to distinguish it from future contributions. For example, if you are committing
a how-to about Actions, don't name it howto-actions.xml. 
  +
  +Multi-page How-Tos
  +If you are adding in a multi-page How-To to this directory please create a subdirectory
with the same name as the main page of your How-To, minus the beginning phrase "howto-" and
the ending phrase ".xml". Add "-<step number>" within filenames for pages which represent
additional How-To steps. See the xmlform-wizard How-To directory structure for more information.
  +
  
  
  
  1.5       +1 -1      cocoon-site/site/2.1/installing/updating.html
  
  Index: updating.html
  ===================================================================
  RCS file: /home/cvs/cocoon-site/site/2.1/installing/updating.html,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- updating.html	21 May 2003 15:23:24 -0000	1.4
  +++ updating.html	21 May 2003 17:47:57 -0000	1.5
  @@ -246,7 +246,7 @@
   <h3>Updating Cocoon</h3>
   <div style="margin-left: 0 ; border: 2px">
   <p>
  -   This is a brief discussion of the changes between the latest official release @released.version@
  +   This is a brief discussion of the changes between the latest official release 2.0.4
      and the current development version of Apache Cocoon. So, if you are interested in
      installing the official release, ignore this document. But if you want to know what
is going
      on in the development of Cocoon, have a look...
  
  
  
  1.2       +51 -51    cocoon-site/site/2.1/installing/updating.pdf
  
  	<<Binary file>>
  
  
  1.2       +30 -30    cocoon-site/site/2.1/plan/linkalarm-readme.txt
  
  Index: linkalarm-readme.txt
  ===================================================================
  RCS file: /home/cvs/cocoon-site/site/2.1/plan/linkalarm-readme.txt,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- linkalarm-readme.txt	15 May 2003 04:18:02 -0000	1.1
  +++ linkalarm-readme.txt	21 May 2003 17:47:57 -0000	1.2
  @@ -1,30 +1,30 @@
  -The LinkAlarm report for cocoon.apache.org/ is at
  -http://reports.linkalarm.com/373104199608/
  -
  -LinkAlarm scans are run after each public release of Cocoon
  -to detect any issues that need to be addressed prior to the
  -next release.
  -
  -The LinkAlarm report gives detailed HTML views of the situation
  -in an easy-to-read style. However, the summary file that is
  -explained below has concise info about the actual broken links.
  -
  -One other LinkAlarm page that is of special interest is the
  -"mailto:" validation page (those errors are not included in
  -the summary listing below).
  -
  -To facilitate the management of link mending by the Cocoon
  -community, there is a summary file in the HEAD CVS at
  - documentation/xdocs/plan/linkalarm-broken.txt
  -This tab-delimited file has the following format ...
  -
  -status problem_link referring_page response_code meaning comment
  -
  -where "status" has these codes ...
  - - ... not yet addressed
  - F ... fixed
  - ? ... has some issue (see the "comment" field)
  - [1-3] ... external link broken for n runs (will be dropped soon)
  -
  -To reduce duplication of effort, please update the "status"
  -tag for each issue that you have addressed.
  +The LinkAlarm report for cocoon.apache.org/ is at
  +http://reports.linkalarm.com/373104199608/
  +
  +LinkAlarm scans are run after each public release of Cocoon
  +to detect any issues that need to be addressed prior to the
  +next release.
  +
  +The LinkAlarm report gives detailed HTML views of the situation
  +in an easy-to-read style. However, the summary file that is
  +explained below has concise info about the actual broken links.
  +
  +One other LinkAlarm page that is of special interest is the
  +"mailto:" validation page (those errors are not included in
  +the summary listing below).
  +
  +To facilitate the management of link mending by the Cocoon
  +community, there is a summary file in the HEAD CVS at
  + documentation/xdocs/plan/linkalarm-broken.txt
  +This tab-delimited file has the following format ...
  +
  +status problem_link referring_page response_code meaning comment
  +
  +where "status" has these codes ...
  + - ... not yet addressed
  + F ... fixed
  + ? ... has some issue (see the "comment" field)
  + [1-3] ... external link broken for n runs (will be dropped soon)
  +
  +To reduce duplication of effort, please update the "status"
  +tag for each issue that you have addressed.
  
  
  
  1.2       +294 -294  cocoon-site/site/2.1/userdocs/concepts/actions.txt
  
  Index: actions.txt
  ===================================================================
  RCS file: /home/cvs/cocoon-site/site/2.1/userdocs/concepts/actions.txt,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- actions.txt	15 May 2003 04:18:54 -0000	1.1
  +++ actions.txt	21 May 2003 17:47:57 -0000	1.2
  @@ -1,294 +1,294 @@
  -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 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
  -in this directory. For a possible implementation look at the file
  -HelloAction.java.
  -
  -Create a file named "actions.inc" in the root of the Cocoon 2
  -repository to include this functionality and execute the command
  -"build package webapp".
  -
  -The created cocoon.war and cocoon.jar file in build/cocoon
  -directory contains the modified version which include the
  -Action sitemap component and the sample HelloAction which
  -is called when requesting the URL http://localhost:8080/cocoon/welcome
  -
  -To give you an overview of the discussion about sitemap Actions here is
  -an excerpt from the cocoon-dev mailing list:
  -
  -------------------------------------<<>>-------------------------------------
  -
  -Peter Donald wrote:
  ->
  -> At 04:15  9/9/00 +0200, you wrote:
  -> >  <match type="uri" pattern="myapp/**">
  -> >    <!-- the following Matcher make the overall request
  -> >         analysis and makes important information available
  -> >         to subsequent components through the objectModel and
  -> >         a Map for substitution in src= attributes.
  -> >         Maybe a Controller sitemap component would be more
  -> >         appropriate
  -> >    -->
  -> >    <match type="myapp-controller" pattern="not really used">
  -> >      <select type="myapp-action-selector">
  -> >        <when test="add">
  -> >          <!-- here the {1} is delivered by the matcher
  -> >               "myapp-controller"
  -> >          -->
  -> >          <generate src="myapp/{1}/remove.xsp"/>
  -> >        </when>
  -> >        <when test="remove">
  -> >          <generate src="myapp/{1}/remove.xsp"/>
  -> >        </when>
  -> >        <otherwise>
  -> >          <generate src="myapp/{1}/index.xml"/>
  -> >        </otherwise>
  -> >      </select>
  -> >      <select type="browser">
  -> >        <when test="netscape">
  -> >          <transform src="myapp/{1}/style-ns.xsl"/>
  -> >          <serialize type="html"/>
  -> >        </when>
  -> >        <when test="wap">
  -> >          <transform src="myapp/{1}/style-wap.xsl"/>
  -> >          <serialize type="wap"/>
  -> >        </when>
  -> >        <otherwise>
  -> >          <transform src="myapp/{1}/style-ie.xsl"/>
  -> >          <serialize type="html"/>
  -> >        </otherwise>
  -> >      </select>
  -> >    </match>
  -> >  </match>
  -> >  <-- here we catch all requests not handled by the match above
  -> >      and redirect them to the login screen or an error page
  -> >  -->
  -> >  <match pattern="myapp/**">
  -> >    <redirect-to uri="myapp/login"/>
  -> >  </match>
  -> >Well, this example might not be the best one but I think its
  -> >good enough to start a discussion about it. What do you think?
  ->
  -> I like the approach but before an implementation can be defined there is a
  -> few questions that must be answered first. Namely
  ->
  -> * What is an Action ?
  -> * How will you use actions ?
  ->
  -> What is an Action ?
  -> -------------------
  ->
  -> In the above case you have associated an Action with a resource. ie the
  -> Remove action is associated with myapp/{1}/remove.xsp resource. Do actions
  -> have to be associated with a resource or are they independent of resources.
  -> I would say that they are independent - an Action framework should be able
  -> to be used via multiple interfaces whether via cocoon, turbine, telnet,
  -> mail etc. So the "ShutdownRealWorldMachine" action is accessible via the C2
  -> interface, a telnet interface or via any number of other methods.
  -
  -The example above is probably misleading because we don't have a Action
  -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
  -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
  -
  -Suppose the Interface of an Actions is like this:
  -
  -   public Interface Action {
  -       public List act (Map objectModel);
  -   }
  -
  -and also suppose that the nested elements of the <map:act> elements are
  -skipped if the action returns a null value instead of a List.
  -
  - <match type="uri" pattern="myapp/**">
  -   <act type="myaction">
  -     <select type="action-selector">
  -       <when test="remove"/>
  -         <generate src="myapp/{1}/remove.xsp"/>
  -       </when>
  -       ...
  -     </select>
  -   </act>
  - </match>
  -
  -The List object supplied by the action is used by the sitemap engine to
  -replace occurrences like {1} from certain attributes like src= but this
  -is optional. So the Action is not really associated to a resource. It's
  -the selector which does this association.
  -
  -> An action is essentially a snippet of code that is executed in response to
  -> a request in a certain context (or Environment in C2s case). The action can
  -> add and change the context/environment data.
  -
  -Agreed.
  -
  -> How granular can actions be ?
  -
  -You should be able to be as granular as you want.
  -
  -> Does session validation count as an action ?
  -
  -Why not?
  -
  -> How about authorisation and authentication ?
  -
  -I still suppose to leave authentication to the container but I know
  -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 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 fails or choose an action to put
  -the form data into your application model and generate the next screen
  -or whatever.
  -
  -> When I program actions I use a extremely granular approach.
  -
  -No problem, you should be able to do things like that
  -
  - <match type="uri" pattern="myapp/**">
  -   <act type="session validation">
  -     <act type="form-validation">
  -       <select type="validation-check">
  -         <when test="ok">
  -           <act type="model-update"/>
  -           <generate src="next-page"/>
  -         </when>
  -         <otherwise>
  -           <generate src="this-page"/>
  -         </otherwise>
  -       </select>
  -     </act>
  -   </act>
  -   <generate src="login"/>
  - </match>
  -
  -> There is also the idea of latent actions. For instance the latent Action is
  -> transmitted between end-user and cocoon until they are activated. Actions
  -> may also be made latent (or deactivated) in a couple of cases. Like when
  -> you try to submit form but are not logged in - it will save action/form
  -> data (or put action into latent state) and then after login commit the
  -> action (or re-activate action).
  -
  -Isn't this a matter how components play together?
  -
  -> How will you use actions ?
  -> ---------------------------
  ->
  -> In many cases when I program to a an actions approach each request can
  -> result in many actions being executed. For instance it is not uncommon for
  -> an action chain to occur like the following.
  ->
  -> SessionValidatorAction --> RoleAssignerAction --> FormValidationAction -->
  -> FormDBEntryAction
  ->
  -> The SessionValidatorAction will check the session and if not exist then it
  -> will put a magic token in environment so that after action is executed then
  -> the rest of action-chain and output resource is ignored and the user is
  -> redirected to a login page.
  ->
  -> The RoleAssignerAction (lame name I know ;->) will check if the current
  -> user implements a certain role and if not redirect them to appropriate
  -> NoEntry.html type page.
  -> ...
  ->
  -> 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
  -> * Anything under webapp/admin must run RoleAssignerAction and check for
  -> "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
  -> appropriate FormDBEntryAction
  -
  -Didn't get the last one? What is a FormDBEntryAction for? Probably an
  -XSP page?
  -
  -> * 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/**">
  -    <act type="session-validation"/>
  -    <match type="uri" pattern="webapp/admin">
  -      <act type="assign-role">
  -        <select type="role-selector">
  -          <when test="admin">
  -            <match type="uri" pattern="webapp/admin/c.xml">
  -              <act type="form-validation src="admin/form-schema-c.xsd"/>
  -              <!-- the following next-page action has knowledge of the
  -                   sequence of pages and returns a List with the first
  -element
  -                   corresponding to the "next page" appropriate
  -depending on
  -                   values in the objectModel signaling successful
  -validation by
  -                   the previous action (type="form-validation"). The
  -following
  -                   three lines could be put into a sitemap resource
  -definition
  -                   and replaced by <redirect-to resource="next-page"/>
  -              -->
  -              <act type="next-page">
  -                <generate src="{1}"/>
  -              </act>
  -            </match>
  -          <otherwise>
  -            <match type="uri-regexp" pattern="webapp/(a|b)\.xml">
  -              <act type="form-validation src="form-schema-{1}.xsd"/>
  -              <act type="next-page">
  -                <generate src="{1}"/>
  -              </act>
  -            </match>
  -          </when>
  -        </select>
  -      </act>
  -    </match>
  -  </match>
  -
  ->
  -> ----------------------------------------------------------------------------
  -> ---------
  ->
  -> So what would I want to see in a Cocoon-Application framework ???
  ->
  -> Well actions are independent of resources and exist in a separate namespace.
  ->
  -> Each request can in theory result in a action-pipeline.
  ->
  -> Each action can add stuff to it's context (or Environment).
  ->
  -> Each action can in theory short-cut the action pipeline and move to another
  -> action-resource pipeline and also store remaining submitted actions as
  -> latent actions.
  ->
  -> An action pipeline must not necessarily be associated with a resource (it
  -> should instead be able to specify a resource that it goes to post processing).
  ->
  -> It may also be good to have an action that's sole purpose is to extract
  -> explicit action requests and execute/store them (ActionExtractorAction +
  -> ActionDispatcherAction ???)
  -
  -Please answer these question yourself after you've read my explanations.
  -
  -> But anyways I mean in no way to imply C2 is bad and if you want to add
  -> hooks into sitemap generation to allow for this sort of stuff (or even
  -> better do it yourself ;>) I would gladly switch all my development across
  -> 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 you're right
  -implementing general actions for general usage is another thing.
  -
  -Giacomo
  \ No newline at end of file
  +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 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
  +in this directory. For a possible implementation look at the file
  +HelloAction.java.
  +
  +Create a file named "actions.inc" in the root of the Cocoon 2
  +repository to include this functionality and execute the command
  +"build package webapp".
  +
  +The created cocoon.war and cocoon.jar file in build/cocoon
  +directory contains the modified version which include the
  +Action sitemap component and the sample HelloAction which
  +is called when requesting the URL http://localhost:8080/cocoon/welcome
  +
  +To give you an overview of the discussion about sitemap Actions here is
  +an excerpt from the cocoon-dev mailing list:
  +
  +------------------------------------<<>>-------------------------------------
  +
  +Peter Donald wrote:
  +>
  +> At 04:15  9/9/00 +0200, you wrote:
  +> >  <match type="uri" pattern="myapp/**">
  +> >    <!-- the following Matcher make the overall request
  +> >         analysis and makes important information available
  +> >         to subsequent components through the objectModel and
  +> >         a Map for substitution in src= attributes.
  +> >         Maybe a Controller sitemap component would be more
  +> >         appropriate
  +> >    -->
  +> >    <match type="myapp-controller" pattern="not really used">
  +> >      <select type="myapp-action-selector">
  +> >        <when test="add">
  +> >          <!-- here the {1} is delivered by the matcher
  +> >               "myapp-controller"
  +> >          -->
  +> >          <generate src="myapp/{1}/remove.xsp"/>
  +> >        </when>
  +> >        <when test="remove">
  +> >          <generate src="myapp/{1}/remove.xsp"/>
  +> >        </when>
  +> >        <otherwise>
  +> >          <generate src="myapp/{1}/index.xml"/>
  +> >        </otherwise>
  +> >      </select>
  +> >      <select type="browser">
  +> >        <when test="netscape">
  +> >          <transform src="myapp/{1}/style-ns.xsl"/>
  +> >          <serialize type="html"/>
  +> >        </when>
  +> >        <when test="wap">
  +> >          <transform src="myapp/{1}/style-wap.xsl"/>
  +> >          <serialize type="wap"/>
  +> >        </when>
  +> >        <otherwise>
  +> >          <transform src="myapp/{1}/style-ie.xsl"/>
  +> >          <serialize type="html"/>
  +> >        </otherwise>
  +> >      </select>
  +> >    </match>
  +> >  </match>
  +> >  <-- here we catch all requests not handled by the match above
  +> >      and redirect them to the login screen or an error page
  +> >  -->
  +> >  <match pattern="myapp/**">
  +> >    <redirect-to uri="myapp/login"/>
  +> >  </match>
  +> >Well, this example might not be the best one but I think its
  +> >good enough to start a discussion about it. What do you think?
  +>
  +> I like the approach but before an implementation can be defined there is a
  +> few questions that must be answered first. Namely
  +>
  +> * What is an Action ?
  +> * How will you use actions ?
  +>
  +> What is an Action ?
  +> -------------------
  +>
  +> In the above case you have associated an Action with a resource. ie the
  +> Remove action is associated with myapp/{1}/remove.xsp resource. Do actions
  +> have to be associated with a resource or are they independent of resources.
  +> I would say that they are independent - an Action framework should be able
  +> to be used via multiple interfaces whether via cocoon, turbine, telnet,
  +> mail etc. So the "ShutdownRealWorldMachine" action is accessible via the C2
  +> interface, a telnet interface or via any number of other methods.
  +
  +The example above is probably misleading because we don't have a Action
  +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
  +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
  +
  +Suppose the Interface of an Actions is like this:
  +
  +   public Interface Action {
  +       public List act (Map objectModel);
  +   }
  +
  +and also suppose that the nested elements of the <map:act> elements are
  +skipped if the action returns a null value instead of a List.
  +
  + <match type="uri" pattern="myapp/**">
  +   <act type="myaction">
  +     <select type="action-selector">
  +       <when test="remove"/>
  +         <generate src="myapp/{1}/remove.xsp"/>
  +       </when>
  +       ...
  +     </select>
  +   </act>
  + </match>
  +
  +The List object supplied by the action is used by the sitemap engine to
  +replace occurrences like {1} from certain attributes like src= but this
  +is optional. So the Action is not really associated to a resource. It's
  +the selector which does this association.
  +
  +> An action is essentially a snippet of code that is executed in response to
  +> a request in a certain context (or Environment in C2s case). The action can
  +> add and change the context/environment data.
  +
  +Agreed.
  +
  +> How granular can actions be ?
  +
  +You should be able to be as granular as you want.
  +
  +> Does session validation count as an action ?
  +
  +Why not?
  +
  +> How about authorisation and authentication ?
  +
  +I still suppose to leave authentication to the container but I know
  +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 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 fails or choose an action to put
  +the form data into your application model and generate the next screen
  +or whatever.
  +
  +> When I program actions I use a extremely granular approach.
  +
  +No problem, you should be able to do things like that
  +
  + <match type="uri" pattern="myapp/**">
  +   <act type="session validation">
  +     <act type="form-validation">
  +       <select type="validation-check">
  +         <when test="ok">
  +           <act type="model-update"/>
  +           <generate src="next-page"/>
  +         </when>
  +         <otherwise>
  +           <generate src="this-page"/>
  +         </otherwise>
  +       </select>
  +     </act>
  +   </act>
  +   <generate src="login"/>
  + </match>
  +
  +> There is also the idea of latent actions. For instance the latent Action is
  +> transmitted between end-user and cocoon until they are activated. Actions
  +> may also be made latent (or deactivated) in a couple of cases. Like when
  +> you try to submit form but are not logged in - it will save action/form
  +> data (or put action into latent state) and then after login commit the
  +> action (or re-activate action).
  +
  +Isn't this a matter how components play together?
  +
  +> How will you use actions ?
  +> ---------------------------
  +>
  +> In many cases when I program to a an actions approach each request can
  +> result in many actions being executed. For instance it is not uncommon for
  +> an action chain to occur like the following.
  +>
  +> SessionValidatorAction --> RoleAssignerAction --> FormValidationAction -->
  +> FormDBEntryAction
  +>
  +> The SessionValidatorAction will check the session and if not exist then it
  +> will put a magic token in environment so that after action is executed then
  +> the rest of action-chain and output resource is ignored and the user is
  +> redirected to a login page.
  +>
  +> The RoleAssignerAction (lame name I know ;->) will check if the current
  +> user implements a certain role and if not redirect them to appropriate
  +> NoEntry.html type page.
  +> ...
  +>
  +> 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
  +> * Anything under webapp/admin must run RoleAssignerAction and check for
  +> "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
  +> appropriate FormDBEntryAction
  +
  +Didn't get the last one? What is a FormDBEntryAction for? Probably an
  +XSP page?
  +
  +> * 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/**">
  +    <act type="session-validation"/>
  +    <match type="uri" pattern="webapp/admin">
  +      <act type="assign-role">
  +        <select type="role-selector">
  +          <when test="admin">
  +            <match type="uri" pattern="webapp/admin/c.xml">
  +              <act type="form-validation src="admin/form-schema-c.xsd"/>
  +              <!-- the following next-page action has knowledge of the
  +                   sequence of pages and returns a List with the first
  +element
  +                   corresponding to the "next page" appropriate
  +depending on
  +                   values in the objectModel signaling successful
  +validation by
  +                   the previous action (type="form-validation"). The
  +following
  +                   three lines could be put into a sitemap resource
  +definition
  +                   and replaced by <redirect-to resource="next-page"/>
  +              -->
  +              <act type="next-page">
  +                <generate src="{1}"/>
  +              </act>
  +            </match>
  +          <otherwise>
  +            <match type="uri-regexp" pattern="webapp/(a|b)\.xml">
  +              <act type="form-validation src="form-schema-{1}.xsd"/>
  +              <act type="next-page">
  +                <generate src="{1}"/>
  +              </act>
  +            </match>
  +          </when>
  +        </select>
  +      </act>
  +    </match>
  +  </match>
  +
  +>
  +> ----------------------------------------------------------------------------
  +> ---------
  +>
  +> So what would I want to see in a Cocoon-Application framework ???
  +>
  +> Well actions are independent of resources and exist in a separate namespace.
  +>
  +> Each request can in theory result in a action-pipeline.
  +>
  +> Each action can add stuff to it's context (or Environment).
  +>
  +> Each action can in theory short-cut the action pipeline and move to another
  +> action-resource pipeline and also store remaining submitted actions as
  +> latent actions.
  +>
  +> An action pipeline must not necessarily be associated with a resource (it
  +> should instead be able to specify a resource that it goes to post processing).
  +>
  +> It may also be good to have an action that's sole purpose is to extract
  +> explicit action requests and execute/store them (ActionExtractorAction +
  +> ActionDispatcherAction ???)
  +
  +Please answer these question yourself after you've read my explanations.
  +
  +> But anyways I mean in no way to imply C2 is bad and if you want to add
  +> hooks into sitemap generation to allow for this sort of stuff (or even
  +> better do it yourself ;>) I would gladly switch all my development across
  +> 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 you're right
  +implementing general actions for general usage is another thing.
  +
  +Giacomo
  
  
  
  1.5       +11 -11    cocoon-site/site/2.1/userdocs/concepts/index.html
  
  Index: index.html
  ===================================================================
  RCS file: /home/cvs/cocoon-site/site/2.1/userdocs/concepts/index.html,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- index.html	21 May 2003 15:23:37 -0000	1.4
  +++ index.html	21 May 2003 17:47:57 -0000	1.5
  @@ -340,10 +340,10 @@
   </ul>
   </li>
   <li>
  -<a href="#%40Name%40+Configuration.">@Name@ Configuration.</a>
  +<a href="#Apache+Cocoon+Configuration.">Apache Cocoon Configuration.</a>
   </li>
   <li>
  -<a href="#%40Name%40+Work+Area">@Name@ Work Area</a>
  +<a href="#Apache+Cocoon+Work+Area">Apache Cocoon Work Area</a>
   </li>
   <li>
   <a href="#Use+with+Tomcat">Use with Tomcat</a>
  @@ -355,7 +355,7 @@
   <div style="margin-left: 0 ; border: 2px">
   <p>
        This document is intended for both Users and Developers 
  -     and presents an overall picture of @Name@.
  +     and presents an overall picture of Apache Cocoon.
        </p>
   <ul>
          
  @@ -410,7 +410,7 @@
   <li>
            
   <a href="#cocoon-configuration">
  -           @Name@ Configuration.
  +           Apache Cocoon Configuration.
            </a>
          
   </li>
  @@ -418,7 +418,7 @@
   <li>
            
   <a href="#work-area">
  -           @Name@ Work Area.
  +           Apache Cocoon Work Area.
            </a>
          
   </li>
  @@ -506,13 +506,13 @@
   <h4>Separation of content, style, logic and management functions in an XML content
based web site (and web services).</h4>
   <div style="margin-left: 0 ; border: 2px">
   <div align="center">
  -<img class="figure" alt="The @Name@ Pyramid Model of Contracts" src="images/pyramid-model.gif"
height="159" width="313"></div>
  +<img class="figure" alt="The Apache Cocoon Pyramid Model of Contracts" src="images/pyramid-model.gif"
height="159" width="313"></div>
   </div>
   <a name="N100D3"></a><a name="Data+Mapping"></a>
   <h4>Data Mapping</h4>
   <div style="margin-left: 0 ; border: 2px">
   <div align="center">
  -<img class="figure" alt="The @Name@ Data Mapping" src="images/data-mapping.gif" height="174"
width="339"></div>
  +<img class="figure" alt="The Apache Cocoon Data Mapping" src="images/data-mapping.gif"
height="174" width="339"></div>
   </div>
   </div>
     
  @@ -1031,8 +1031,8 @@
   </div>
     
   <a name="cocoon-configuration"></a>
  -  <a name="N10378"></a><a name="%40Name%40+Configuration."></a>
  -<h3>@Name@ Configuration.</h3>
  +  <a name="N10378"></a><a name="Apache+Cocoon+Configuration."></a>
  +<h3>Apache Cocoon Configuration.</h3>
   <div style="margin-left: 0 ; border: 2px">
   <p>Cocoon is highly configurable. Main configuration files, assuming Cocoon deployment
as a servlet in a servlet container, are (directory locations assume Tomcat servlet container):</p>
   <ul>
  @@ -1053,8 +1053,8 @@
   </div>
     
   <a name="work-area"></a>
  -  <a name="N103A4"></a><a name="%40Name%40+Work+Area"></a>
  -<h3>@Name@ Work Area</h3>
  +  <a name="N103A4"></a><a name="Apache+Cocoon+Work+Area"></a>
  +<h3>Apache Cocoon Work Area</h3>
   <div style="margin-left: 0 ; border: 2px">
   <p>Cocoon produces execution log entries for debugging/auditing.</p>
   <ul>
  
  
  
  1.2       +502 -430  cocoon-site/site/2.1/userdocs/concepts/index.pdf
  
  	<<Binary file>>
  
  
  1.2       +55 -55    cocoon-site/site/2.1/userdocs/generators/telnet.txt
  
  Index: telnet.txt
  ===================================================================
  RCS file: /home/cvs/cocoon-site/site/2.1/userdocs/generators/telnet.txt,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- telnet.txt	15 May 2003 04:19:38 -0000	1.1
  +++ telnet.txt	21 May 2003 17:47:57 -0000	1.2
  @@ -1,55 +1,55 @@
  -POST /cocoon/request1 HTTP/1.1
  -Content-Type: text/plain
  -Content-Length:1513
  -
  -<?xml version="1.0"?>
  -<Orders>
  -	<OrderID>20259</OrderID>
  -	<CustomerID>WWWWWWW</CustomerID>
  -	<EmployeeID>6</EmployeeID>
  -	<OrderDate>2001-05-05 00:00:00</OrderDate>
  -	<RequiredDate>2001-06-05 00:00:00</RequiredDate>
  -	<ShippedDate>2001-06-01 00:00:00</ShippedDate>
  -	<ShipVia>1</ShipVia>
  -	<Freight>11.6100</Freight>
  -	<ShipName>Thoms White</ShipName>
  -	<ShipAddress>Somestr. 48</ShipAddress>
  -	<ShipCity>Munster</ShipCity>
  -	<ShipRegion>West</ShipRegion>
  -	<ShipPostalCode>00000</ShipPostalCode>
  -	<ShipCountry>Germany</ShipCountry>
  -	<OrderDetails>
  -		<OrderID>20259</OrderID>
  -		<ProductID>51</ProductID>
  -		<UnitPrice>42.4000</UnitPrice>
  -		<Quantity>40</Quantity>
  -		<Discount>0.0</Discount>
  -	</OrderDetails>
  -	<OrderDetails>
  -		<OrderID>20259</OrderID>
  -		<ProductID>14</ProductID>
  -		<UnitPrice>18.6000</UnitPrice>
  -		<Quantity>9</Quantity>
  -		<Discount>0.0</Discount>
  -	</OrderDetails>
  -	<OrderDetails>
  -		<OrderID>20259</OrderID>
  -		<ProductID>7</ProductID>
  -		<UnitPrice>12.4000</UnitPrice>
  -		<Quantity>30</Quantity>
  -		<Discount>0.0</Discount>
  -	</OrderDetails>
  -	<Customers>
  -		<CustomerID>WWWWWWW</CustomerID>
  -		<CompanyName>Thomas White</CompanyName>
  -		<ContactName>Karin Black</ContactName>
  -		<ContactTitle>Marketing Manager</ContactTitle>
  -		<Address>Somestr. 48</Address>
  -		<City>Munster</City>
  -		<Region>West</Region>
  -		<PostalCode>00000</PostalCode>
  -		<Country>Germany</Country>
  -		<Phone>xxxx-yyyyyy</Phone>
  -		<Fax>xxxx-yyyyyy</Fax>
  -	</Customers>
  -</Orders>
  \ No newline at end of file
  +POST /cocoon/request1 HTTP/1.1
  +Content-Type: text/plain
  +Content-Length:1513
  +
  +<?xml version="1.0"?>
  +<Orders>
  +	<OrderID>20259</OrderID>
  +	<CustomerID>WWWWWWW</CustomerID>
  +	<EmployeeID>6</EmployeeID>
  +	<OrderDate>2001-05-05 00:00:00</OrderDate>
  +	<RequiredDate>2001-06-05 00:00:00</RequiredDate>
  +	<ShippedDate>2001-06-01 00:00:00</ShippedDate>
  +	<ShipVia>1</ShipVia>
  +	<Freight>11.6100</Freight>
  +	<ShipName>Thoms White</ShipName>
  +	<ShipAddress>Somestr. 48</ShipAddress>
  +	<ShipCity>Munster</ShipCity>
  +	<ShipRegion>West</ShipRegion>
  +	<ShipPostalCode>00000</ShipPostalCode>
  +	<ShipCountry>Germany</ShipCountry>
  +	<OrderDetails>
  +		<OrderID>20259</OrderID>
  +		<ProductID>51</ProductID>
  +		<UnitPrice>42.4000</UnitPrice>
  +		<Quantity>40</Quantity>
  +		<Discount>0.0</Discount>
  +	</OrderDetails>
  +	<OrderDetails>
  +		<OrderID>20259</OrderID>
  +		<ProductID>14</ProductID>
  +		<UnitPrice>18.6000</UnitPrice>
  +		<Quantity>9</Quantity>
  +		<Discount>0.0</Discount>
  +	</OrderDetails>
  +	<OrderDetails>
  +		<OrderID>20259</OrderID>
  +		<ProductID>7</ProductID>
  +		<UnitPrice>12.4000</UnitPrice>
  +		<Quantity>30</Quantity>
  +		<Discount>0.0</Discount>
  +	</OrderDetails>
  +	<Customers>
  +		<CustomerID>WWWWWWW</CustomerID>
  +		<CompanyName>Thomas White</CompanyName>
  +		<ContactName>Karin Black</ContactName>
  +		<ContactTitle>Marketing Manager</ContactTitle>
  +		<Address>Somestr. 48</Address>
  +		<City>Munster</City>
  +		<Region>West</Region>
  +		<PostalCode>00000</PostalCode>
  +		<Country>Germany</Country>
  +		<Phone>xxxx-yyyyyy</Phone>
  +		<Fax>xxxx-yyyyyy</Fax>
  +	</Customers>
  +</Orders>
  
  
  

Mime
View raw message