cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <Giacomo.P...@pwr.ch>
Subject Re: Action proposal
Date Sat, 16 Sep 2000 12:48:33 GMT
Peter Donald wrote:
> 
> I finally got around to looking at action framework to see if it fitted all
> my needs. I tested it against the following applications I have developed
> in past.
> 

<snip/>

> Guess what C2 + proposed actions == 100% success :P

<snip/>

> Your proposed mapping via below is perfect for implicit actions
> 
>  <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>
> 
> And probably the best way to define actions is just like you do with other
> components - ie
> 
>   <map:action default="none">
>    <map:action name="session-validator"
> src="org.apache.cocoon.action.MySessionValidator"/>
> 
>    <map:action name="admin-authorizer"
> src="org.apache.cocoon.action.MyAuthorizer">
>      <identity-manager
> name="org.apache.avalon.blocks.identity.SimpleIdentityManager" />
>    </map:action>
> 
>    <map:action name="validate-form"
> src="org.apache.cocoon.action.MyFormValidator"/>
>      <schema>my-path-to-schema-resource.xsd</schema>
>    </map:action>
> 
>    <map:action name="save-form"  src="org.apache.cocoon.action.MyFormSaver"/>
>      <database> ....... </database>
>    </map:action>
> 
>   </map:action>
> 
> Now when a user tries to access a resource what happens ?
> First cocoon will build up a list or chain of implicit actions. (Implicit
> meaning those that are defined via the sitemap). Then it will parse
> cookies/post/get input to grab the explicit user submitted actions and

Cocoon is not (or better will not) parse any cookies/post/get things.
This is delegated to the sitemap components because it is environment
specific.

> build an action chain out of them. However we don't want the user to be
> able to submit arbitary actions - we want control over this for security
> reasons - so this leads us to the next step: Action chains in sitemap
> 
> <map:action-chains default="none">

No default. I think it goes at the level like <map:resources> and
<map:views>

>   <map:action-chain name="data-entry">
>     <map:perform action="validate-form" />
>     <map:perform action="save-form" />
>   </map:action-chain>
> 
>   <map:action-chain name="secure-data-entry">
>     <map:perform action="session-validator" />
>     <map:perform action="admin-authorizer" />
>     <map:perform action="validate-form" />
>     <map:perform action="save-form" />
>   </map:action-chain>
> 
>   <map:action-chain name="example-action-to-perform-linking">
>     <map:perform action="session-validator" />
>     <map:perform chain="action-linked-to" />
>   </map:action-chain>
> 
>   <map:action-chain name="action-linked-to">
>     <map:perform name="some-action" />
>     <map:perform name="another-action" />
>   </map:action-chain>
> 
> </map:action-chains>

To be consistent with the rest of the sitemap syntax I suggest using:

  <map:action-chains>
    <map:action-chain name="data-entry">
<!--
      The type= attribute references a action defined in the 
      components actions section
-->
      <map:perform type="validate-form" />
      <map:perform type="save-form" />
    </map:action-chain>

    <map:action-chain name="example-action-to-perform-linking">
<!-- 
      The chain= attribute references an action-chain
-->
      <map:perform type="session-validator" />
      <map:perform chain="action-linked-to" />
    </map:action-chain>
  
    <map:action-chain name="action-linked-to">
      <map:perform type="some-action" />
      <map:perform type="another-action" />
    </map:action-chain>
  
  </map:action-chains>

> The one last requirement is that remainin explicit actions in chain can be
> saved and deferred by some means programmatically.

I suggest leave this for later and concentrate on actions and
action-chains.

> So in conclusion this is what C2 needs:
> 
> * building implict action chain (as per Giacomo's proposal)
> * building explicitly requested action chain (as per above or another method)
> * some way to push explicitly submitted actions onto stack and then pop and
> execute them later

Ok, let me summarize to see if I grasped it:

Explicit actions are those presented to the user in kinda control panels
or alike (do that, check this, etc.). From the sitemap point of view
they can be collected into action-chains. In the pipeline section of the
sitemap explicit Actions and especially action-chains do not have a way
to control sitemap evaluation flow by means of the List object an Action
may return and thus cannot have nested elements from the sitemap
namespace (Parameters should be allowed). Of course they can communicate
with other sitemap component ddduring pipeline evaluation time through
the objectModel Map. 

Implicit actions are those which do processings like data validation and
signal the sitemap engine if nested elements are to be evaluated or not
by means of returning a List object or null. The List object is used to
substitute occurences of {n} in src attributes of nested sitemap
components (Generators, Transformers, Readers). The n in {n} is a number
representing the index into the last List returned by a component to the
sitemap engine. An expression like {../2} means the 2. element of the
List returned by the parent component of the last components returning a
List (and so on).

The sitemap engine is only able to distinguish action-chains from
actions but not explicit actions from implicit action. The sitemap
engine will call ations in an action-chain in the order they are
defined. It's the responsability of the action itself to determine what
processing it should be doing. 

> There is still one application I haven't tested against but other than that
> I *believe* the proposal covers it all ? Anyone else out there who needs
> other features ?
> 
> Anyways I will have a look at it some more next weekend (if I remember
> design to other site :P)
> 
> One thing I did notice was that my sitemap became very very very very
> verbose. For instance on one of my apps my control screen is capable of
> submitting about 36 different types of actions. Is it possible in C2 to
> mount sitemaps at certain anchor points
> (ie /myapp1 ---> sitemap1, /myapp2 ---> sitemap2). If so then this point is
> irrelevent otherwise there was a serious verbosity problems :P

Yes, there is the <map:mount> element exactly for this purpose. For
further reduction off verbosity we plan to make subsitemaps inherit
components from their parent sitemaps. But for this we need some kind of
ComponentManagers able to be hierarchicaly structured and also able to
handle pools of components because most of them are not ThreadSafe
(Sharable) but Poolable. But this is a question I've put on the avalon
list.

Any comments?

Giacomo

-- 
PWR GmbH, Organisation & Entwicklung      Tel:   +41 (0)1  856 2202
Giacomo Pati, CTO/CEO                     Fax:   +41 (0)1  856 2201
Hintereichenstrasse 7                     Mobil: +41 (0)78 759 7703
CH-8166 Niederweningen                    Mailto:Giacomo.Pati@pwr.ch
                                          Web:   http://www.pwr.ch

Mime
View raw message