cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Action proposal
Date Sun, 17 Sep 2000 01:02:32 GMT
Giacomo Pati wrote:
> 
> 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?

Yes, the sitemap should be validated in terms of pipeline structure.
something like

 generator -> generator -> serializer -> transformer

is clearly wrong but sometimes it's hard to see if select/act/match and
friends get in the way.
 
> > > 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.

This is the key point, IMO, and I do see sitemap and actions as
"rotations" of the same solution space... in non-mathematical terms:
both allow to cover all possibility, but one is easier for something
(publishing) the other is easier for something else (web-apps).

But rotations are NOT orthogonal, are just a different view of the same
stuff.

I have to think more about this issue, I still have to "see" the thing
from the outside and it's too foggy out there.
 
> > > 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.

Ok, cool.

Do me a favor: download the latest Avalon CVS and see if it works for
you. If not, make sure you tell them sooner rather than later... I don't
want to wait for another Avalon release.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------



Mime
View raw message