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 Sun, 17 Sep 2000 09:48:19 GMT
Stefano Mazzocchi wrote:
> 
> 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.

Yup!

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

Some parts of the proposal is still foggy to me too. Yes, please, think
about it too and suggest you visions (they are always very good) because
I see that Pete is far at the surface of the sitemap architecture which
is good for some aspects (because we might be too far inside) but is
sometimes a pain to explain how is should work :)) (hey, this is NO
offense to you Pete, its really allwright how it is :P)

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

I'm already there (you should have seen my questions on the avalon list)
:P
I also will completing the sitemap docs I've begun. Please be patient
with me I have a lot of other work to do these weeks.

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