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] ¿FlowMap?
Date Tue, 17 Apr 2001 03:02:53 GMT
----- Original Message -----
From: "Jeremy Quinn" <jeremy@media.demon.co.uk>

> Just a thought ... Now Actions have got xml configuration files, are they
> going to be 'the new XSP'? ie. it's only a short step before people want
> them compiled on the fly ... ?


too right!  These new actions are fantastically useful (cheers Berin - I
don't think AbstractComplimentaryConfigurableAction is too confusing a name
either, although if they weren't quite so Complimentary, I'd consider
dropping that bit)

I've got some set up to maintain my postgres database structure, and I'm
writing a taglib to output abstract forms based on the same configuration
files;  this captures the most annoying aspect of them all......the 10 or so
application cutting points that need updated to add one measly new database
field!

Having said that I don't think this is the best solution.  I think the best
solution would be have data entities modelled as persistent components which
are configured by XSP code within an expanded domain for that language (in
which XSP becomes the canonical language for configuring components
requiring dynamic configuration in an XML server....many components, such as
serverpages, would have natural XML representations of their state; others,
such as flowmaps, wouldn't).

A single action could then be used to interprate Requests to see if they
represented a message to be passed to some component (this would remove the
confusing magic-matching on the "cocoon-action" parameter) and then dispatch
the message to the appropriate component method.  The XML representation of
such components could then be aggregated into the content of whatever
webapp.  Then such webapps would be constructed in a properly
component-oriented style; their implementations would be concise and easy to
maintain.

(although powerful, I don't think actions + sitemaps alone form a very sound
basis for a good programming methodology.)

- Allan

----- Original Message -----
From: "Jeremy Quinn" <jeremy@media.demon.co.uk>
To: <cocoon-dev@xml.apache.org>
Sent: Monday, April 16, 2001 9:53 AM
Subject: Re: [C2] ¿FlowMap?


> At 3:48 PM +0200 15/4/01, giacomo wrote:
> >On Sat, 14 Apr 2001, Jeremy Quinn wrote:
> >
>
> Hi Giacomo, thanks for your reply.
>
> I am just trying to work out where to do all the jobs the Crudlet TagLib
> does, if they were not going to be done in a TagLib (just trying to work
> out if it is possible/desirable)
>
>
> >> Could the FlowMap be implemented as an Action?
> >
> >?? What are you thinking a FlowMap is?
>
> Something that allows me to map out (then control) the progress of my
webApp
>   what needs to happen to "get here"
> where I am allowed to go next,
> what is the scope of the objects we are manipulating.
>
> For instance if I could use something like a flo map to say, when you come
> here I'll make you a new object that you are going to fill in over the
next
> couple of pages, then commit the object to the Space, and throw it away
(if
> you take this exit), unless of course you did not fill it in properly, or
> wandered off, in which case, when you come back you can carry on filling
it
> in as long as you are within the session timeout.
>
>
> >An Action can implement whatever
> >it likes to.
>
> Just a thought ... Now Actions have got xml configuration files, are they
> going to be 'the new XSP'? ie. it's only a short step before people want
> them compiled on the fly ... ?
>
>
> >> Load your flowmap.xml into your context (SiteMap or Servlet context?)
> >> Keep track of your user in a Session.
> >> Provide <action/> <back/> etc.
> >>
> >> Can Actions access Sessions?
> >
> >Of course
>
> Phew! ;)
>
> >> Could Session objects be visible as XSLT Stylesheet params?
> >
> >I don't like it.
>
> Oh dear, Donald simultaneously suggested it too.
>
> >> What if they implemented XMLFragment?
> >
> >I'm not familiar with XMLFragment
>
> An Interface initially developed for Objects fed to XSP, has toDOM and
> toSAX methods.
>
> We got Beans, we update them, (easily handled by an Action) we output them
> as XML (give it to the StyleSheet as an XML Fragment and let the XSL
Author
> take the bits they want).
>
>
>
> Sorry if my questions appear daft :)
>
>
>
> regards Jeremy
>
> --
>    ___________________________________________________________________
>
>    Jeremy Quinn                                           Karma Divers
>                                                        webSpace Design
>                                             HyperMedia Research Centre
>
>    <mailto:sharkbait@mac.com>     <http://www.media.demon.co.uk>
>     <phone:+44.[0].20.7737.6831>        <pager:jermq@sms.genie.co.uk>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message