cocoon-dev mailing list archives

On Sat, Sep 16, 2000 at 04:18:14PM +0200, Stefano Mazzocchi wrote:
> 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.
> >
> > * 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>
>
> Hmmmm, I'm not sure I like this structure.... people might get the
> impression that more than one generation can take place which is indeed
> not the case.
Yes, the example above is _wrong_. It would always generate the
login resource. But this has nothing to do with the Actions. It
could also happen with the components we have today. Maybe we
should throw an error if a second generator will be selected to
make the sitemap admin aware of it. What do you think?
> > 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>
>
> Yep
>
> > 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.
>
> Sounds good even if I have NO idea of how to implement this into the
> sitemap... Giacomo, got any ideas handy?
A action-chain can be implemented as a separate method (like we
do with views and resources) and called during sitemap request
evaluation. But I don't like the deferring of action in the sitemap.
it would introduce some kind of session/state handling which is IMHO
not the concern of the sitemap. I think it must be the components
which have to take care of it.
> > 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
>
> We are perfectly aware of verbosity issues and we designed it to be both
> "mountable" and "cascading". This means that you can have a structure
> like this
>
> / -> root sitemap
> /docs -> docs sitemap (inherits components located in the root sitemap)
> /docs/press -> press sitemap (inherits component located in docs, and
> cascaded in root)
>
> and so on. I don't know if this is already implemented (Giacomo?) but
> for sure we need to do this before release otherwise we have serious
> scalability problems.
The mounting of subsitemaps is already implemented and tested.
Component inheritance is beeing deferred because we need the new
Avalon release to implement it. It requires SitemapComponentManagers
that can be arranged in a hierarchical way and they must be able to
manage all kinds of sitemap components the right way by means of
Poolable, Recyclable, Sharable, Clonable etc. interfaces.
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