this might be useful, it might not be. But personally I'd like to be able to store the mappings information in something like the cocoon.xconf in an xml format, it could be the struts/jsf/spring talking but having the servlet configuration in one place makes sense (to me, there could be good reasons why it wouldn't).
This could cause problems with reloads and suchlike, but the one clear advantage I see is that it would help prevent the temptation of coupling the directory struture to the view controllor logic. definition/binding/template files also seem to cover the same ground in different ways. I haven't thought the case through yet or seen whats going on in 2.2 enough to have even any weak views on this. But on the surface couldn't all this stuff live in one form.xml file? The validations to be performed, the ids of the fields, the bindings? To really go off on one, an efficent way of accessing the binding object. form.getBinding().getPath() or form.binding.path, so when a command is executed the target method can be accessed. var insertCMD = cocoon.parameters.insertCMD: var deleteCMD = cocoon.parameters.deleteCMD: var businessObject = cocoon.parameters.businessObj; var form = ... var commandExecutor = var setMethod = form.getBinding().getPath(); var bo = Packages.java.lang.Class.forName(businessObject).newInstance(); and so on. The idea being that the same java class or flowscript can deal with the crud actions and make the most of cocoon's binding mechanism.The actions/commands defined as parameters when the function is called. A new form and its processing could be a matter of creating a new xml file (assuming the 3 in 1 isn't complete crack smoking). Sorry I only meant to write the first paragraph. Mark On Tue, 22 Feb 2005 10:29:23 -0600, Peter Hunsberger <[EMAIL PROTECTED]> wrote: > On Tue, 22 Feb 2005 17:00:19 +0100, Stefano Mazzocchi > <[EMAIL PROTECTED]> wrote: > > Wojciech Gdela wrote: > > > Hello, > > > > <sni>OO pipeline discussion (sorta)</snip> > > > It's also true that we know a lot more than pipeline caching is more a > > myth than a real useful thing, at times and more so in complex web > > applications. > > Hmm, I wouldn't say that, it's just hard to do well: you end up > having to break down every different level of data provider into it's > own generator or source and having some kind of complex cache > invalidation that can walk orthogonally across the validity objects > for these generators/sources. Having more-or-less completed this for > our app I can say we get definite performance benefits. > > If I had time I'd like to comment more, but basically we ended up > building a sort of miniature (3 table) relational database in memory > to manage the cache (maps many screens to many data sources). Sources > register invalidation event handlers within it by "invalidation key > type". Invalidation keys can determine if they match a particular > event (which passes in a candidate key) and if they do they blow away > the validity. Different types of keys can decide whether they care > about other types of keys and to what extent (complete equality, > partial equality, etc.) That way we get out of the hassle of trying to > inter-relate every sources dependencies with every other source in > some kind of complex graph. > > Under this scheme we no longer use the Cocoon sitemap for matching, > pretty much everything is a single generic Cocoon generator. We then > use Java based lookups (a factory pattern into our EJB layer) to > determine the sources for various requests. So basically, we already > have an existence proof that you can have dynamic pipeline > construction and caching living in coexistence within Cocoon. > > > Am I ready to surrender to 'dynamic pipelines'? not yet, but I'm ready > > to admit that we know better today and given what cocoon has become, it > > might open the door to even better innovation. > > > > So, I welcome RTs on the topic of the 'unification' of sitemap + flow > > into a 'cocoonscript' that has SAX pipelines as native constructs, even > > if I urge people to realize that sitemaps will have to be supported for > > a long time in the future, given our user base. > > Well, you may recall my old push for an XSLT based sitemap.... Still > think it would be conceptually a good way of doing this, but it seems > pretty obvious that what people want is something more script like and > not more XSLT! > > Given that, having a way to configure component declarations (in an > XML sitemap type thing) that are then only referenced/matched in some > kind of flowscript like language (taking the sitemap pipelines out of > the picture) seems natural? Eg, prebuilt Javascript pipeline objects. > If you want to do this in Java, then really, source resolvers already > give you (more-or-less) the Cocoon way of doing this... > > -- > Peter Hunsberger >
