cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Lowe <mel...@gmail.com>
Subject Re: [OT]Re: [RT] How scripting made me hate java
Date Tue, 22 Feb 2005 22:57:59 GMT
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
<peter.hunsberger@gmail.com> wrote:
> On Tue, 22 Feb 2005 17:00:19 +0100, Stefano Mazzocchi
> <stefano@apache.org> 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
>

Mime
View raw message