cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hunsberger, Peter" <Peter.Hunsber...@stjude.org>
Subject RE: [RT] Cocoon Input Model
Date Tue, 02 Mar 2004 17:27:05 GMT
Alan <alan-cocoon-dev@engrm.com> writes:
 
<snip/>

> 
> > > I am using the matching facilities agressively. It is how I see a
> > >     web application. A GET are function calls, the URI's are the
> > >     function signatures, the pipelines are the function 
> bodies. Its
> > >     stateless functional programming to me.
> > 
> > Well, yes, but you're encoding application logic in the 
> sitemap.  That 
> > just doesn't scale;  the sitemap isn't supposed to be a programming 
> > language.  REST is fine, but flow isn't anti-REST (RESTless ?)...
> 
> It's a pity that it doesn't scale then, because it's been a nice way
>     to do things.
>     
>     I'm not putting much logic in the sitemap except to
>     match the path part of the URI. Parameter handling is done by
>     whoever intercepts the path. Most of my logic is in XSLT.
> 
>     I came to Cocoon from XSLT. I was already chaining
>     trasformations. I'd made the most of a little matching engine
>     I'd written. I'm using Cocoon thus.
> 
>     Flow isn't anti-REST, but, yeah, the sitemap looks like a REST
>     method dispatch engine.
>     
>     Maybe that is what I want. Maybe its easy to do this in flow,
>     and if I want to be declartive, my flowscript can read a
>     configuration file.

I suspect that once you start to parameterize and generalize this you'll
find that flow doesn't need to read much in the way of a configuration
file...  However, if it does, I'll suggest that this configuration is
itself stored in your "database" and treated the same way as any of your
other data (although it's technically metadata).

<snip/>

> 
> Two things.
> 
>     1) I jumped into this because it was a discussion of input
>        pipelines and I was interested in it in terms of Momento.
>        
>        I know there is some use of XUpdate in Cocoon, but that is
>        the preferred language for Momento. I see the penultimate
>        step in an input pipeline as a transform to XUpdate, the
>        ultimate step a call to Momento.
>        
>        I think if someone were to develop a simpiliar declartive
>        language to describe a complex set of SQL updates in XML, one
>        cold use the same notion to update an SQL database. This,
>        rather than writing loops, JDBC calls, and such in Java.

Probably a good thing, though one we're a long way from.  

We've got a relational DB with an abstract object model underneath
everything we do.  The entire system (front and back end) is described
in metadata.  The interface to Cocoon from the back end is via proxied
EJB's.  Cocoon has about a dozen generators hitting these proxies and
they in turn feed about a dozen XSLT's.  Nothing involved directly with
the UI knows anything other than the object model, although a layer of
XSLT have the responsibility of assembling instances of the object model
from the metadata, screen specific templates, security information and
the actual data.  In theory, we can remove the HTML producing XSLT and
slap on, say, a set of PDF producing XSLT and change nothing else in the
system...

>     2) I see that this is more of a disucssion of the
>        deserialization and form validation. I will be able to do the
>        above. Nothing is going to move out from underneith those
>        plans while I'm implementing them. 

Agreed!

> 
> Also, thanks for all the knowledge.
 
Anytime...


Mime
View raw message