Alan <[EMAIL PROTECTED]> 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...
