cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Allan Erskine" <a.ersk...@cs.ucl.ac.uk>
Subject Re: [C2] state and actions proposal
Date Thu, 01 Feb 2001 06:30:48 GMT
> > Allan Erskine wrote:
> >
> > Hi
> >
> > I have a proposal for actions in C2.  The proposal is that an action
should be definable in the context of the state that it
> > affects, and the action's possible parameters.  This would necessitate
being able to define state entities in the sitemap, along
> > with the actions that can affect these entities.
> >
> > Furthermore, it should be possible to define an action's interface (ie
the state it affects, it's parameters, and what it returns
> > [+to where!]) separately from it's implementation.
>
>
> Not to put a damper on things, but we have two things at work with
> Actions:
>
> 1) They need to be simple--to that end they deal only with request
>    params and such.
> 2) The Servlet 2.3 proposal covers (duplicates?) the actions with
>    the Filters.  It would not be surprising to see Actions living
>    as long as they are needed, and replaced by Filters when Servlet
>    2.3 becomes widely available.
>
> This is, of course, unless we find a _really_ compelling reason to
> do it all in Cocoon.

OK - granted, my "actions" rant must have seemed pie in the sky; I don't
want to hijack the whole action framework...I'm sure you have a better
notion of where they're headed than I do, as I'm quite new to cocoon.

What I'm really worried about is the way these actions get matched with
requests before calling their handling classes.  It's very strongly coupled
and low-level, and although I'm sure web developers will take to it (since
they've always had to do things the hard way), I can't help thinking there
is scope for a layer on top of actions.

I've read the servlet 2.3 spec, and the similarlity between cocoon actions
and filters only sounds alarm bells for me.  Cocoon 2 is shaping up to be a
general purpose presentation engine...the servlet 2.3 spec is a spec for
servlet engines.  Filters are trying to abstract away from the request
response model, and I think cocoon should be moving in the same direction,
only faster, and with better scope for modularity than filters will provide.

For all the great work that's been done in the name of SoC, I think it would
be a shame if C2 didn't properly abstract away from the entities it deals
with....Writing action handling classes, labelling some actions, and pairing
them off with similarly labelled request params introduces more strong
coupling than you can shake a stick at.  If cocoon were mine, I'd like to
hide this complexity and "magic" matching with a properly abstracted
interface.

Please pardon my steam...I hope somebody is at least a tiny bit with me on
this; if not I'll just have to post some _REALLY_ compelling reasons!  (Or
quit while I'm behind....)

- Allan

>
> >
> > In other words, there should be a construct analogous to classes from OO
languages at sitemap level, along with the ability to
> > access entities of a particular class at pipeline level (xsp level too).
> >
> > eg
> >
> > <map:classes>
> >     <map:class name=....>
> >         <schema>
> >             <attr name="id" type="integer">    (insert favorite schema
defn method here)
> >             ...
> >         </schema>
> >         <interface>
> >             <action name="...">
> >                 <param ...>
> >                 <returns ....>
> >             </action>
> >         ....
> >         <implementation>
> >             <view src="..">                --- most but not all entities
would allow a virtual SAX
> >                                     representation
> >             <action name="...">
> >                   ----action implementations here---
> >         </implementation>
> >     </map:class>
> >     ...
> > </map:classes>
> >
> > The class/entity system need only be complex enough to allow C2 to
fulfil it's mandate as an interactive presentation layer, and
> > NO MORE.  The entity management responsibilities would lie as before
with whatever RDBMS, CMS, etc
> >
> > Among the many benefits of this I can imagine, the most important IMHO
would be the ability to write general purpose actions for
> > these enties, e.g. a general table class, allowing insert, update,
delete actions which could be reused by all entities of that
> > class;  table view class (entities constructed according to view
conditions, e.g. XML query, or SQL query etc); general purpose
> > entity validation...etc etc etc
> >
> > The abstraction provided would also mark a web first....C2 web apps
would be portable!!  So long as the sitemap constructs and xsp
> > pages were written in terms of the abstract class/action definitions,
the implementation could be changed from RDBMS to CMS to EJB
> > and back again without a grey hair on anyones head.
> >
> > If someone can convince me this is nonsense, I'll pack my boots.  If
anyone thinks there might be something in it, I'll send a few
> > code snippets from my scratch-pad...
> >
> > - Allan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>



Mime
View raw message