cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <dona...@mad.scientist.com>
Subject Action proposal
Date Sat, 16 Sep 2000 03:56:47 GMT
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.

* Web-Based testing: 
  - lots of implicit actions (actions mapped via which resource they access)
  - lots of explicit actions because users can perform actions
  - lots of different complexities (different roles for different people,
    different access privlidges)

In it had things like the ability to change tests, change format, publish
answers, block questions of certain tests, allow certain users to sit from
certain IP addresses, lock down timing of tests etc etc

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

* Web-based groupware:
  - lots of implicit actions
  - very few explicit actions

C2 + proposed actions == 100% success

* Front end to database
  - very few implicit actions
  - lots of explicit actions

C2 + proposed actions == 100% success

There is one more application I still have to test but I forgot to bring
home design doc so I will do it next week :P

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
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">

  <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>

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

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

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



Cheers,

Pete

*------------------------------------------------------*
| "Nearly all men can stand adversity, but if you want |
| to test a man's character, give him power."          |
|       -Abraham Lincoln                               |
*------------------------------------------------------*

Mime
View raw message