You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Lassi Immonen <li...@urova.fi> on 2000/09/07 17:18:32 UTC
[C2]Access control using sitemap
Hi,
I really would like to use Cocoon2 in our web/content management project.
Could someone give some advice how to implement user identification/access
control using sitemap? It has to be somekind of selector and all requests
has to go through same point?
Thanks
Lassi Immonen
Re: [C2]Access control using sitemap
Posted by Nicola Ken Barozzi <ni...@supereva.it>.
From: "Giacomo Pati" <Gi...@pwr.ch>
> Lassi Immonen wrote:
> >
> > > > I really would like to use Cocoon2 in our web/content management
> > project.
> > > > Could someone give some advice how to implement user
> > identification/access
> > > > control using sitemap? It has to be somekind of selector and all
> > requests
> > > > has to go through same point?
> > >
> > > IIRC, there was a policy to not handle authorisation and authentication
> > > in the sitemap, and let the web server handle that.
> >
> > Is there any reason not to use sitemap as basis of creating access control
> > system?
>
> Not really. Nobody stops you from doing so. But wouldn't you think that
> especially authentication is better done at the servlet container side?
> It offers may ways to do so, from basic and form based authentication to
> strong client side authentication using certificates.
I had a discussion with lrich on the user list on this one.
He insisted that non-container based auth-auth is better 4 him and wrote
a taglib.
Personally I agree with Giacomo, but a system that uses both is welcome IMHO.
> > It's not going to be only access control, I plan to have ability to produce
> > dynamic content based on userprofile in database.
>
> IMHO this is another part. Usually its called authorisation. Off course
> this is something that only your application can determine and would
> clearly fit into the sitemap or better into XSP pages.
Yes, it's explained clearlt on the J2EE site.
For the third time ;-) I attatch my simple example of XSP authorization
taglib used with servlet container security.
Believe me, it's very easy! :-)
Anyway we could talk about integrating the approaches for a uniform
system, although I feel it's more to write in the docs than in the codes.
It's very important nevertheless.
nicola_ken
Nicola Ken Barozzi - AISA Industries S.p.A
http://www.aisaindustries.it/
Via Leonardo da Vinci,2 Ticengo (CR) Italy
Research Activity:
Politecnico di Milano - Dipartimento di Meccanica
Piazza Leonardo da Vinci, n.32 - 20133 Milano (Italy)
Re: [C2]Access control using sitemap
Posted by Giacomo Pati <Gi...@pwr.ch>.
Lassi Immonen wrote:
>
> > > I really would like to use Cocoon2 in our web/content management
> project.
> > > Could someone give some advice how to implement user
> identification/access
> > > control using sitemap? It has to be somekind of selector and all
> requests
> > > has to go through same point?
> >
> > IIRC, there was a policy to not handle authorisation and authentication
> > in the sitemap, and let the web server handle that.
>
> Is there any reason not to use sitemap as basis of creating access control
> system?
Not really. Nobody stops you from doing so. But wouldn't you think that
especially authentication is better done at the servlet container side?
It offers may ways to do so, from basic and form based authentication to
strong client side authentication using certificates.
> It's not going to be only access control, I plan to have ability to produce
> dynamic content based on userprofile in database.
IMHO this is another part. Usually its called authorisation. Off course
this is something that only your application can determine and would
clearly fit into the sitemap or better into XSP pages.
>
> >
> > However, you could write a selector to handle it, yes. Off the top of
> > my head: just wrap all pages to be protected and test the uses
> > credentials, if it fails redirect to a "permission denied" page.
>
> I cannot see any other examples as to start other than recently added
> BrowserSelector, so would my "AccessSelector" work like:
>
> <map:selector name="access" factory="my.AccessSelector">
> ??
> </map:selector>
I don't think this is a good example using a factory class. Probably a
normal class is good enought for that. Please get in touch with the
difference between a selector/matcher factory and a normal class by
reading the Interfaces.
> and
>
> <map:match pattern="mysite/*">
> <map:select type="access">
> <map:when test="granted">
> ?? how to use this as starting point to all my content residing under
> mysite/
> </map:when>
> <map:otherwise>
> <map:redirect-to uri="login"/>
> </map:otherwise>
> </map:select>
> </map:match>
Yes, more or less that way. We have to prove if web application can be
written in a MVC manner using selectors/matchers as Controllers of the
Model and XSP pages as Views of the Model.
> And in AccessSelector code, can I access database through JDBC? It's not
> very clear to me how to maintain for example my custom Users-object live
> somewhere with possible connection to database and accessible from
> AccessSelector? Any advice?
Any sitemap component has full access to the objectModel (means Request,
Response, Context and thus Session) and can make whatever seems
appropriate (even JDBC access to databases).
> Anyway from BrowserSelector code I can see how one can get request object.
Yes, have a look at CocoonServlet to see what else is in the
objectModel.
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
Re: [C2]Access control using sitemap
Posted by Giacomo Pati <Gi...@pwr.ch>.
donaldp@mad.scientist.com wrote:
>
> On Mon, 11 Sep 2000, Giacomo Pati wrote:
>
> > Peter Donald wrote:
> > >
> > > At 10:43 10/9/00 +0200, Giacomo Pati wrote:
> > > >The example above is probably misleading because we don't have a Action
> > > >component in the sitemap so far. Generally speaking I think a Sitemap
> > > >Action is an object that acts upon an application model based on data
> > > >supplied by the environments objectModel (ie Request). It's its
> > > >responsability to make some data available to the Sitemap engine as
> > > >further selection/matching criteria (a List object) as well as in the
> > > >objectModel for other sitemap components
> > > ... snip ...
> > >
> > > yes I like this :P. I think it does all that I would require - thou I will
> > > try and break it next weakend to see if I can :P
> > ^^^^^^^
> > Where is your weak end ;)
>
> ack ! :P
>
> > What you mean with "try and break". If you mean something like
> > implementing it, so wait. I have a C2 version on my hd that I use to
> > experiment with the mentioned Action component to see if this would work
> > like excpected (you must know I mostly can't resist testing things that
> > are easy and quickly to implemented ;-). I had this extension to C2 in
> > mind for a couple of days.
>
> kewl. By try and break - I merely meant mental exercises -
> go over all the sites I created and try to see if that
> approach could work on all of them. If it doesn't break then
> I try to think of wierd and wonderful scenarios that it may
> break in - or be too much work and try to figure out if said
> scenario is
> a> likely to occur
> b> can be done a different way better
> c> is important to support
>
> > > not really - it is impossible for an individual action to "discover" the
> > > other actions as the data may come in via post/get/cookies/other and is
> > > really a container issue - where actions are contained. There needs to be a
> > > way to grab all actions that have been passed to webapp (rather than those
> > > that are implicit via sitemap) and store them.
> >
> > Oh, you mean something like pushing the current request onto a stack,
> > executing an other request (pipeline) and if it's signaling ok
> > re-request from that stack afterwards?
>
> yep essentially.
>
> Well anyways I will have a shot this WEEKend.
So I'm anxiously awaiting your suggestions.
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
Re: [C2]Access control using sitemap
Posted by do...@mad.scientist.com.
On Mon, 11 Sep 2000, Giacomo Pati wrote:
> Peter Donald wrote:
> >
> > At 10:43 10/9/00 +0200, Giacomo Pati wrote:
> > >The example above is probably misleading because we don't have a Action
> > >component in the sitemap so far. Generally speaking I think a Sitemap
> > >Action is an object that acts upon an application model based on data
> > >supplied by the environments objectModel (ie Request). It's its
> > >responsability to make some data available to the Sitemap engine as
> > >further selection/matching criteria (a List object) as well as in the
> > >objectModel for other sitemap components
> > ... snip ...
> >
> > yes I like this :P. I think it does all that I would require - thou I will
> > try and break it next weakend to see if I can :P
> ^^^^^^^
> Where is your weak end ;)
ack ! :P
> What you mean with "try and break". If you mean something like
> implementing it, so wait. I have a C2 version on my hd that I use to
> experiment with the mentioned Action component to see if this would work
> like excpected (you must know I mostly can't resist testing things that
> are easy and quickly to implemented ;-). I had this extension to C2 in
> mind for a couple of days.
kewl. By try and break - I merely meant mental exercises -
go over all the sites I created and try to see if that
approach could work on all of them. If it doesn't break then
I try to think of wierd and wonderful scenarios that it may
break in - or be too much work and try to figure out if said
scenario is
a> likely to occur
b> can be done a different way better
c> is important to support
> > not really - it is impossible for an individual action to "discover" the
> > other actions as the data may come in via post/get/cookies/other and is
> > really a container issue - where actions are contained. There needs to be a
> > way to grab all actions that have been passed to webapp (rather than those
> > that are implicit via sitemap) and store them.
>
> Oh, you mean something like pushing the current request onto a stack,
> executing an other request (pipeline) and if it's signaling ok
> re-request from that stack afterwards?
yep essentially.
Well anyways I will have a shot this WEEKend.
:P
Cheers,
Pete
*--------------------------------------------------*
| Latrobe University, | Does the name 'Pavlov' |
| Bundoora, Australia | ring a bell ? |
*--------------------------------------------------*
Re: [C2]Access control using sitemap
Posted by Giacomo Pati <Gi...@pwr.ch>.
Peter Donald wrote:
>
> At 10:43 10/9/00 +0200, Giacomo Pati wrote:
> >The example above is probably misleading because we don't have a Action
> >component in the sitemap so far. Generally speaking I think a Sitemap
> >Action is an object that acts upon an application model based on data
> >supplied by the environments objectModel (ie Request). It's its
> >responsability to make some data available to the Sitemap engine as
> >further selection/matching criteria (a List object) as well as in the
> >objectModel for other sitemap components
> ... snip ...
>
> yes I like this :P. I think it does all that I would require - thou I will
> try and break it next weakend to see if I can :P
^^^^^^^
Where is your weak end ;)
What you mean with "try and break". If you mean something like
implementing it, so wait. I have a C2 version on my hd that I use to
experiment with the mentioned Action component to see if this would work
like excpected (you must know I mostly can't resist testing things that
are easy and quickly to implemented ;-). I had this extension to C2 in
mind for a couple of days.
> >> There is also the idea of latent actions. For instance the latent Action is
> >> transmitted between end-user and cocoon until they are activated. Actions
> >> may also be made latent (or deactivated) in a couple of cases. Like when
> >> you try to submit form but are not logged in - it will save action/form
> >> data (or put action into latent state) and then after login commit the
> >> action (or re-activate action).
> >
> >Isn't this a matter how components play together?
>
> not really - it is impossible for an individual action to "discover" the
> other actions as the data may come in via post/get/cookies/other and is
> really a container issue - where actions are contained. There needs to be a
> way to grab all actions that have been passed to webapp (rather than those
> that are implicit via sitemap) and store them.
Oh, you mean something like pushing the current request onto a stack,
executing an other request (pipeline) and if it's signaling ok
re-request from that stack afterwards?
> >> * Then specific resources webapp/a.xml, webapp/b.xml and webapp/admin/c.xml
> >> must run FormValidationAction with appropriate form schema and the
> >> apprporiate FormDBEntryAction
> >
> >Didn't get the last one? What is a FormDBEntryAction for? Probably an
> >XSP page?
>
> nope - it is just an action that grabs stuff from environment and places it
> in a database. I usually seperate it from form validation and consider this
> form saving :P
Should be easy with a separate Action component. Maybe such a component
can be customized at configuration time or with Parameters at runtien to
suit the need. I don't want to go that far to say we need Actions being
composed out of several other Actions (well sound thrilling but maybe
for one of the next releases :).
> >> * A user can also arbitarily submit an action from any page (via post
> >> request or perhaps a ?action=blah tacked onto URL) that must be executed.
> >
> > <match type="uri" pattern="webapp/**">
> > <act type="session-validation"/>
> > <match type="uri" pattern="webapp/admin">
> > <act type="assign-role">
> > <select type="role-selector">
> > <when test="admin">
> > <match type="uri" pattern="webapp/admin/c.xml">
> > <act type="form-validation src="admin/form-schema-c.xsd"/>
> > <!-- the following next-page action has knowledge of the
> > sequence of pages and returns a List with the first
> >element
> > corresponding to the "next page" appropriate
> >depending on
> > values in the objectModel signaling successful
> >validation by
> > the previous action (type="form-validation"). The
> >following
> > three lines could be put into a sitemap resource
> >definition
> > and replaced by <redirect-to resource="next-page"/>
> > -->
> > <act type="next-page">
> > <generate src="{1}"/>
> > </act>
> > </match>
> > <otherwise>
> > <match type="uri-regexp" pattern="webapp/(a|b)\.xml">
> > <act type="form-validation src="form-schema-{1}.xsd"/>
> > <act type="next-page">
> > <generate src="{1}"/>
> > </act>
> > </match>
> > </when>
> > </select>
> > </act>
> > </match>
> > </match>
>
> This could work real good :P
>
> >> It may also be good to have an action that's sole purpose is to extract
> >> explicit action requests and execute/store them (ActionExtractorAction +
> >> ActionDispatcherAction ???)
> >
> >Please answer these question yourself after you've read my explanations.
>
> ActionExtraction is really a container concern and thus dispatching can be
> either a container or else contained concern (much like servlet dispatching
> via /servlet/<servlet-name> is done via another servlet).
>
> Anyways I will try to come up with problems with this approach (if any) and
> try a few thought experiments :P
I'm really awaiting your thoughts about it :)
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
Re: [C2]Access control using sitemap
Posted by Peter Donald <do...@mad.scientist.com>.
At 10:43 10/9/00 +0200, Giacomo Pati wrote:
>The example above is probably misleading because we don't have a Action
>component in the sitemap so far. Generally speaking I think a Sitemap
>Action is an object that acts upon an application model based on data
>supplied by the environments objectModel (ie Request). It's its
>responsability to make some data available to the Sitemap engine as
>further selection/matching criteria (a List object) as well as in the
>objectModel for other sitemap components
... snip ...
yes I like this :P. I think it does all that I would require - thou I will
try and break it next weakend to see if I can :P
>> There is also the idea of latent actions. For instance the latent Action is
>> transmitted between end-user and cocoon until they are activated. Actions
>> may also be made latent (or deactivated) in a couple of cases. Like when
>> you try to submit form but are not logged in - it will save action/form
>> data (or put action into latent state) and then after login commit the
>> action (or re-activate action).
>
>Isn't this a matter how components play together?
not really - it is impossible for an individual action to "discover" the
other actions as the data may come in via post/get/cookies/other and is
really a container issue - where actions are contained. There needs to be a
way to grab all actions that have been passed to webapp (rather than those
that are implicit via sitemap) and store them.
>> * Then specific resources webapp/a.xml, webapp/b.xml and webapp/admin/c.xml
>> must run FormValidationAction with appropriate form schema and the
>> apprporiate FormDBEntryAction
>
>Didn't get the last one? What is a FormDBEntryAction for? Probably an
>XSP page?
nope - it is just an action that grabs stuff from environment and places it
in a database. I usually seperate it from form validation and consider this
form saving :P
>> * A user can also arbitarily submit an action from any page (via post
>> request or perhaps a ?action=blah tacked onto URL) that must be executed.
>
> <match type="uri" pattern="webapp/**">
> <act type="session-validation"/>
> <match type="uri" pattern="webapp/admin">
> <act type="assign-role">
> <select type="role-selector">
> <when test="admin">
> <match type="uri" pattern="webapp/admin/c.xml">
> <act type="form-validation src="admin/form-schema-c.xsd"/>
> <!-- the following next-page action has knowledge of the
> sequence of pages and returns a List with the first
>element
> corresponding to the "next page" appropriate
>depending on
> values in the objectModel signaling successful
>validation by
> the previous action (type="form-validation"). The
>following
> three lines could be put into a sitemap resource
>definition
> and replaced by <redirect-to resource="next-page"/>
> -->
> <act type="next-page">
> <generate src="{1}"/>
> </act>
> </match>
> <otherwise>
> <match type="uri-regexp" pattern="webapp/(a|b)\.xml">
> <act type="form-validation src="form-schema-{1}.xsd"/>
> <act type="next-page">
> <generate src="{1}"/>
> </act>
> </match>
> </when>
> </select>
> </act>
> </match>
> </match>
This could work real good :P
>> It may also be good to have an action that's sole purpose is to extract
>> explicit action requests and execute/store them (ActionExtractorAction +
>> ActionDispatcherAction ???)
>
>Please answer these question yourself after you've read my explanations.
ActionExtraction is really a container concern and thus dispatching can be
either a container or else contained concern (much like servlet dispatching
via /servlet/<servlet-name> is done via another servlet).
Anyways I will try to come up with problems with this approach (if any) and
try a few thought experiments :P
Cheers,
Pete
*------------------------------------------------------*
| "Nearly all men can stand adversity, but if you want |
| to test a man's character, give him power." |
| -Abraham Lincoln |
*------------------------------------------------------*
Re: Action proposal
Posted by Stefano Mazzocchi <st...@apache.org>.
Giacomo Pati wrote:
> <map:pipeline>
> <map:match pattern="myapp/**">
> <!-- this action will parse the cookies/post/get data
> and make the result of that examination available
> 1. as state information in the objectModel Map
> 2. by returning resource specifications in a List
> -->
> <map:act chain="parse-input-and-make-information-available-chain">
> <!-- this selector will choose among the information
> made available in the objectModel Map by the previous
> Action(s).
> -->
> <map:select type="input-checker-selector">
> <map:when test="show-index">
> <!-- this generator is charged with the appropriate index
> resource specified in the List returned by the Action
> above.
> -->
> <map:generate src="myapp/{1}/index"/>
> </map:when>
> <map:when test="kill-task">
> <!-- this action kills a task that was spawned previously
> by another action using data make available by the Action
> above.
> -->
> <map:act type="task-killer"/>
> <map:generate src="myapp/{1}/task-killing-status-page"/>
> </map:when>
> <map:otherwise>
> <map:generate src="myapp/login"/>
> </map:otherwise>
> </select>
> </map:act>
> <map:transform src="myapp/general.xsl"/>
> <map:serialize type="html"/>
> </map:match>
> <map:handle-error>
> <map:transform src="myapp/error-transformer.xsl"/>
> <map:transform src="myapp/general.xsl"/>
> <map:serialize type="html"/>
> </map:handle-error>
> </map:pipeline>
Hmmm, this reminds me of one of the my early sitemap components when I
was designing it on the whiteboard: I called it "sensor", it was
supposed to "sense" the environment/request/whatever and behave on it.
Then the other components would have been influenced by it's action.
Well, to be honest, I threw it away because I couldn't come up with a
better name, but I agree that "actor/action/act" is much better (even if
much more general and, sometimes, misleading).
But there was another reason why I threw it away.... but I can't
remember tonight (it's 3am I should get some sleep)
Anyway, it looks cool... I just have to spend more cycles on this... ok,
back on the whiteboard....
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: Action proposal
Posted by Giacomo Pati <Gi...@pwr.ch>.
On Sun, Sep 17, 2000 at 01:35:12AM +1000, Peter Donald wrote:
> At 02:48 16/9/00 +0200, you 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.
> >>
> >
> ><snip/>
> >
> >> Guess what C2 + proposed actions == 100% success :P
> >
> ><snip/>
>
> like that bit did you ? :P
Absolutetly :-))
> >> 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.
>
> so how would you see a form working ?
A first Matcher selects the URI space of the app. Nested Matchers
further divide the URI into app sections. Actions are processing
the input (cookies/posts/gets) and put state information into the
objectModel Map or maybe return a List of replacement values.
Selectors and/or Matchers choose the right pipeline components
base on the state information in the objectModel Map to produce
the "next screen" and those Generators/Transformers use sources
(src= attribute) that are specified in a List (that one mentioned
above) an Action has returned to the sitemap engine.
> >> 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>
>
> yup :}
>
> >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>
>
> sounds good.
>
> >> 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.
>
> yep but it is important - almost every login action will do some rerouting :P
As I understand it the rerouting is made based on information i
available in parts like URI, cookies, post data etc. These
information is available to the sitemap components and they can
act on them like described above.
> >
> >> 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.
>
> hmm - right - I think. It may be useful for a explicit action to redirect
> to an error page or form page if the user badly formats an action - is this
> possible ?
Yes, it is. You use a <map:pipeline> element to put all your
declarations into it. Each <map:pipeline> can have its own
<map:handle-error> which is a spezial pipeline without a generator.
If one of the components throws an Exception the <map:handle-error>
part gets control. The special ErrorGenerator (maybe its called
NotificationGenerator now, didn't remember) which produces a
specific DTD of an Exception which your selected transformer in
the <map:handle-error> can process into what ever you like.
> >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).
>
> I think so (not so familiar with C2 :P)
To be honest, you should make yourself more familiar with it
to understand what we are talking about or else we miss to
tell you details which are "well known" for us :P
> >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.
>
> right.
>
> >Any comments?
>
> Not really except how do use see explicit actions being triggered ? Do you
> have an action apply to sitemap that explicitly parses out data from
> cookies/put/get/post request ?
No, _you_ should make such an action available (or maybe there can
be a general parametrizable Action defined that does what eveybody
needs for). As I've said earlier, the sitemap engine
doesn't do such thing because it is environment dependent. Look:
<map:pipeline>
<map:match pattern="myapp/**">
<!-- this action will parse the cookies/post/get data
and make the result of that examination available
1. as state information in the objectModel Map
2. by returning resource specifications in a List
-->
<map:act chain="parse-input-and-make-information-available-chain">
<!-- this selector will choose among the information
made available in the objectModel Map by the previous
Action(s).
-->
<map:select type="input-checker-selector">
<map:when test="show-index">
<!-- this generator is charged with the appropriate index
resource specified in the List returned by the Action
above.
-->
<map:generate src="myapp/{1}/index"/>
</map:when>
<map:when test="kill-task">
<!-- this action kills a task that was spawned previously
by another action using data make available by the Action
above.
-->
<map:act type="task-killer"/>
<map:generate src="myapp/{1}/task-killing-status-page"/>
</map:when>
<map:otherwise>
<map:generate src="myapp/login"/>
</map:otherwise>
</select>
</map:act>
<map:transform src="myapp/general.xsl"/>
<map:serialize type="html"/>
</map:match>
<map:handle-error>
<map:transform src="myapp/error-transformer.xsl"/>
<map:transform src="myapp/general.xsl"/>
<map:serialize type="html"/>
</map:handle-error>
</map:pipeline>
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
Re: Action proposal
Posted by Giacomo Pati <Gi...@pwr.ch>.
On Sun, Sep 17, 2000 at 01:44:36AM +1000, Peter Donald wrote:
> >Not really except how do use see explicit actions being triggered ? Do you
> >have an action apply to sitemap that explicitly parses out data from
> >cookies/put/get/post request ?
>
> Okay this wasn't so clear :P.
>
> What I mean do you see this as the way of handling explict actions. Have an
> implicit action that parses out data and constructions a action-chain on
> the fly.
No, nothing "on the fly". You define the maximum possible action
chain for a specific URL of you application. You place the
<map:act chain="your-max-chain"/> immediately after the <map:match>
for your URL. The sitemap engine will call all the action in
sequence. Maybe the first action in the chain parser the input and
makes information available in the objectModel Map for the other
actions. All subsequent action can examine that information to
decide if it concerns to them and do something or not.
>
> So I could map the DecodeAction to /myappbase/blee and any resource below
> /myappbase/blee will decode explicit actions then build and execute
> appropriate chains ?
I don't get this. It would be good if you could write a possible
sitemap example.
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
Re: Action proposal
Posted by Peter Donald <do...@mad.scientist.com>.
>Not really except how do use see explicit actions being triggered ? Do you
>have an action apply to sitemap that explicitly parses out data from
>cookies/put/get/post request ?
Okay this wasn't so clear :P.
What I mean do you see this as the way of handling explict actions. Have an
implicit action that parses out data and constructions a action-chain on
the fly.
So I could map the DecodeAction to /myappbase/blee and any resource below
/myappbase/blee will decode explicit actions then build and execute
appropriate chains ?
Cheers,
Pete
*------------------------------------------------------*
| "Nearly all men can stand adversity, but if you want |
| to test a man's character, give him power." |
| -Abraham Lincoln |
*------------------------------------------------------*
Re: Action proposal
Posted by Peter Donald <do...@mad.scientist.com>.
At 02:48 16/9/00 +0200, you 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.
>>
>
><snip/>
>
>> Guess what C2 + proposed actions == 100% success :P
>
><snip/>
like that bit did you ? :P
>> 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.
so how would you see a form working ?
>> 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>
yup :}
>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>
sounds good.
>> 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.
yep but it is important - almost every login action will do some rerouting :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
>
>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.
hmm - right - I think. It may be useful for a explicit action to redirect
to an error page or form page if the user badly formats an action - is this
possible ?
>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).
I think so (not so familiar with C2 :P)
>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.
right.
>Any comments?
Not really except how do use see explicit actions being triggered ? Do you
have an action apply to sitemap that explicitly parses out data from
cookies/put/get/post request ?
Cheers,
Pete
*------------------------------------------------------*
| "Nearly all men can stand adversity, but if you want |
| to test a man's character, give him power." |
| -Abraham Lincoln |
*------------------------------------------------------*
Re: Action proposal
Posted by Giacomo Pati <Gi...@pwr.ch>.
Stefano Mazzocchi wrote:
>
> Giacomo Pati wrote:
>
> > > I know, I know... but I didn't hear your comments on the proposals I
> > > made.
> >
> > To be honest, the hole ComponentManager discussion is too academic to me
> > and the fact that the discussion is long lasting enough prevents me to
> > comment further on. I really have to manage my time that I can spend on
> > Apache projects make me contributing on C2 only because I like it very
> > much and I want to make it a golden hammer (or a silver bullet at least
> > :). And I see the work we have to do in C2 now that
> > NamedComponentManager is nuked.
>
> Yes, I know... but having a solid framework prevents this to happen
> again... it's in your interest as well, isn't it?
Yes, of course it is in my interest. To be honest most of the time I
don't understand what you're talking about because I haven't the time to
follow those long threads seriously. But because I know who is debatting
there (you, Berin, Pete and others) I'm conviced you'll find a good
solution because you people on the avalon list are far smarter designers
that I am (from the abstract point of view). I think my part of the game
is to make others (ie. Pete and Berin) aware of what C2 needs and
convince them to follow threads on this list too (as happened with Pete
recently).
Look, I have two or three evening of about three or four hours which I
can spend on coding. But most of the time consumes me by reading and
responding to mails. And the fact that the Americans blast my mailbox in
the evening I need half the time I can spend on those issues. But I
really want to make C2 rock and I know that I can't do it alone so I
must be active on the cocoon lists to convince others to help.
>
> > Your proposals are ok so I don't have to comment on it.
>
> Ok, good, but others might not know this :)
But you are one of the best "fighter" I know :)
> > I know you would
> > like me to support Avalon as well because it is very fundamental but
> > this fundamentals at the point they have reached today is really not my
> > skill.
>
> No problem.
>
> > Well, I've made a comment today to show where my expectations are and
> > you'll see that they are at the point where I am looking for
> > implementation ease.
>
> This is what I wanted from you: reality checks from an implementation
> standpoint.
Ok, but no one seems to take notice of that (at least nobody commented
on that) because it's implementation stuff and you guys are talking
about abstact design. And I can even understand that they won't talk
about implementations at that point of the discussion. But well, if this
is what you are expecting from me then I feel that some pressure
releases from me :)
> > > > 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.
> > >
> > > My patience is infinite (more or less), it's the rest of the people here
> > > that is not :)
> >
> > Whom you say that. I might be one of the most unpatient one and have C2
> > working with all those beautifull things we've discussed so far earlier
> > rather that later. But I know myself very well and I will go on slowly
> > to make the systems design well.
>
> :) I infected almost everyone around here with the "better is better"
> design pattern... (rather than "worse is better") and people used to
> flame me for that, eh, eh, what a revenge... :)
>
> > BTW: I had a RT about the issues we discussed under this thread. Listen:
>
> I'm all ears..
>
> > Now that we need to have a hierachical SitemapComponentManager to make
> > C2 scalable and reduce verbosity in the sitemap why can't we expose that
> > SitemapComponentManager to Components and let them build the pipeline
> > (or parts of it) programmatically, he he :) :) :)
>
> Oh, gees, this is *very* RT... but I see something there... I'd say
> "throw some good implementation rock at and see if it breaks".
Ok, next mail please :)
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
Re: Action proposal
Posted by Stefano Mazzocchi <st...@apache.org>.
Giacomo Pati wrote:
> > I know, I know... but I didn't hear your comments on the proposals I
> > made.
>
> To be honest, the hole ComponentManager discussion is too academic to me
> and the fact that the discussion is long lasting enough prevents me to
> comment further on. I really have to manage my time that I can spend on
> Apache projects make me contributing on C2 only because I like it very
> much and I want to make it a golden hammer (or a silver bullet at least
> :). And I see the work we have to do in C2 now that
> NamedComponentManager is nuked.
Yes, I know... but having a solid framework prevents this to happen
again... it's in your interest as well, isn't it?
> Your proposals are ok so I don't have to comment on it.
Ok, good, but others might not know this :)
> I know you would
> like me to support Avalon as well because it is very fundamental but
> this fundamentals at the point they have reached today is really not my
> skill.
No problem.
> Well, I've made a comment today to show where my expectations are and
> you'll see that they are at the point where I am looking for
> implementation ease.
This is what I wanted from you: reality checks from an implementation
standpoint.
> > > 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.
> >
> > My patience is infinite (more or less), it's the rest of the people here
> > that is not :)
>
> Whom you say that. I might be one of the most unpatient one and have C2
> working with all those beautifull things we've discussed so far earlier
> rather that later. But I know myself very well and I will go on slowly
> to make the systems design well.
:) I infected almost everyone around here with the "better is better"
design pattern... (rather than "worse is better") and people used to
flame me for that, eh, eh, what a revenge... :)
> BTW: I had a RT about the issues we discussed under this thread. Listen:
I'm all ears..
> Now that we need to have a hierachical SitemapComponentManager to make
> C2 scalable and reduce verbosity in the sitemap why can't we expose that
> SitemapComponentManager to Components and let them build the pipeline
> (or parts of it) programmatically, he he :) :) :)
Oh, gees, this is *very* RT... but I see something there... I'd say
"throw some good implementation rock at and see if it breaks".
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: Action proposal
Posted by Giacomo Pati <Gi...@pwr.ch>.
Stefano Mazzocchi wrote:
>
> Giacomo Pati wrote:
>
> > > 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)
>
> You know how I work... if you force the quantum state of my mind to
> collapse you are polluting the result... there is no such thing as the
> classic observer :)
>
> I'll throw some stones in the lake and see where they go...
>
> [...]
>
> > > 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 know, I know... but I didn't hear your comments on the proposals I
> made.
To be honest, the hole ComponentManager discussion is too academic to me
and the fact that the discussion is long lasting enough prevents me to
comment further on. I really have to manage my time that I can spend on
Apache projects make me contributing on C2 only because I like it very
much and I want to make it a golden hammer (or a silver bullet at least
:). And I see the work we have to do in C2 now that
NamedComponentManager is nuked.
Your proposals are ok so I don't have to comment on it. I know you would
like me to support Avalon as well because it is very fundamental but
this fundamentals at the point they have reached today is really not my
skill.
Well, I've made a comment today to show where my expectations are and
you'll see that they are at the point where I am looking for
implementation ease.
> > 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.
>
> My patience is infinite (more or less), it's the rest of the people here
> that is not :)
Whom you say that. I might be one of the most unpatient one and have C2
working with all those beautifull things we've discussed so far earlier
rather that later. But I know myself very well and I will go on slowly
to make the systems design well.
BTW: I had a RT about the issues we discussed under this thread. Listen:
Now that we need to have a hierachical SitemapComponentManager to make
C2 scalable and reduce verbosity in the sitemap why can't we expose that
SitemapComponentManager to Components and let them build the pipeline
(or parts of it) programmatically, he he :) :) :)
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
Re: Action proposal
Posted by Stefano Mazzocchi <st...@apache.org>.
Giacomo Pati wrote:
> > 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)
You know how I work... if you force the quantum state of my mind to
collapse you are polluting the result... there is no such thing as the
classic observer :)
I'll throw some stones in the lake and see where they go...
[...]
> > 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 know, I know... but I didn't hear your comments on the proposals I
made.
> 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.
My patience is infinite (more or less), it's the rest of the people here
that is not :)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: Action proposal
Posted by Giacomo Pati <Gi...@pwr.ch>.
Per Kreipke wrote:
>
> <snip>
>
> > > > > / -> 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.
>
> Forgive my simple question, I'm sure I don't really understand exactly what
> you guys are talking about but I was just working on something similar to
> the 'property inheritance' described above.
We were talking about ingeritance of SitemapComponents from a subsitemap
to its parent sitemap.
> Given an XML tree describing
> site directories and their properties, like below, I was thinking that XSL
> could be used to 'cascade' and 'inherit' settings. E.g. Would want to make
> sure that the 'Your mom' node was also private because it's parent 'Humor'
> was private.
>
> <dir name="Top">
> <props>
> <flPrivate>false</flPrivate>
> </props>
> <dir name="Humor">
> <props>
> <flPrivate>true</flPrivate>
> </props>
> <dir name="Your Mom">
> </dir>
> </dir>
> </dir>
>
> Instead of using Java to do this, couldn't the XSL or DOM processor do this?
I don't get this. Could you explain how this relates to the sitemap
inheritance we taked about in this thread?
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
RE: Action proposal
Posted by Per Kreipke <pe...@onclave.com>.
<snip>
> > > > / -> 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.
Forgive my simple question, I'm sure I don't really understand exactly what
you guys are talking about but I was just working on something similar to
the 'property inheritance' described above. Given an XML tree describing
site directories and their properties, like below, I was thinking that XSL
could be used to 'cascade' and 'inherit' settings. E.g. Would want to make
sure that the 'Your mom' node was also private because it's parent 'Humor'
was private.
<dir name="Top">
<props>
<flPrivate>false</flPrivate>
</props>
<dir name="Humor">
<props>
<flPrivate>true</flPrivate>
</props>
<dir name="Your Mom">
</dir>
</dir>
</dir>
Instead of using Java to do this, couldn't the XSL or DOM processor do this?
Per.
Re: Action proposal
Posted by Stefano Mazzocchi <st...@apache.org>.
Giacomo Pati wrote:
> > 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)
You know how I work... if you force the quantum state of my mind to
collapse you are polluting the result... there is no such thing as the
classic observer :)
I'll throw some stones in the lake and see where they go...
[...]
> > Do me a favor: download the latest Avalon CVS and see if it works for
> > you. If not, make sure you tellX-Mozilla-Status: 0009an 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 know, I know... but I didn't hear your comments on the proposals I
made.
> 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.
My patience is infinite (more or less), it's the rest of the people here
that is not :)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: Action proposal
Posted by Giacomo Pati <Gi...@pwr.ch>.
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
Re: Action proposal
Posted by Stefano Mazzocchi <st...@apache.org>.
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.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: Action proposal
Posted by Giacomo Pati <Gi...@pwr.ch>.
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
Re: Action proposal
Posted by Stefano Mazzocchi <st...@apache.org>.
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.
> 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?
> 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.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: Action proposal
Posted by Giacomo Pati <Gi...@pwr.ch>.
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
Action proposal
Posted by Peter Donald <do...@mad.scientist.com>.
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 |
*------------------------------------------------------*
Re: [C2]Access control using sitemap
Posted by Giacomo Pati <Gi...@pwr.ch>.
Peter Donald wrote:
>
> At 04:15 9/9/00 +0200, you wrote:
> > <match type="uri" pattern="myapp/**">
> > <!-- the following Matcher make the overall request
> > analysis and makes important information available
> > to subsequent components through the objectModel and
> > a Map for substitution in src= attributes.
> > Maybe a Controller sitemap component would be more
> > appropriate
> > -->
> > <match type="myapp-controller" pattern="not really used">
> > <select type="myapp-action-selector">
> > <when test="add">
> > <!-- here the {1} is delivered by the matcher
> > "myapp-controller"
> > -->
> > <generate src="myapp/{1}/remove.xsp"/>
> > </when>
> > <when test="remove">
> > <generate src="myapp/{1}/remove.xsp"/>
> > </when>
> > <otherwise>
> > <generate src="myapp/{1}/index.xml"/>
> > </otehrwise>
> > </select>
> > <select type="browser">
> > <when test="netscape">
> > <transform src="myapp/{1}/style-ns.xsl"/>
> > <serialize type="html"/>
> > </when>
> > <when test="wap">
> > <transform src="myapp/{1}/style-wap.xsl"/>
> > <serialize type="wap"/>
> > </when>
> > <otherwise>
> > <transform src="myapp/{1}/style-ie.xsl"/>
> > <serialize type="html"/>
> > </otherwise>
> > </select>
> > </match>
> > </match>
> > <-- here we catch all requests not handled by the match above
> > and redirect them to the login screen or an error page
> > -->
> > <match pattern="myapp/**">
> > <redirect-to uri="myapp/login"/>
> > </match>
> >Well, this example might not be the best one but I think its
> >good enough to start a discussion about it. What do you think?
>
> I like the approach but before an implementation can be defined there is a
> few questions that must be answered first. Namely
>
> * What is an Action ?
> * How will you use actions ?
>
> What is an Action ?
> -------------------
>
> In the above case you have associated an Action with a resource. ie the
> Remove action is associated with myapp/{1}/remove.xsp resource. Do actions
> have to be associated with a resource or are they independent of resources.
> I would say that they are independent - an Action framework should be able
> to be used via multiple interfaces whether via cocoon, turbine, telnet,
> mail etc. So the "ShutdownRealWorldMachine" action is accessible via the C2
> interface, a telnet interface or via any number of other methods.
The example above is probably misleading because we don't have a Action
component in the sitemap so far. Generally speaking I think a Sitemap
Action is an object that acts upon an application model based on data
supplied by the environments objectModel (ie Request). It's its
responsability to make some data available to the Sitemap engine as
further selection/matching criteria (a List object) as well as in the
objectModel for other sitemap components
Suppose the Interface of an Actions is like this:
public Interface Action {
public List act (Map objectModel);
}
and also suppose that the nested elements of the <map:act> elements are
skipped if the action returns a null value instead of a List.
<match type="uri" pattern="myapp/**">
<act type="myaction">
<select type="action-selector">
<when test="remove"/>
<generate src="myapp/{1}/remove.xsp"/>
</when>
...
</select>
</act>
</match>
The List object supplied by the action is used by the sitemap engine to
replace occurrences like {1} from certain attributes like src= but this
is optional. So the Action is not really associated to a resource. It's
the selector which does this association.
> An action is essentially a snippet of code that is executed in response to
> a request in a certain context (or Environment in C2s case). The action can
> add and change the context/environment data.
Agreed.
> How granular can actions be ?
You should be able to be as granular as you want.
> Does session validation count as an action ?
Why not?
> How about authorisation and authentication ?
I still suppose to leave authentication to the container but I know
someone will do it with a sitemap component :/
Authorisation is more dependant on the application context and there are
the possibilities to use AuthorisationMatchers, AuthorisationSelectors,
AuthorisationActions or a authorisation logicsheeet, what ever suit your
needs best.
> What about form validation ?
Even here, it depends. If you only want to validate form data a Selector
can be used to achieve that and in the <map:when> elements you
regenerate the resource if validation failes or choose an action to put
the form data into your application model and generate the next screen
or whatever.
> When I program actions I use a extremely granular approach.
No problem, you should be able to do things like that
<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>
> There is also the idea of latent actions. For instance the latent Action is
> transmitted between end-user and cocoon until they are activated. Actions
> may also be made latent (or deactivated) in a couple of cases. Like when
> you try to submit form but are not logged in - it will save action/form
> data (or put action into latent state) and then after login commit the
> action (or re-activate action).
Isn't this a matter how components play together?
> How will you use actions ?
> ---------------------------
>
> In many cases when I program to a an actions approach each request can
> result in many actions being executed. For instance it is not uncommon for
> an action chain to occur like the following.
>
> SessionValidatorAction --> RoleAssignerAction --> FormValidationAction -->
> FormDBEntryAction
>
> The SessionValidatorAction will check the session and if not exist then it
> will put a magic token in environment so that after action is executed then
> the rest of action-chain and output resource is ignored and the user is
> redirected to a login page.
>
> The RoleAssignerAction (lame name I know ;->) will check if the current
> user implements a certain role and if not redirect them to appropriate
> NoEntry.html type page.
> ...
>
> So when I designe a sitemap for a web-application I want to somehow be able
> to do the following.
>
> * Anything under webapp/ must run SessionValidatorAction
> * Anything under webapp/admin must run RoleAssignerAction and check for
> "admin" role
> * Then specific resources webapp/a.xml, webapp/b.xml and webapp/admin/c.xml
> must run FormValidationAction with appropriate form schema and the
> apprporiate FormDBEntryAction
Didn't get the last one? What is a FormDBEntryAction for? Probably an
XSP page?
> * A user can also arbitarily submit an action from any page (via post
> request or perhaps a ?action=blah tacked onto URL) that must be executed.
<match type="uri" pattern="webapp/**">
<act type="session-validation"/>
<match type="uri" pattern="webapp/admin">
<act type="assign-role">
<select type="role-selector">
<when test="admin">
<match type="uri" pattern="webapp/admin/c.xml">
<act type="form-validation src="admin/form-schema-c.xsd"/>
<!-- the following next-page action has knowledge of the
sequence of pages and returns a List with the first
element
corresponding to the "next page" appropriate
depending on
values in the objectModel signaling successful
validation by
the previous action (type="form-validation"). The
following
three lines could be put into a sitemap resource
definition
and replaced by <redirect-to resource="next-page"/>
-->
<act type="next-page">
<generate src="{1}"/>
</act>
</match>
<otherwise>
<match type="uri-regexp" pattern="webapp/(a|b)\.xml">
<act type="form-validation src="form-schema-{1}.xsd"/>
<act type="next-page">
<generate src="{1}"/>
</act>
</match>
</when>
</select>
</act>
</match>
</match>
>
> ----------------------------------------------------------------------------
> ---------
>
> So what would I want to see in a Cocoon-Application framework ???
>
> Well actions are independent of resources and exist in a seperate namespace.
>
> Each request can in theory result in a action-pipeline.
>
> Each action can add stuff to it's context (or Environment).
>
> Each action can in theory short-cut the action pipeline and move to another
> action-resource pipeline and also store remaining submitted actions as
> latent actions.
>
> An action pipeline must not necessarily be associated with a resource (it
> should instead be able to specify a resource that it goes to post processing).
>
> It may also be good to have an action that's sole purpose is to extract
> explicit action requests and execute/store them (ActionExtractorAction +
> ActionDispatcherAction ???)
Please answer these question yourself after you've read my explanations.
> But anyways I mean in no way to imply C2 is bad and if you want to add
> hooks into sitemap generation to allow for this sort of stuff (or even
> better do it yourself ;>) I would gladly switch all my development across
> to C2 and I suspect many others would too :P.
Implementing the framework to use actions like I've mentioned through
out this mail is a matter of an hour or two. But your're right
implementing general actions for general usage is another thing.
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
Re: [C2]Access control using sitemap
Posted by Peter Donald <do...@mad.scientist.com>.
At 04:15 9/9/00 +0200, you wrote:
> <match type="uri" pattern="myapp/**">
> <!-- the following Matcher make the overall request
> analysis and makes important information available
> to subsequent components through the objectModel and
> a Map for substitution in src= attributes.
> Maybe a Controller sitemap component would be more
> appropriate
> -->
> <match type="myapp-controller" pattern="not really used">
> <select type="myapp-action-selector">
> <when test="add">
> <!-- here the {1} is delivered by the matcher
> "myapp-controller"
> -->
> <generate src="myapp/{1}/add.xsp"/>
> </when>
> <when test="remove">
> <generate src="myapp/{1}/remove.xsp"/>
> </when>
> <otherwise>
> <generate src="myapp/{1}/index.xml"/>
> </otehrwise>
> </select>
> <select type="browser">
> <when test="netscape">
> <transform src="myapp/{1}/style-ns.xsl"/>
> <serialize type="html"/>
> </when>
> <when test="wap">
> <transform src="myapp/{1}/style-wap.xsl"/>
> <serialize type="wap"/>
> </when>
> <otherwise>
> <transform src="myapp/{1}/style-ie.xsl"/>
> <serialize type="html"/>
> </otherwise>
> </select>
> </match>
> </match>
> <-- here we catch all requests not handled by the match above
> and redirect them to the login screen or an error page
> -->
> <match pattern="myapp/**">
> <redirect-to uri="myapp/login"/>
> </match>
>Well, this example might not be the best one but I think its
>good enough to start a discussion about it. What do you think?
I like the approach but before an implementation can be defined there is a
few questions that must be answered first. Namely
* What is an Action ?
* How will you use actions ?
What is an Action ?
-------------------
In the above case you have associated an Action with a resource. ie the
Remove action is associated with myapp/{1}/remove.xsp resource. Do actions
have to be associated with a resource or are they independent of resources.
I would say that they are independent - an Action framework should be able
to be used via multiple interfaces whether via cocoon, turbine, telnet,
mail etc. So the "ShutdownRealWorldMachine" action is accessible via the C2
interface, a telnet interface or via any number of other methods.
An action is essentially a snippet of code that is executed in response to
a request in a certain context (or Environment in C2s case). The action can
add and change the context/environment data.
How granular can actions be ? Does session validation count as an action ?
How about authorisation and authentication ? What about form validation ?
When I program actions I use a extremely granular approach.
There is also the idea of latent actions. For instance the latent Action is
transmitted between end-user and cocoon until they are activated. Actions
may also be made latent (or deactivated) in a couple of cases. Like when
you try to submit form but are not logged in - it will save action/form
data (or put action into latent state) and then after login commit the
action (or re-activate action).
How will you use actions ?
---------------------------
In many cases when I program to a an actions approach each request can
result in many actions being executed. For instance it is not uncommon for
an action chain to occur like the following.
SessionValidatorAction --> RoleAssignerAction --> FormValidationAction -->
FormDBEntryAction
The SessionValidatorAction will check the session and if not exist then it
will put a magic token in environment so that after action is executed then
the rest of action-chain and output resource is ignored and the user is
redirected to a login page.
The RoleAssignerAction (lame name I know ;->) will check if the current
user implements a certain role and if not redirect them to appropriate
NoEntry.html type page.
...
So when I designe a sitemap for a web-application I want to somehow be able
to do the following.
* Anything under webapp/ must run SessionValidatorAction
* Anything under webapp/admin must run RoleAssignerAction and check for
"admin" role
* Then specific resources webapp/a.xml, webapp/b.xml and webapp/admin/c.xml
must run FormValidationAction with appropriate form schema and the
apprporiate FormDBEntryAction
* A user can also arbitarily submit an action from any page (via post
request or perhaps a ?action=blah tacked onto URL) that must be executed.
----------------------------------------------------------------------------
---------
So what would I want to see in a Cocoon-Application framework ???
Well actions are independent of resources and exist in a seperate namespace.
Each request can in theory result in a action-pipeline.
Each action can add stuff to it's context (or Environment).
Each action can in theory short-cut the action pipeline and move to another
action-resource pipeline and also store remaining submitted actions as
latent actions.
An action pipeline must not necessarily be associated with a resource (it
should instead be able to specify a resource that it goes to post processing).
It may also be good to have an action that's sole purpose is to extract
explicit action requests and execute/store them (ActionExtractorAction +
ActionDispatcherAction ???)
But anyways I mean in no way to imply C2 is bad and if you want to add
hooks into sitemap generation to allow for this sort of stuff (or even
better do it yourself ;>) I would gladly switch all my development across
to C2 and I suspect many others would too :P.
Anyway I should stop ruffling feathers considering I don't plan to
implement this for quite a few months :P
Cheers,
Pete
*------------------------------------------------------*
| "Nearly all men can stand adversity, but if you want |
| to test a man's character, give him power." |
| -Abraham Lincoln |
*------------------------------------------------------*
Re: [C2]Access control using sitemap
Posted by Giacomo Pati <Gi...@pwr.ch>.
Hi all
this is a interesting thread and I like to join in.
Actually I'm thinking of and developing a sitemap administration app
based on C2.
My first step was to develop a stylesheet to render the sitemap.xmap
file to a html document. You'll find it under
webapps/stylesheets/simple-sitemap2html.xsl (commited today). Use the
following command to render the initial html page for that admin app:
java org.apache.xalan.xslt.Process \
-IN webapp/sitemap.xmap \
-XSL webapp/stylesheets/simple-sitemap2html.xsl \
-OUT a.html \
-HTML
and look at the generated a.html file with your preferred browser (it
doesn't work under C2 today and I don't know yet why).
I think the C2 sitemap component might be able to give you all you need
to write web apps. Let's have a look at it:
All sitemap component (except Serializers) have access to the so called
objectModel which is a Map containing objects like HttpServletRequest,
HttpServletResponse and ServletContext. The CocoonServlet, as calling
environment of Cocoon, is responsible to provide this objectModel and
its content to the C2 engine. The objectModels lifecycle is the time to
process one response. Objects that have a longer lifecycle can be put
into the Session object as usual. The objectModel can be used to pass
information along all sitemap component participating in the pipeline
selection and resource production process.
Lets have a example how I see a possible sitemap pipeline snipped to
achieve this (I'll abbreviate the elelments :)
<match type="uri" pattern="myapp/**">
<!-- the following Matcher make the overall request
analysis and makes important information available
to subsequent components through the objectModel and
a Map for substitution in src= attributes.
Maybe a Controller sitemap component would be more
appropriate
-->
<match type="myapp-controller" pattern="not really used">
<select type="myapp-action-selector">
<when test="add">
<!-- here the {1} is delivered by the matcher
"myapp-controller"
-->
<generate src="myapp/{1}/add.xsp"/>
</when>
<when test="remove">
<generate src="myapp/{1}/remove.xsp"/>
</when>
<otherwise>
<generate src="myapp/{1}/index.xml"/>
</otehrwise>
</select>
<select type="browser">
<when test="netscape">
<transform src="myapp/{1}/style-ns.xsl"/>
<serialize type="html"/>
</when>
<when test="wap">
<transform src="myapp/{1}/style-wap.xsl"/>
<serialize type="wap"/>
</when>
<otherwise>
<transform src="myapp/{1}/style-ie.xsl"/>
<serialize type="html"/>
</otherwise>
</select>
</match>
</match>
<-- here we catch all requests not handled by the match above
and redirect them to the login screen or an error page
-->
<match pattern="myapp/**">
<redirect-to uri="myapp/login"/>
</match>
Well, this example might not be the best one but I think its
good enough to start a discussion about it. What do you think?
Peter Donald wrote:
>
> At 11:47 8/9/00 -0400, you wrote:
> >I actually was interested in Cocoon because I thought it could merge
> >multiple pipes into one output. I was in fact using XInclude to include XML
> >fragments (like user info, skins, globals) and XSL to shape (filter) the
> >results into a another XML hierarchy which would then be styled. E.g. a two
> >stage XSLT pipeline. I think this is very powerful.
>
> yep - but not so easy - especially when you cyndicate content from multiple
> different sources or when the aggregation mapping needs to be dynamic etc.
> >> Aggregation will be served by Jetspeed (an apache project that is
> >> currently
> >> at java.apache.org but will soon be at xml.apache.org). Jetspeed
> >> does a lot
> >> more than aggregate - it mixes in lots of other options.
> >
> >True. However, as you mention later, it also seems difficult to learn.
>
> :< yup
I know people doing kinda portals stuff using C2 (but unfortunately they
are still not allowed to give those components back into the open source
community). And personally I think Jetspeed may be used as a sitemap
component doing aggregation mapping in the (near) future.
> >Fair enough. Two comments. First, I thought I read on this list that Turbine
> >was going to be used by C2 at some point. I was hoping that it's
> >functionality would thereby become available to me.
>
> possibly - in the future. C2 already uses some components (database
> pooling) from turbine) but it conceptually a different beast. Currently
> Cocoon handles dispatching
I have to correct this here. C1 has the database pooling component from
Turbine integrated but not C2 yet. I'll try to port Donalds esql
logicsheet to C2 sometimes (my time is limited as well, but maybe we'll
find some volunteers :) That logicsheet is prepared to use the pooling
stuff.
> >Second, I've begun to look at Cocoon as a two way pipeline and fooling
> >around to see if I can make it work (please tell me if it's been done
> >already!). That is, each input to the system (e.g. POST) can have multiple
> >outputs (e.g. to calling client and backend system), enumerated in the
> >sitemap as transformations themselves.
>
> quite possible - thou I would hesitate to say not anywhere as easy as it
> should be.
>
> >I think it would be interesting, and the proper separation of responsibility
> >in the opposite direction from Cocoon's original design, for the input
> >request to generate multiple outbound 'messages' for other systems. Those
> >messages should of course simply be XML snippets, which can of course be
> >created by XSP and XSL transforms.
>
> it is an interesting approach - make sure you post to the list if you get
> it up and running :P
>
> >Am I making any sense? Basically, I could see Cocoon becoming a great way to
> >write middleware, not just a publishing system. The benefit of a system like
> >C2 where you can insert new elements in the pipeline is that you can let
> >Cocoon extend as far in either direction from its center as you want, just
> >add or subtract transforms.
C2 was designed to run in many environments. For now they are Web
(called from a servlet) and command line. I think you can use C2 in any
environment which has a request/response pattern.
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
RE: [C2]Access control using sitemap
Posted by Peter Donald <do...@mad.scientist.com>.
At 11:47 8/9/00 -0400, you wrote:
>I actually was interested in Cocoon because I thought it could merge
>multiple pipes into one output. I was in fact using XInclude to include XML
>fragments (like user info, skins, globals) and XSL to shape (filter) the
>results into a another XML hierarchy which would then be styled. E.g. a two
>stage XSLT pipeline. I think this is very powerful.
yep - but not so easy - especially when you cyndicate content from multiple
different sources or when the aggregation mapping needs to be dynamic etc.
>> Aggregation will be served by Jetspeed (an apache project that is
>> currently
>> at java.apache.org but will soon be at xml.apache.org). Jetspeed
>> does a lot
>> more than aggregate - it mixes in lots of other options.
>
>True. However, as you mention later, it also seems difficult to learn.
:< yup
>Fair enough. Two comments. First, I thought I read on this list that Turbine
>was going to be used by C2 at some point. I was hoping that it's
>functionality would thereby become available to me.
possibly - in the future. C2 already uses some components (database
pooling) from turbine) but it conceptually a different beast. Currently
Cocoon handles dispatching
>Second, I've begun to look at Cocoon as a two way pipeline and fooling
>around to see if I can make it work (please tell me if it's been done
>already!). That is, each input to the system (e.g. POST) can have multiple
>outputs (e.g. to calling client and backend system), enumerated in the
>sitemap as transformations themselves.
quite possible - thou I would hesitate to say not anywhere as easy as it
should be.
>I think it would be interesting, and the proper separation of responsibility
>in the opposite direction from Cocoon's original design, for the input
>request to generate multiple outbound 'messages' for other systems. Those
>messages should of course simply be XML snippets, which can of course be
>created by XSP and XSL transforms.
it is an interesting approach - make sure you post to the list if you get
it up and running :P
>Am I making any sense? Basically, I could see Cocoon becoming a great way to
>write middleware, not just a publishing system. The benefit of a system like
>C2 where you can insert new elements in the pipeline is that you can let
>Cocoon extend as far in either direction from its center as you want, just
>add or subtract transforms.
>
>Outbound:
>Browser <- HTML <- XSLT <- XML <- XSP <- {JDBC | XInclude | Files | XML-RPC
>| Other}
>
>Inbound:
>Browser -> HTTP -> XSL -> XML -> XSP -> {XML store | MSSQLXML | XQL DB |
>XML-RPC | ...}
yep I understand where you are coming from (I tried a similar approach back
in C1.4-C1.6).
However I think I would classify it as "flexibility" syndrome. You can do
it that way but it is not efficient. It also requires back-end writers to
be versed in waaaaay to many technologies and be damn good at those
technologies. Combine this with the fact that it is a PITA to debug XSP or
any dynamically generated language and how *costly* it is and I don't think
you will see such an approach adopted by large websites.
Mixing content and logic is never a good thing and building excessive
number of general purpose XML processors is a large costly task without any
great benefit IMHO. This is one of the reasons that template engines are
coming in the fore ... I would much rather see a templating XSP rather than
general purpose logic in XSP.
>> So in effect when a request comes in it goes via a "sitemap" (not to be
>> confused with C2s sitemap) that maps request to a web-application. The
>> web-application does it's stuff and then chooses a C2 pipeline to output
>> via. It then fills a "context" with relevent information (like
>> result data)
>> and executes the pipeline with relevent context. Aggregator sits on top of
>> this.
>
>As mentioned above, while I use what you're describing right now, I'm hoping
>to use only Cocoon in the future.
good luck - I think you will need it :P
>> None of these applications are yet easy to use with cocoon. I have been
>> trying to get people to adopt diferent apache products for a while but so
>> far I have only got them to se cocoon out of these three. There
>> are changes
>> in place to make usage of these products easier (specifically
>> turbine has a
>> simple developers kit setup in progress) but that still leaves a
>> lot of the
>> Integration for you to do. Currently there is also a move to
>> standadise the
>> packaging of all apache products (I believe PMC is or will in future be
>> discussing this possibility) which will help this progress.
>
>Great! But, uh, who's PMC?
I don't know what it stands for but it is group of people who decide on
directions of Apache projects. Jon (Turbine's original author) was one who
was going to try and standardise project/build structure. I believe Stefano
(original Cocoon author) is also on it.
Cheers,
Pete
*------------------------------------------------------*
| "Nearly all men can stand adversity, but if you want |
| to test a man's character, give him power." |
| -Abraham Lincoln |
*------------------------------------------------------*
Re: [C2]Access control using sitemap
Posted by Zvi <th...@ifrance.com>.
Hi Giacomo,
Giacomo Pati wrote:
> Zvi wrote:
> >
> > Hi,
> >
> > Stefano Mazzocchi wrote:
> >
> > [skipped]
> >
> > > > Aggregation means the method through which multiple pipelines are merged to
> > > > produce 1 oupput. Currently cocoon has support for 1 pipeline producing
> > > > multiple outputs but no support for multiple pipelines producing one
> > > > output. (thou you can do it with certain hacks and perhaps via XInclude -
> > > > it is not easy).
> > >
> > > ???
> > >
> > > Do you seriously think that something like this
> > >
> > > <page>
> > > <sitebar xinclude:href="/sitebar"/>
> > > <body>
> > > blah blah
> > > </body>
> > > </page>
> > >
> > > is too hard to use?
> >
> > not so hard, but it's on the individual page level, in my app I need take the XML
> > fragment of sidebar and transform it with XSLT and only then iclude into document.
> > Especially highly needed, ability to programmaticaly call XSPs, i.e. include XSP
> > inside other XSP without internal HTTP requests. I think better to do that at
> > sitemap level, example:
> >
> > <match type="uri" pattern="myapp/**">
> > <vaiable name="sitebar">
> > <generate src="myapp/sitebar.xml"/>
> > <transform src="myapp/sitebar.xsl"/>
> > </variable>
> > <vaiable name="footer">
> > <generate src="myapp/footer.xml"/>
> > <transform src="myapp/footer.xsl"/>
> > </variable>
> > <generate src="myapp/page.xml">
> > <param name="sitebar" value="$sitebar"/>
> > <param name="footer" value="$footer"/>
> > </generate>
> > <transform src="myapp/page.xsl"/>
> > <serialize type="html"/>
> > </match>
> >
> > In short we need aggregation on the sitemap level and not only on the individual XSP
> > page level.
>
> Is it so hard to write a simple transformer that does this???
>
> <match type="uri" pattern="myapp/**">
> <generate src="myapp/page.xml">
> <transform type="my-include" src="myapp/sitebar.xml">
> <param name="stylesheet" value="myapp/sitebar.xsl"/>
> <param name="position" value="left"/>
> </transform>
> <transform type="my-include" src="myapp/footer.xml">
> <param name="stylesheet" value="myapp/footer.xsl"/>
> <param name="position" value="bottom"/>
> </transform>
> <transform src="myapp/page.xsl"/>
> <serialize type="html"/>
> </match>
>
> IMHO its totally easy to write such a "my-include" transformer, don't
> you think? And you can easily read it top down.
Can you explain how this work? Is that real C2 sitemap example?
In my example I need 2 xsp's transformed, before inclusion in another XSP document - and
in your example you include them on the transformation stage.
And this is not the same thing.
What I don't like in C2 sitemap, that there is many things hidden, to reduce verbosity,
but I think it's also reduce redability. What for example happend with results of two
intermidiate transforms, how can I understand from this sitemap them going to be included
into resulting document?
Regards,
Zvi
Re: [C2]Access control using sitemap
Posted by Giacomo Pati <Gi...@pwr.ch>.
Zvi wrote:
>
> Hi,
>
> Stefano Mazzocchi wrote:
>
> [skipped]
>
> > > Aggregation means the method through which multiple pipelines are merged to
> > > produce 1 oupput. Currently cocoon has support for 1 pipeline producing
> > > multiple outputs but no support for multiple pipelines producing one
> > > output. (thou you can do it with certain hacks and perhaps via XInclude -
> > > it is not easy).
> >
> > ???
> >
> > Do you seriously think that something like this
> >
> > <page>
> > <sitebar xinclude:href="/sitebar"/>
> > <body>
> > blah blah
> > </body>
> > </page>
> >
> > is too hard to use?
>
> not so hard, but it's on the individual page level, in my app I need take the XML
> fragment of sidebar and transform it with XSLT and only then iclude into document.
> Especially highly needed, ability to programmaticaly call XSPs, i.e. include XSP
> inside other XSP without internal HTTP requests. I think better to do that at
> sitemap level, example:
>
> <match type="uri" pattern="myapp/**">
> <vaiable name="sitebar">
> <generate src="myapp/sitebar.xml"/>
> <transform src="myapp/sitebar.xsl"/>
> </variable>
> <vaiable name="footer">
> <generate src="myapp/footer.xml"/>
> <transform src="myapp/footer.xsl"/>
> </variable>
> <generate src="myapp/page.xml">
> <param name="sitebar" value="$sitebar"/>
> <param name="footer" value="$footer"/>
> </generate>
> <transform src="myapp/page.xsl"/>
> <serialize type="html"/>
> </match>
>
> In short we need aggregation on the sitemap level and not only on the individual XSP
> page level.
Is it so hard to write a simple transformer that does this???
<match type="uri" pattern="myapp/**">
<generate src="myapp/page.xml">
<transform type="my-include" src="myapp/sitebar.xml">
<param name="stylesheet" value="myapp/sitebar.xsl"/>
<param name="position" value="left"/>
</transform>
<transform type="my-include" src="myapp/footer.xml">
<param name="stylesheet" value="myapp/footer.xsl"/>
<param name="position" value="bottom"/>
</transform>
<transform src="myapp/page.xsl"/>
<serialize type="html"/>
</match>
IMHO its totally easy to write such a "my-include" transformer, don't
you think? And you can easily read it top down.
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
Re: [C2]Access control using sitemap
Posted by Zvi <th...@ifrance.com>.
Hi,
Stefano Mazzocchi wrote:
[skipped]
> > Aggregation means the method through which multiple pipelines are merged to
> > produce 1 oupput. Currently cocoon has support for 1 pipeline producing
> > multiple outputs but no support for multiple pipelines producing one
> > output. (thou you can do it with certain hacks and perhaps via XInclude -
> > it is not easy).
>
> ???
>
> Do you seriously think that something like this
>
> <page>
> <sitebar xinclude:href="/sitebar"/>
> <body>
> blah blah
> </body>
> </page>
>
> is too hard to use?
not so hard, but it's on the individual page level, in my app I need take the XML
fragment of sidebar and transform it with XSLT and only then iclude into document.
Especially highly needed, ability to programmaticaly call XSPs, i.e. include XSP
inside other XSP without internal HTTP requests. I think better to do that at
sitemap level, example:
<match type="uri" pattern="myapp/**">
<vaiable name="sitebar">
<generate src="myapp/sitebar.xml"/>
<transform src="myapp/sitebar.xsl"/>
</variable>
<vaiable name="footer">
<generate src="myapp/footer.xml"/>
<transform src="myapp/footer.xsl"/>
</variable>
<generate src="myapp/page.xml">
<param name="sitebar" value="$sitebar"/>
<param name="footer" value="$footer"/>
</generate>
<transform src="myapp/page.xsl"/>
<serialize type="html"/>
</match>
In short we need aggregation on the sitemap level and not only on the individual XSP
page level.
Best Regards,
Zvi
Re: [C2]Access control using sitemap
Posted by Peter Donald <do...@mad.scientist.com>.
At 08:19 11/9/00 +0200, you wrote:
>Peter Donald wrote:
>>
>> At 10:58 9/9/00 +0200, Stefano Mazzocchi wrote:
>> >And calling java methods from XSLT extentions or using WebMacro like
>> >templating is not a better solution either, since all have pros and
>> >cons. There is no silver bullet.
>>
>> just curious but what are the cons for a template approach.
>
>One for all: speed!
kewl. Thou I think velocity will have a compiled sheets aswell :P
>> I have only
>> barely played with that and it was a custom solution a few years ago (when
>> I didn't mind hacks :P). I would love to to have XML templating + CSS
>> styling (rather than icky icky xslt) - so tell me why thats a bad idea :P
>
>Well, maybe you are not listening, but tell me if this is ok for you
>
> <?xml version="1.0"?>
> <?xml-stylesheet href="page.css" type="text/css"?>
> <page>
> <content>
> <p>Hello Peter, I told you this <util:count/> times</p>
> </content>
> </page>
>
>isn't this enough of a XML template with no "icky icky xslt"? ;-)
this is great :P
>Why to you keep thinking that "using XSP" means "placing programming
>code into your pages"?
I have been badly burned by the other *SPs (ASP/JSP) and NEVER want to
there again so call it extreme cautiousness or paranoid delusions :P
Cheers,
Pete
*------------------------------------------------------*
| "Nearly all men can stand adversity, but if you want |
| to test a man's character, give him power." |
| -Abraham Lincoln |
*------------------------------------------------------*
Re: [C2]Access control using sitemap
Posted by Stefano Mazzocchi <st...@apache.org>.
Peter Donald wrote:
>
> At 10:58 9/9/00 +0200, Stefano Mazzocchi wrote:
> >And calling java methods from XSLT extentions or using WebMacro like
> >templating is not a better solution either, since all have pros and
> >cons. There is no silver bullet.
>
> just curious but what are the cons for a template approach.
One for all: speed!
But this said, almost everything is a template system.
> I have only
> barely played with that and it was a custom solution a few years ago (when
> I didn't mind hacks :P). I would love to to have XML templating + CSS
> styling (rather than icky icky xslt) - so tell me why thats a bad idea :P
Well, maybe you are not listening, but tell me if this is ok for you
<?xml version="1.0"?>
<?xml-stylesheet href="page.css" type="text/css"?>
<page>
<content>
<p>Hello Peter, I told you this <util:count/> times</p>
</content>
</page>
isn't this enough of a XML template with no "icky icky xslt"? ;-)
Why to you keep thinking that "using XSP" means "placing programming
code into your pages"?
What's the difference if the above is compiled into java or interepreted
at runtime from the author point of view?
> >> For instance the sitemap may pass incoming data down one
> >> action path - the path may result in one of 5 outwards bound
> >> publishing pipelines. The action can place magic-data
> >> in context to say which pipeline to choose etc.
> >>
> >> Does that make any sense ? :P
> >
> >Yes, but there is a problem with your vision: pipelines are _not_ chains
> >of actions. You cannot (and should not) have run-time pipeline
> >composition, otherwise the whole sitemap model falls apart.
>
> yep
>
> >The Turbine-like functionality can be perfectly stored into a complex
> >generator and leave the pipeline untouched.
>
> the problem with that is that actions are independent of any resource chain
> - and you would have to aggregate actions into one generator - which
> defeats purpose of component based engineering.
Good point. Then we have to follow Giacomo's suggestion and extend the
sitemap semantics.
> >Agreed, but you seem to imply with your mail that action-orientated
> >processing is not of our concern.. which is, indeed, not the case... we
> >just want to finish up the core before doing anything inside sitemap
> >components.
>
> ok - my mistake :P
>
> >No, you should get your hand dirty and make proposals. This is what
> >you've done in Avalon and it worked well, didn't it? When you have time
> >and energy you should do the same here to scratch your itches.
>
> well it look slike I prolly will - at least when I start working on that
> stuff :P
And we'll welcome your contributions :)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: [C2]Access control using sitemap
Posted by Peter Donald <do...@mad.scientist.com>.
At 10:58 9/9/00 +0200, Stefano Mazzocchi wrote:
>And calling java methods from XSLT extentions or using WebMacro like
>templating is not a better solution either, since all have pros and
>cons. There is no silver bullet.
just curious but what are the cons for a template approach. I have only
barely played with that and it was a custom solution a few years ago (when
I didn't mind hacks :P). I would love to to have XML templating + CSS
styling (rather than icky icky xslt) - so tell me why thats a bad idea :P
>> For instance the sitemap may pass incoming data down one
>> action path - the path may result in one of 5 outwards bound
>> publishing pipelines. The action can place magic-data
>> in context to say which pipeline to choose etc.
>>
>> Does that make any sense ? :P
>
>Yes, but there is a problem with your vision: pipelines are _not_ chains
>of actions. You cannot (and should not) have run-time pipeline
>composition, otherwise the whole sitemap model falls apart.
yep
>The Turbine-like functionality can be perfectly stored into a complex
>generator and leave the pipeline untouched.
the problem with that is that actions are independent of any resource chain
- and you would have to aggregate actions into one generator - which
defeats purpose of component based engineering.
>Agreed, but you seem to imply with your mail that action-orientated
>processing is not of our concern.. which is, indeed, not the case... we
>just want to finish up the core before doing anything inside sitemap
>components.
ok - my mistake :P
>No, you should get your hand dirty and make proposals. This is what
>you've done in Avalon and it worked well, didn't it? When you have time
>and energy you should do the same here to scratch your itches.
well it look slike I prolly will - at least when I start working on that
stuff :P
Cheers,
Pete
*------------------------------------------------------*
| "Nearly all men can stand adversity, but if you want |
| to test a man's character, give him power." |
| -Abraham Lincoln |
*------------------------------------------------------*
Re: [C2]Access control using sitemap
Posted by Stefano Mazzocchi <st...@apache.org>.
donaldp@mad.scientist.com wrote:
>
> On Sat, 9 Sep 2000, Stefano Mazzocchi wrote:
> > I disagree.
>
> :P
>
> > The sitemap maps "resources" to "instructions to produce them".
>
> it has the potential to - but it doesn't now from what I can
> tell (thou I may be wrong).
I need examples to say if the functionality is there or not. So far,
nobody came with something that was not possible to do in the sitemap...
and without bad hacks.
> > The Cocoon Sitemap is a "module-oriented programming languages for web
> > sites".
>
> > > So what I see cocoons main strength is building the pipeline and "running" it.
> >
> > I agree here, but I do NOT see why this matches with "publishing" only.
>
> it doesn't. It is perfectly capable of building complex
> aggregating web-applications - but it aint easy to do it in
> it - thats what I am getting at.
Oh, we strongly agree then: my goal is to make this both technologically
possible without hacks, simple for simple stuff, complex for complex
stuff, but still possible for incredibly complex stuff.
And keep clean separation of concern and don't hurt scalability both
technical and human.
If you have a better plan, please, let me know.
> > > There are other requirements for a complete web-development system, two of
> > > which are aggregation and application logic.
> >
> > Correct. I agree with this separation but unlike you, I see cocoon below
> > both, not at the same level. Aggregation is a special way of generating
> > content, while application logic is a complex yet specific way of
> > building sitemaps and the logic that glues different resources together
> > depending on user actions or enviornment parameters.
>
> I see cocoon below aggregation but at same level as
> application logic. Both IMHO should be side by side but each
> to their own :P
I disagree: you can place Cocoon into Turbine screens and you can use
Turbine services in Cocoon XSPs... but both are hacks. Big time hacks,
and I hate hacks, you all know that.
The only possible way to do side-by-side things is with modular
frameworks and I'm sure you agree with me on this :-)
> > > Aggregation means the method through which multiple pipelines are merged to
> > > produce 1 oupput. Currently cocoon has support for 1 pipeline producing
> > > multiple outputs but no support for multiple pipelines producing one
> > > output. (thou you can do it with certain hacks and perhaps via XInclude -
> > > it is not easy).
> >
> > ???
> >
> > Do you seriously think that something like this
> >
> > <page>
> > <sitebar xinclude:href="/sitebar"/>
> > <body>
> > blah blah
> > </body>
> > </page>
> >
> > is too hard to use?
>
> now make that include variable depending on what *mode* you
> are in. ie Admins have different sitebar, people outside
> company have different colors/skinning, and admins outside
> company have both applied. ALso make it variable content
> depending on time of day etc etc .
>
> It is all possible - but it is just not easy.
Granted. What I'm asking is to join effort to make it easier. And this
means working side by side with the Turbine people as well, I'm not
trying to reinvent the wheel.
> > > Aggregation will be served by Jetspeed (an apache project that is currently
> > > at java.apache.org but will soon be at xml.apache.org). Jetspeed does a lot
> > > more than aggregate - it mixes in lots of other options.
> >
> > Agreed. The goal is: Cocoon2 provides internal aggregation capabilities,
> > Jetspeed drives the process.... it's more or less a Cocoon Web
> > Application that uses its capabilities for a more specific purpose
> > (which is creating portals and bring different informative source to the
> > same site).
> >
> > I picture Jetspeed2 as a number of additional Cocoon sitemap components
> > and some sitemaps prebuilt do mix them together. Everything down below
> > is done by Cocoon, so you either can use Jetspeed or rewrite your own
> > with Cocoon functionality.
>
> yep agreed.
>
> > > Web-application logic is something different again - it includes all the
> > > "doing" aspects of the system. So if your applications contacts a database
> > > and performs a whole heap of transactions, performs complex processing etc
> > > then this should be done in web-application level. Apache has a
> > > web-application framework (Turbine at java.apache.org) that includes a lot
> > > of this functionality (Identity management, authentication, authorisation,
> > > database pools, "actions" etc).
> >
> > Yes, we need to integrate Turbine functionality in C2 and I have a
> > couple of ideas on how to do this:
> >
> > 1) get turbine-like services from Avalon (db pool, identity manager,
> > etc...) as blocks
>
> thats what I am aiming for :P
See, we do agree deeply inside :)
> > 2) create a "web application language" that defines the logic of the web
> > application. This is then "compiled" into sitemap and XSP skeletons.
>
> I always dislike this approach. I really don't like
> reinventing the wheel - even if it is a slightly better
> wheel. If I want to develope stuff for a large website with
> a lot of application logic I want to do it in straight java
> and not worry about anything else. If there was a way of
> scripting inputs to actions and templating outputs via some
> xsp sheet then brilliant - just don't make me use some ugly
> xml/java/scripting cross :P
I won't, don't worry. I totally dislike placing java into XML as well,
XSP was designed to be the very low level that users should never see or
use themselves... but you need taglibs for that and it's an evolutionary
process that takes time.
And calling java methods from XSLT extentions or using WebMacro like
templating is not a better solution either, since all have pros and
cons. There is no silver bullet.
> > Turbine is indeed cool, but it's programmer focused and our pyramid of
> > concerns doesn't fit to their model where the programmer is also the
> > site manager (which is never the case).
>
> agreed.
>
> > > So in effect when a request comes in it goes via a "sitemap" (not to be
> > > confused with C2s sitemap) that maps request to a web-application. The
> > > web-application does it's stuff and then chooses a C2 pipeline to output
> > > via. It then fills a "context" with relevent information (like result data)
> > > and executes the pipeline with relevent context. Aggregator sits on top of
> > > this.
> >
> > More or less, this is still unclear to me...
>
> You seem to get everything except perhaps how contexts are
> filled with data from web-applications ?
>
> Basically you put data in a context and this is used by
> various stages in pipeline.
>
> For instance a request comes in and is mapped to a
> particular action. The action may do any number of things
> which result in it putting data in it's context. The
> context-data is then used at various stages in pipeline. For
> instance a username and address may be stored in the
> context-data. This is then pulled out at a generator or
> transformer stage. In many ways it is like "session" data
> per-request (yes that is a contradiction of terms :P).
Ok, I see your point.
> It is especially useful in templating style web-applications
> and I suspect in C2 aswell.
>
> Context-data can also contain special "escape" commands that
> tell the C2 engine to do other things.
>
> For instance the sitemap may pass incoming data down one
> action path - the path may result in one of 5 outwards bound
> publishing pipelines. The action can place magic-data
> in context to say which pipeline to choose etc.
>
> Does that make any sense ? :P
Yes, but there is a problem with your vision: pipelines are _not_ chains
of actions. You cannot (and should not) have run-time pipeline
composition, otherwise the whole sitemap model falls apart.
The Turbine-like functionality can be perfectly stored into a complex
generator and leave the pipeline untouched.
This enforces separation of concerns between action programmers and site
administration (for example, you can change the layout of your web
application without messing with the web-app logic)
> > > None of these applications are yet easy to use with cocoon. I have been
> > > trying to get people to adopt diferent apache products for a while but so
> > > far I have only got them to se cocoon out of these three.
> >
> > I wonder why? :)
>
> :P
>
> well it is not what you think - I think cocoon is probably
> THE leading publishing framework - I am not even familiar
> with any comparable products - but the people I got to use
> it just love it because it is easy to use (at least compared
> to other OS frameworks) and lets them do what they want
> (basically publishing from a db)
This is what I was aiming at: Cocoon does what you need and evolves with
your needs.
This is why started with static publishing, then dynamic publishing, now
complex dynamic publishing and in the future very complex dynamic
publishing.
It's all about placing information on a user browser after all.
It just gets more tricky as you add complexity.
> > More or less, I agree. But I do not see why Cocoon2 can't fit all of
> > them in fuctionality. Don't get me wrong, it's indeed hard to write web
> > applications on C2 "today"... but the functionality you need it's
> > there.. we just have to "tune it" for web applications and create
> > helpers for you.
>
> yep. It is possible - just not easy and I have not seen any
> discussion about action-orientated processing.
Agreed, but you seem to imply with your mail that action-orientated
processing is not of our concern.. which is, indeed, not the case... we
just want to finish up the core before doing anything inside sitemap
components.
And, yes, it might turn out that the sitemap needs new semantics to
drive this... so what, we'll add it... adding things is not a problem,
the problem is removing things.
This is why you make just one step at a time.
> I saw a while
> back that someone was discussing form validation but that is
> only a small part of picture.
Please, don't use the "it doesn't do it today" argument around here:
many of the specifications we are using (and we use a lot of new ones!)
are not even finalized and we are busy trying to get ready with a first
beta release...
Proposing is good and welcome, but please, understand the dynamics of
this project.
> > > >And, if Cocoon isn't a web-app framework,
> > > >are there any web-app frameworks it'll integrate with easily?
> > >
> > > Well currently Jetspeed does it and it wouldn't be hard to add it to
> > > turbine. The problem is that neither is yet easy to set up and they require
> > > a lot of knowledge. Personally I wouldn't recomend it atm but in the future
> > > that is the way to go.
> >
> > I don't think it's possible to integrate turbine and Cocoon. They are
> > too different. But Cocoon can clone Turbine functionality and provide
> > better separation of concerns.
>
> actually I demo-ed cocoon pages in turbine a bit back to try
> and entice people to use turbine (they already used
> cocoon) but they disliked the difficulty of setting it
> up. It was also a major code-hack :(
I know.. the problem is that Turbine folks don't think it's a hack and
they even suggest it to users.
> > > If you have a product out in next few months just write xsp to do it for
> > > you - if your product timeline is longer (end of next year) then doing it
> > > the *right* way may be in order. I am trying at the moment to get some
> > > funding to setup an integrated solution and if so will start an OS frontend
> > > next march. Heres hoping :P
> >
> > Well, that will clearly fork this project then, since we'll be aiming at
> > the same target :)
>
> hmm - Perhaps I should just wait and see :P
No, you should get your hand dirty and make proposals. This is what
you've done in Avalon and it worked well, didn't it? When you have time
and energy you should do the same here to scratch your itches.
> A few questions thou -
>
> * in the future do you plan to be able to map incoming
> requests to event mosaics ?
Sorry, doesn't parse.
> * will sitemap be able to represent other aspects of system
> (like I mentioned a while back on Avalon list ?)
Same here, please, give me more context.
> From reading the code I was under the impression that is
> publishing orientated and from a few comments here I was
> under the same impression (which could quite possibly be
> completely wrong as I don't always pay attention :P)
There is no web application that doesn't publish information, while
there are publishing necessities that don't require the complexity of
web applications.
This is my personal vision of the web. And Cocoon reflects this starting
from publishing functionalities and growing bigger to match all possible
publishing needs, even mapped by complex logic.
But it's an evolutionary process and will take time and help to happen.
No, Paul, we are not focused on publishing *only*, but publishing has a
central role on the web and still will in the future (even more than
today).
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: [C2]Access control using sitemap
Posted by Stefano Mazzocchi <st...@apache.org>.
Giacomo Pati wrote:
> > > Do you seriously think that something like this
> > >
> > > <page>
> > > <sitebar xinclude:href="/sitebar"/>
> > > <body>
> > > blah blah
> > > </body>
> > > </page>
> > >
> > > is too hard to use?
> >
> > now make that include variable depending on what *mode* you
> > are in. ie Admins have different sitebar, people outside
> > company have different colors/skinning, and admins outside
> > company have both applied. ALso make it variable content
> > depending on time of day etc etc .
>
> If you need logic to determine which sitebar to choose use an XSP page
> instead of the above to create the xinclude.
Naaah, *much* easier than this.
Look closer: href="/sitebar"... does it specify "which flavor" of
sitemap do I want?
No, it uses proper separation of concerns so this page author doesn't
"care" nor should have to care about which sitebar to use, just that it
will be served by the resource named "/sitebar".
It's up to the logic that drives the "/sitebar" resource (included into
the sitemap or programmed directly into the generator) to match eventual
run-time parameters that effect the outcome.
No need to place scripting or anything inside this page.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: [C2]Access control using sitemap
Posted by Giacomo Pati <Gi...@pwr.ch>.
donaldp@mad.scientist.com wrote:
>
> On Sat, 9 Sep 2000, Stefano Mazzocchi wrote:
> > I disagree.
>
> :P
>
> > The sitemap maps "resources" to "instructions to produce them".
>
> it has the potential to - but it doesn't now from what I can
> tell (thou I may be wrong).
Don't get this ???
> > The Cocoon Sitemap is a "module-oriented programming languages for web
> > sites".
I think so, too!
> > > Aggregation means the method through which multiple pipelines are merged to
> > > produce 1 oupput. Currently cocoon has support for 1 pipeline producing
> > > multiple outputs but no support for multiple pipelines producing one
> > > output. (thou you can do it with certain hacks and perhaps via XInclude -
> > > it is not easy).
> >
> > ???
> >
> > Do you seriously think that something like this
> >
> > <page>
> > <sitebar xinclude:href="/sitebar"/>
> > <body>
> > blah blah
> > </body>
> > </page>
> >
> > is too hard to use?
>
> now make that include variable depending on what *mode* you
> are in. ie Admins have different sitebar, people outside
> company have different colors/skinning, and admins outside
> company have both applied. ALso make it variable content
> depending on time of day etc etc .
If you need logic to determine which sitebar to choose use an XSP page
instead of the above to create the xinclude.
> It is all possible - but it is just not easy.
<snip/>
> > > Web-application logic is something different again - it includes all the
> > > "doing" aspects of the system. So if your applications contacts a database
> > > and performs a whole heap of transactions, performs complex processing etc
> > > then this should be done in web-application level. Apache has a
> > > web-application framework (Turbine at java.apache.org) that includes a lot
> > > of this functionality (Identity management, authentication, authorisation,
> > > database pools, "actions" etc).
> >
> > Yes, we need to integrate Turbine functionality in C2 and I have a
> > couple of ideas on how to do this:
> >
> > 1) get turbine-like services from Avalon (db pool, identity manager,
> > etc...) as blocks
>
> thats what I am aiming for :P
>
> > 2) create a "web application language" that defines the logic of the web
> > application. This is then "compiled" into sitemap and XSP skeletons.
>
> I always dislike this approach. I really don't like
> reinventing the wheel - even if it is a slightly better
> wheel. If I want to develope stuff for a large website with
> a lot of application logic I want to do it in straight java
> and not worry about anything else. If there was a way of
> scripting inputs to actions and templating outputs via some
> xsp sheet then brilliant - just don't make me use some ugly
> xml/java/scripting cross :P
That's what I've mentioned in a earlier mail by using matcher/selectors
(or maybe a new Controller component) as Controller to process the users
interaction in straight java and use selectors/matchers to assemble the
pipeline to build the "next screen".
> > Turbine is indeed cool, but it's programmer focused and our pyramid of
> > concerns doesn't fit to their model where the programmer is also the
> > site manager (which is never the case).
>
> agreed.
>
> > > So in effect when a request comes in it goes via a "sitemap" (not to be
> > > confused with C2s sitemap) that maps request to a web-application. The
> > > web-application does it's stuff and then chooses a C2 pipeline to output
> > > via. It then fills a "context" with relevent information (like result data)
> > > and executes the pipeline with relevent context. Aggregator sits on top of
> > > this.
> >
> > More or less, this is still unclear to me...
>
> You seem to get everything except perhaps how contexts are
> filled with data from web-applications ?
>
> Basically you put data in a context and this is used by
> various stages in pipeline.
>
> For instance a request comes in and is mapped to a
> particular action. The action may do any number of things
> which result in it putting data in it's context. The
> context-data is then used at various stages in pipeline. For
> instance a username and address may be stored in the
> context-data. This is then pulled out at a generator or
> transformer stage. In many ways it is like "session" data
> per-request (yes that is a contradiction of terms :P).
This is what is called the objectModel in C2. A Map that the calling
Environment provides per request and all sitemap components have access
to and can pass data along the pipeline assembling/processing stage.
> It is especially useful in templating style web-applications
> and I suspect in C2 aswell.
>
> Context-data can also contain special "escape" commands that
> tell the C2 engine to do other things.
Matchers and Selectors can evaluate the objectModel and instruct the C2
engine what components to choose to build the pipeline. This is already
realized.
> For instance the sitemap may pass incoming data down one
> action path - the path may result in one of 5 outwards bound
> publishing pipelines. The action can place magic-data
> in context to say which pipeline to choose etc.
Exactly! That is C2 behaviour. This is easily done. Write a Selector
that inspects the objectModel and choose the pipeline to build like that
<select type="actions">
<when test="add">
<generate .../>
</when>
<when test="remove">
<generate .../>
</when>
<otherwise>
<generate .../>
</otherwise>
</select>
> Does that make any sense ? :P
>
> > > None of these applications are yet easy to use with cocoon. I have been
> > > trying to get people to adopt diferent apache products for a while but so
> > > far I have only got them to se cocoon out of these three.
> >
> > I wonder why? :)
>
> :P
>
> well it is not what you think - I think cocoon is probably
> THE leading publishing framework - I am not even familiar
> with any comparable products - but the people I got to use
> it just love it because it is easy to use (at least compared
> to other OS frameworks) and lets them do what they want
> (basically publishing from a db)
This is true for C1 but C2 can do much more.
> > More or less, I agree. But I do not see why Cocoon2 can't fit all of
> > them in fuctionality. Don't get me wrong, it's indeed hard to write web
> > applications on C2 "today"... but the functionality you need it's
> > there.. we just have to "tune it" for web applications and create
> > helpers for you.
>
> yep. It is possible - just not easy and I have not seen any
> discussion about action-orientated processing. I saw a while
> back that someone was discussing form validation but that is
> only a small part of picture.
>
> > > >And, if Cocoon isn't a web-app framework,
> > > >are there any web-app frameworks it'll integrate with easily?
> > >
> > > Well currently Jetspeed does it and it wouldn't be hard to add it to
> > > turbine. The problem is that neither is yet easy to set up and they require
> > > a lot of knowledge. Personally I wouldn't recomend it atm but in the future
> > > that is the way to go.
> >
> > I don't think it's possible to integrate turbine and Cocoon. They are
> > too different. But Cocoon can clone Turbine functionality and provide
> > better separation of concerns.
>
> actually I demo-ed cocoon pages in turbine a bit back to try
> and entice people to use turbine (they already used
> cocoon) but they disliked the difficulty of setting it
> up. It was also a major code-hack :(
>
> > > If you have a product out in next few months just write xsp to do it for
> > > you - if your product timeline is longer (end of next year) then doing it
> > > the *right* way may be in order. I am trying at the moment to get some
> > > funding to setup an integrated solution and if so will start an OS frontend
> > > next march. Heres hoping :P
> >
> > Well, that will clearly fork this project then, since we'll be aiming at
> > the same target :)
>
> hmm - Perhaps I should just wait and see :P
>
> A few questions thou -
>
> * in the future do you plan to be able to map incoming
> requests to event mosaics ?
can you explain that more in detail?
> * will sitemap be able to represent other aspects of system
> (like I mentioned a while back on Avalon list ?)
Oops, probably missed that one.
> From reading the code I was under the impression that is
> publishing orientated and from a few comments here I was
> under the same impression (which could quite possibly be
> completely wrong as I don't always pay attention :P)
I definitely beleave it can do more than only publishing.
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
Re: [C2]Access control using sitemap
Posted by do...@mad.scientist.com.
On Sat, 9 Sep 2000, Stefano Mazzocchi wrote:
> I disagree.
:P
> The sitemap maps "resources" to "instructions to produce them".
it has the potential to - but it doesn't now from what I can
tell (thou I may be wrong).
> The Cocoon Sitemap is a "module-oriented programming languages for web
> sites".
> > So what I see cocoons main strength is building the pipeline and "running" it.
>
> I agree here, but I do NOT see why this matches with "publishing" only.
it doesn't. It is perfectly capable of building complex
aggregating web-applications - but it aint easy to do it in
it - thats what I am getting at.
> > There are other requirements for a complete web-development system, two of
> > which are aggregation and application logic.
>
> Correct. I agree with this separation but unlike you, I see cocoon below
> both, not at the same level. Aggregation is a special way of generating
> content, while application logic is a complex yet specific way of
> building sitemaps and the logic that glues different resources together
> depending on user actions or enviornment parameters.
I see cocoon below aggregation but at same level as
application logic. Both IMHO should be side by side but each
to their own :P
> > Aggregation means the method through which multiple pipelines are merged to
> > produce 1 oupput. Currently cocoon has support for 1 pipeline producing
> > multiple outputs but no support for multiple pipelines producing one
> > output. (thou you can do it with certain hacks and perhaps via XInclude -
> > it is not easy).
>
> ???
>
> Do you seriously think that something like this
>
> <page>
> <sitebar xinclude:href="/sitebar"/>
> <body>
> blah blah
> </body>
> </page>
>
> is too hard to use?
now make that include variable depending on what *mode* you
are in. ie Admins have different sitebar, people outside
company have different colors/skinning, and admins outside
company have both applied. ALso make it variable content
depending on time of day etc etc .
It is all possible - but it is just not easy.
> > Aggregation will be served by Jetspeed (an apache project that is currently
> > at java.apache.org but will soon be at xml.apache.org). Jetspeed does a lot
> > more than aggregate - it mixes in lots of other options.
>
> Agreed. The goal is: Cocoon2 provides internal aggregation capabilities,
> Jetspeed drives the process.... it's more or less a Cocoon Web
> Application that uses its capabilities for a more specific purpose
> (which is creating portals and bring different informative source to the
> same site).
>
> I picture Jetspeed2 as a number of additional Cocoon sitemap components
> and some sitemaps prebuilt do mix them together. Everything down below
> is done by Cocoon, so you either can use Jetspeed or rewrite your own
> with Cocoon functionality.
yep agreed.
> > Web-application logic is something different again - it includes all the
> > "doing" aspects of the system. So if your applications contacts a database
> > and performs a whole heap of transactions, performs complex processing etc
> > then this should be done in web-application level. Apache has a
> > web-application framework (Turbine at java.apache.org) that includes a lot
> > of this functionality (Identity management, authentication, authorisation,
> > database pools, "actions" etc).
>
> Yes, we need to integrate Turbine functionality in C2 and I have a
> couple of ideas on how to do this:
>
> 1) get turbine-like services from Avalon (db pool, identity manager,
> etc...) as blocks
thats what I am aiming for :P
> 2) create a "web application language" that defines the logic of the web
> application. This is then "compiled" into sitemap and XSP skeletons.
I always dislike this approach. I really don't like
reinventing the wheel - even if it is a slightly better
wheel. If I want to develope stuff for a large website with
a lot of application logic I want to do it in straight java
and not worry about anything else. If there was a way of
scripting inputs to actions and templating outputs via some
xsp sheet then brilliant - just don't make me use some ugly
xml/java/scripting cross :P
> Turbine is indeed cool, but it's programmer focused and our pyramid of
> concerns doesn't fit to their model where the programmer is also the
> site manager (which is never the case).
agreed.
> > So in effect when a request comes in it goes via a "sitemap" (not to be
> > confused with C2s sitemap) that maps request to a web-application. The
> > web-application does it's stuff and then chooses a C2 pipeline to output
> > via. It then fills a "context" with relevent information (like result data)
> > and executes the pipeline with relevent context. Aggregator sits on top of
> > this.
>
> More or less, this is still unclear to me...
You seem to get everything except perhaps how contexts are
filled with data from web-applications ?
Basically you put data in a context and this is used by
various stages in pipeline.
For instance a request comes in and is mapped to a
particular action. The action may do any number of things
which result in it putting data in it's context. The
context-data is then used at various stages in pipeline. For
instance a username and address may be stored in the
context-data. This is then pulled out at a generator or
transformer stage. In many ways it is like "session" data
per-request (yes that is a contradiction of terms :P).
It is especially useful in templating style web-applications
and I suspect in C2 aswell.
Context-data can also contain special "escape" commands that
tell the C2 engine to do other things.
For instance the sitemap may pass incoming data down one
action path - the path may result in one of 5 outwards bound
publishing pipelines. The action can place magic-data
in context to say which pipeline to choose etc.
Does that make any sense ? :P
> > None of these applications are yet easy to use with cocoon. I have been
> > trying to get people to adopt diferent apache products for a while but so
> > far I have only got them to se cocoon out of these three.
>
> I wonder why? :)
:P
well it is not what you think - I think cocoon is probably
THE leading publishing framework - I am not even familiar
with any comparable products - but the people I got to use
it just love it because it is easy to use (at least compared
to other OS frameworks) and lets them do what they want
(basically publishing from a db)
> More or less, I agree. But I do not see why Cocoon2 can't fit all of
> them in fuctionality. Don't get me wrong, it's indeed hard to write web
> applications on C2 "today"... but the functionality you need it's
> there.. we just have to "tune it" for web applications and create
> helpers for you.
yep. It is possible - just not easy and I have not seen any
discussion about action-orientated processing. I saw a while
back that someone was discussing form validation but that is
only a small part of picture.
> > >And, if Cocoon isn't a web-app framework,
> > >are there any web-app frameworks it'll integrate with easily?
> >
> > Well currently Jetspeed does it and it wouldn't be hard to add it to
> > turbine. The problem is that neither is yet easy to set up and they require
> > a lot of knowledge. Personally I wouldn't recomend it atm but in the future
> > that is the way to go.
>
> I don't think it's possible to integrate turbine and Cocoon. They are
> too different. But Cocoon can clone Turbine functionality and provide
> better separation of concerns.
actually I demo-ed cocoon pages in turbine a bit back to try
and entice people to use turbine (they already used
cocoon) but they disliked the difficulty of setting it
up. It was also a major code-hack :(
> > If you have a product out in next few months just write xsp to do it for
> > you - if your product timeline is longer (end of next year) then doing it
> > the *right* way may be in order. I am trying at the moment to get some
> > funding to setup an integrated solution and if so will start an OS frontend
> > next march. Heres hoping :P
>
> Well, that will clearly fork this project then, since we'll be aiming at
> the same target :)
hmm - Perhaps I should just wait and see :P
A few questions thou -
* in the future do you plan to be able to map incoming
requests to event mosaics ?
* will sitemap be able to represent other aspects of system
(like I mentioned a while back on Avalon list ?)
Re: [C2]Access control using sitemap
Posted by Stefano Mazzocchi <st...@apache.org>.
Peter Donald wrote:
>
> At 09:57 8/9/00 -0400, you wrote:
> >Peter,
> >
> >Could you expand a little on exactly what you thing the differences are
> >between a web-publishing framework and a web-application framework (incl.
> >what responsibilities each has)?
>
> well there is a few ways of looking at it really. The way I choose to look
> at it (which may differ from others :P) is as follows. Cocoon2 is primarily
> about passing fragments through a pipeline. By fragments I mean XML
> fragments. The pipeline starts at generators, then transformers and then
> serializers. Each of these are considered "stages" in the pipeline.
>
> The result of a particular stage is determined by
> 1> What type of stage it is ? (ie generator/transformer/serializer)
> 2> What is purpose of stage ? (ie xslt transformer stage transfroms via xsl)
> 3> Context in which pipeline is called (ie user session information, logic
> vairables, web-application parameters etc)
>
> Cocoon2 is great in that it gives great support to 1 and 2 and minimalist
> support to 3.
I disagree.
The sitemap maps "resources" to "instructions to produce them".
The Cocoon Sitemap is a "module-oriented programming languages for web
sites".
> So what I see cocoons main strength is building the pipeline and "running" it.
I agree here, but I do NOT see why this matches with "publishing" only.
It's like saying that since Java strenght is building a program (compile
it) and run it (executing it), it cannot do 3D games.
C1 is totally focused on publishing and I grant you that, but C2
introduced the pipeline to be able to do "everything" (see below)
> There are other requirements for a complete web-development system, two of
> which are aggregation and application logic.
Correct. I agree with this separation but unlike you, I see cocoon below
both, not at the same level. Aggregation is a special way of generating
content, while application logic is a complex yet specific way of
building sitemaps and the logic that glues different resources together
depending on user actions or enviornment parameters.
> Aggregation means the method through which multiple pipelines are merged to
> produce 1 oupput. Currently cocoon has support for 1 pipeline producing
> multiple outputs but no support for multiple pipelines producing one
> output. (thou you can do it with certain hacks and perhaps via XInclude -
> it is not easy).
???
Do you seriously think that something like this
<page>
<sitebar xinclude:href="/sitebar"/>
<body>
blah blah
</body>
</page>
is too hard to use?
> Aggregation will be served by Jetspeed (an apache project that is currently
> at java.apache.org but will soon be at xml.apache.org). Jetspeed does a lot
> more than aggregate - it mixes in lots of other options.
Agreed. The goal is: Cocoon2 provides internal aggregation capabilities,
Jetspeed drives the process.... it's more or less a Cocoon Web
Application that uses its capabilities for a more specific purpose
(which is creating portals and bring different informative source to the
same site).
I picture Jetspeed2 as a number of additional Cocoon sitemap components
and some sitemaps prebuilt do mix them together. Everything down below
is done by Cocoon, so you either can use Jetspeed or rewrite your own
with Cocoon functionality.
> Web-application logic is something different again - it includes all the
> "doing" aspects of the system. So if your applications contacts a database
> and performs a whole heap of transactions, performs complex processing etc
> then this should be done in web-application level. Apache has a
> web-application framework (Turbine at java.apache.org) that includes a lot
> of this functionality (Identity management, authentication, authorisation,
> database pools, "actions" etc).
Yes, we need to integrate Turbine functionality in C2 and I have a
couple of ideas on how to do this:
1) get turbine-like services from Avalon (db pool, identity manager,
etc...) as blocks
2) create a "web application language" that defines the logic of the web
application. This is then "compiled" into sitemap and XSP skeletons.
Turbine is indeed cool, but it's programmer focused and our pyramid of
concerns doesn't fit to their model where the programmer is also the
site manager (which is never the case).
> So in effect when a request comes in it goes via a "sitemap" (not to be
> confused with C2s sitemap) that maps request to a web-application. The
> web-application does it's stuff and then chooses a C2 pipeline to output
> via. It then fills a "context" with relevent information (like result data)
> and executes the pipeline with relevent context. Aggregator sits on top of
> this.
More or less, this is still unclear to me...
> None of these applications are yet easy to use with cocoon. I have been
> trying to get people to adopt diferent apache products for a while but so
> far I have only got them to se cocoon out of these three.
I wonder why? :)
> There are changes
> in place to make usage of these products easier (specifically turbine has a
> simple developers kit setup in progress) but that still leaves a lot of the
> Integration for you to do. Currently there is also a move to standadise the
> packaging of all apache products (I believe PMC is or will in future be
> discussing this possibility) which will help this progress.
yes, but it will take time.
> SO in conclusiong, publishing is about managing and running pipelines,
> applications is about doing stuff and filling "context" data to pipeline
> start and aggregation is about binding multiple pipelines to one output.
More or less, I agree. But I do not see why Cocoon2 can't fit all of
them in fuctionality. Don't get me wrong, it's indeed hard to write web
applications on C2 "today"... but the functionality you need it's
there.. we just have to "tune it" for web applications and create
helpers for you.
Just like taglibs require XSP down below, but it's a pain to use XSP
with logic built in.
Sitemaps will be the same: you can write your own sitemap if it's easy,
or use tools to "autogenerate" your sitemap from some more specific
schema that defines what to do with your application and where to fit
actions/screens and all that.
> >And, if Cocoon isn't a web-app framework,
> >are there any web-app frameworks it'll integrate with easily?
>
> Well currently Jetspeed does it and it wouldn't be hard to add it to
> turbine. The problem is that neither is yet easy to set up and they require
> a lot of knowledge. Personally I wouldn't recomend it atm but in the future
> that is the way to go.
I don't think it's possible to integrate turbine and Cocoon. They are
too different. But Cocoon can clone Turbine functionality and provide
better separation of concerns.
> If you have a product out in next few months just write xsp to do it for
> you - if your product timeline is longer (end of next year) then doing it
> the *right* way may be in order. I am trying at the moment to get some
> funding to setup an integrated solution and if so will start an OS frontend
> next march. Heres hoping :P
Well, that will clearly fork this project then, since we'll be aiming at
the same target :)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
RE: [C2]Access control using sitemap
Posted by Per Kreipke <pe...@onclave.com>.
> Peter Donald wrote:
> At 09:57 8/9/00 -0400, you wrote:
> >Peter,
> >
> >Could you expand a little on exactly what you thing the differences are
> >between a web-publishing framework and a web-application framework (incl.
> >what responsibilities each has)?
>
> well there is a few ways of looking at it really. The way I choose to look
> at it (which may differ from others :P) is as follows. Cocoon2 is
> primarily
> about passing fragments through a pipeline. By fragments I mean XML
> fragments. The pipeline starts at generators, then transformers and then
> serializers. Each of these are considered "stages" in the pipeline.
Ok, we're talking about C2 here and I agree with your view so far.
> The result of a particular stage is determined by
> 1> What type of stage it is ? (ie generator/transformer/serializer)
> 2> What is purpose of stage ? (ie xslt transformer stage
> transfroms via xsl)
> 3> Context in which pipeline is called (ie user session information, logic
> vairables, web-application parameters etc)
>
> Cocoon2 is great in that it gives great support to 1 and 2 and minimalist
> support to 3.
>
> So what I see cocoons main strength is building the pipeline and
> "running" it.
>
> There are other requirements for a complete web-development system, two of
> which are aggregation and application logic.
>
> Aggregation means the method through which multiple pipelines are
> merged to
> produce 1 oupput. Currently cocoon has support for 1 pipeline producing
> multiple outputs but no support for multiple pipelines producing one
> output. (thou you can do it with certain hacks and perhaps via XInclude -
> it is not easy).
I actually was interested in Cocoon because I thought it could merge
multiple pipes into one output. I was in fact using XInclude to include XML
fragments (like user info, skins, globals) and XSL to shape (filter) the
results into a another XML hierarchy which would then be styled. E.g. a two
stage XSLT pipeline. I think this is very powerful.
> Aggregation will be served by Jetspeed (an apache project that is
> currently
> at java.apache.org but will soon be at xml.apache.org). Jetspeed
> does a lot
> more than aggregate - it mixes in lots of other options.
True. However, as you mention later, it also seems difficult to learn.
> Web-application logic is something different again - it includes all the
> "doing" aspects of the system. So if your applications contacts a database
> and performs a whole heap of transactions, performs complex processing etc
> then this should be done in web-application level. Apache has a
> web-application framework (Turbine at java.apache.org) that includes a lot
> of this functionality (Identity management, authentication, authorisation,
> database pools, "actions" etc).
Fair enough. Two comments. First, I thought I read on this list that Turbine
was going to be used by C2 at some point. I was hoping that it's
functionality would thereby become available to me.
Second, I've begun to look at Cocoon as a two way pipeline and fooling
around to see if I can make it work (please tell me if it's been done
already!). That is, each input to the system (e.g. POST) can have multiple
outputs (e.g. to calling client and backend system), enumerated in the
sitemap as transformations themselves.
For example, I'm hoping to set something up that takes an POST and splits it
into two (or more) pipelines; one which returns a result back to the user,
and one (or more) which makes changes to the system. A simple version can
already be done: XSP page takes a form and executes some Java code to insert
records into the database using JDBC (or, better, the esql taglib).
I think it would be interesting, and the proper separation of responsibility
in the opposite direction from Cocoon's original design, for the input
request to generate multiple outbound 'messages' for other systems. Those
messages should of course simply be XML snippets, which can of course be
created by XSP and XSL transforms.
Am I making any sense? Basically, I could see Cocoon becoming a great way to
write middleware, not just a publishing system. The benefit of a system like
C2 where you can insert new elements in the pipeline is that you can let
Cocoon extend as far in either direction from its center as you want, just
add or subtract transforms.
Outbound:
Browser <- HTML <- XSLT <- XML <- XSP <- {JDBC | XInclude | Files | XML-RPC
| Other}
Inbound:
Browser -> HTTP -> XSL -> XML -> XSP -> {XML store | MSSQLXML | XQL DB |
XML-RPC | ...}
> So in effect when a request comes in it goes via a "sitemap" (not to be
> confused with C2s sitemap) that maps request to a web-application. The
> web-application does it's stuff and then chooses a C2 pipeline to output
> via. It then fills a "context" with relevent information (like
> result data)
> and executes the pipeline with relevent context. Aggregator sits on top of
> this.
As mentioned above, while I use what you're describing right now, I'm hoping
to use only Cocoon in the future.
> None of these applications are yet easy to use with cocoon. I have been
> trying to get people to adopt diferent apache products for a while but so
> far I have only got them to se cocoon out of these three. There
> are changes
> in place to make usage of these products easier (specifically
> turbine has a
> simple developers kit setup in progress) but that still leaves a
> lot of the
> Integration for you to do. Currently there is also a move to
> standadise the
> packaging of all apache products (I believe PMC is or will in future be
> discussing this possibility) which will help this progress.
Great! But, uh, who's PMC?
> SO in conclusiong, publishing is about managing and running pipelines,
> applications is about doing stuff and filling "context" data to pipeline
> start and aggregation is about binding multiple pipelines to one output.
>
> >And, if Cocoon isn't a web-app framework,
> >are there any web-app frameworks it'll integrate with easily?
>
> Well currently Jetspeed does it and it wouldn't be hard to add it to
> turbine. The problem is that neither is yet easy to set up and
> they require
> a lot of knowledge. Personally I wouldn't recomend it atm but in
> the future
> that is the way to go.
Sigh.
> If you have a product out in next few months just write xsp to do it for
> you - if your product timeline is longer (end of next year) then doing it
> the *right* way may be in order. I am trying at the moment to get some
> funding to setup an integrated solution and if so will start an
> OS frontend
> next march. Heres hoping :P
Sigh again, that's a long time. And good luck on your efforts!
Will let you know if I make any progress.
Per.
RE: [C2]Access control using sitemap
Posted by Peter Donald <do...@mad.scientist.com>.
At 09:57 8/9/00 -0400, you wrote:
>Peter,
>
>Could you expand a little on exactly what you thing the differences are
>between a web-publishing framework and a web-application framework (incl.
>what responsibilities each has)?
well there is a few ways of looking at it really. The way I choose to look
at it (which may differ from others :P) is as follows. Cocoon2 is primarily
about passing fragments through a pipeline. By fragments I mean XML
fragments. The pipeline starts at generators, then transformers and then
serializers. Each of these are considered "stages" in the pipeline.
The result of a particular stage is determined by
1> What type of stage it is ? (ie generator/transformer/serializer)
2> What is purpose of stage ? (ie xslt transformer stage transfroms via xsl)
3> Context in which pipeline is called (ie user session information, logic
vairables, web-application parameters etc)
Cocoon2 is great in that it gives great support to 1 and 2 and minimalist
support to 3.
So what I see cocoons main strength is building the pipeline and "running" it.
There are other requirements for a complete web-development system, two of
which are aggregation and application logic.
Aggregation means the method through which multiple pipelines are merged to
produce 1 oupput. Currently cocoon has support for 1 pipeline producing
multiple outputs but no support for multiple pipelines producing one
output. (thou you can do it with certain hacks and perhaps via XInclude -
it is not easy).
Aggregation will be served by Jetspeed (an apache project that is currently
at java.apache.org but will soon be at xml.apache.org). Jetspeed does a lot
more than aggregate - it mixes in lots of other options.
Web-application logic is something different again - it includes all the
"doing" aspects of the system. So if your applications contacts a database
and performs a whole heap of transactions, performs complex processing etc
then this should be done in web-application level. Apache has a
web-application framework (Turbine at java.apache.org) that includes a lot
of this functionality (Identity management, authentication, authorisation,
database pools, "actions" etc).
So in effect when a request comes in it goes via a "sitemap" (not to be
confused with C2s sitemap) that maps request to a web-application. The
web-application does it's stuff and then chooses a C2 pipeline to output
via. It then fills a "context" with relevent information (like result data)
and executes the pipeline with relevent context. Aggregator sits on top of
this.
None of these applications are yet easy to use with cocoon. I have been
trying to get people to adopt diferent apache products for a while but so
far I have only got them to se cocoon out of these three. There are changes
in place to make usage of these products easier (specifically turbine has a
simple developers kit setup in progress) but that still leaves a lot of the
Integration for you to do. Currently there is also a move to standadise the
packaging of all apache products (I believe PMC is or will in future be
discussing this possibility) which will help this progress.
SO in conclusiong, publishing is about managing and running pipelines,
applications is about doing stuff and filling "context" data to pipeline
start and aggregation is about binding multiple pipelines to one output.
>And, if Cocoon isn't a web-app framework,
>are there any web-app frameworks it'll integrate with easily?
Well currently Jetspeed does it and it wouldn't be hard to add it to
turbine. The problem is that neither is yet easy to set up and they require
a lot of knowledge. Personally I wouldn't recomend it atm but in the future
that is the way to go.
If you have a product out in next few months just write xsp to do it for
you - if your product timeline is longer (end of next year) then doing it
the *right* way may be in order. I am trying at the moment to get some
funding to setup an integrated solution and if so will start an OS frontend
next march. Heres hoping :P
Cheers,
Pete
*------------------------------------------------------*
| "Nearly all men can stand adversity, but if you want |
| to test a man's character, give him power." |
| -Abraham Lincoln |
*------------------------------------------------------*
RE: [C2]Access control using sitemap
Posted by Per Kreipke <pe...@onclave.com>.
Peter,
Could you expand a little on exactly what you thing the differences are
between a web-publishing framework and a web-application framework (incl.
what responsibilities each has)? And, if Cocoon isn't a web-app framework,
are there any web-app frameworks it'll integrate with easily?
Per.
> At 04:18 8/9/00 +0300, you wrote:
> >> IIRC, there was a policy to not handle authorisation and authentication
> >> in the sitemap, and let the web server handle that.
> >
> >Is there any reason not to use sitemap as basis of creating
> access control
> >system?
> >
> >It's not going to be only access control, I plan to have ability
> to produce
> >dynamic content based on userprofile in database.
>
> Cocoon is designed porimarily with the vision of web-publishing framework.
> What you are talking about is a web-application framework. You *can*
> incorporate access-control, complex processing etc but it is not really
> what it is designed for and you may end up doing things the *hard-way*.
> Until there is a solution even close to C2 with publishing however it may
> be only way.
>
>
>
>
> Cheers,
>
> Pete
>
> *------------------------------------------------------*
> | "Nearly all men can stand adversity, but if you want |
> | to test a man's character, give him power." |
> | -Abraham Lincoln |
> *------------------------------------------------------*
>
Re: [C2]Access control using sitemap
Posted by Peter Donald <do...@mad.scientist.com>.
At 04:18 8/9/00 +0300, you wrote:
>> IIRC, there was a policy to not handle authorisation and authentication
>> in the sitemap, and let the web server handle that.
>
>Is there any reason not to use sitemap as basis of creating access control
>system?
>
>It's not going to be only access control, I plan to have ability to produce
>dynamic content based on userprofile in database.
Cocoon is designed porimarily with the vision of web-publishing framework.
What you are talking about is a web-application framework. You *can*
incorporate access-control, complex processing etc but it is not really
what it is designed for and you may end up doing things the *hard-way*.
Until there is a solution even close to C2 with publishing however it may
be only way.
Cheers,
Pete
*------------------------------------------------------*
| "Nearly all men can stand adversity, but if you want |
| to test a man's character, give him power." |
| -Abraham Lincoln |
*------------------------------------------------------*
Re: [C2]Access control using sitemap
Posted by Lassi Immonen <li...@urova.fi>.
> > I really would like to use Cocoon2 in our web/content management
project.
> > Could someone give some advice how to implement user
identification/access
> > control using sitemap? It has to be somekind of selector and all
requests
> > has to go through same point?
>
> IIRC, there was a policy to not handle authorisation and authentication
> in the sitemap, and let the web server handle that.
Is there any reason not to use sitemap as basis of creating access control
system?
It's not going to be only access control, I plan to have ability to produce
dynamic content based on userprofile in database.
>
> However, you could write a selector to handle it, yes. Off the top of
> my head: just wrap all pages to be protected and test the uses
> credentials, if it fails redirect to a "permission denied" page.
I cannot see any other examples as to start other than recently added
BrowserSelector, so would my "AccessSelector" work like:
<map:selector name="access" factory="my.AccessSelector">
??
</map:selector>
and
<map:match pattern="mysite/*">
<map:select type="access">
<map:when test="granted">
?? how to use this as starting point to all my content residing under
mysite/
</map:when>
<map:otherwise>
<map:redirect-to uri="login"/>
</map:otherwise>
</map:select>
</map:match>
And in AccessSelector code, can I access database through JDBC? It's not
very clear to me how to maintain for example my custom Users-object live
somewhere with possible connection to database and accessible from
AccessSelector? Any advice?
Anyway from BrowserSelector code I can see how one can get request object.
> There was a discussion about this several months ago - have a look in
> the archives.
It seems that at http://xml-archive.webweaving.org has been down for a
while. Is there any alternative method to search cocoon-dev?
Thanks
Lassi Immonen
Re: [C2]Access control using sitemap
Posted by Ross Burton <ro...@mail.com>.
> I really would like to use Cocoon2 in our web/content management project.
> Could someone give some advice how to implement user identification/access
> control using sitemap? It has to be somekind of selector and all requests
> has to go through same point?
IIRC, there was a policy to not handle authorisation and authentication
in the sitemap, and let the web server handle that.
However, you could write a selector to handle it, yes. Off the top of
my head: just wrap all pages to be protected and test the uses
credentials, if it fails redirect to a "permission denied" page.
There was a discussion about this several months ago - have a look in
the archives.
Ross Burton