I've somewhat set the original existential feelings asside and went in through the door of pragmatics... still I'ld have to conclude that I'm missing some more application-object oriented contracts in the whole of Cocoon... and it's quite well reflected by the
/* FIXME */ remarks lingering in the code here and there... How are we to 'address' business objects that need to be influencing the cocoon pipeline?
See, if your pipeline needs to mingle itself with some xml or xslt there is the wealth of
cocoon: and whatnot stuff to declare in the @src's of the sitemap... if what needs to be sliced in is a true Java Object (be it bean, form-model, js wrapper object, continuation,...) then suddenly the nice and obvious addressing scheme is to be replaced with mysterious (i.e. conspired behind the controlling back of the sitemap) strings as Map keys into (pick randomly one out of) Environment, ObjectModel, Request and Session... [and euh, "bean-dict" and "kont" are quite inspirationless choices indeed :-)]
It's too vague as an idea, but maybe some source of the kind
object: could be giving access to an object space declared by the sitemap (for reading and writing).... of course current sources are quite targetted to being wrappers around inputstreams...
Or am I trying to compare apples with pears?
Another thing that strikes me is that in most examples to date the pipelines become application-technique-specific... that might be logical at first glance, yet still I'ld like to see some mechanism to easily reuse application-agnostic pipes in different application-controllers: say have one WoodyForm, that together with it's (one) publication pipe gets reused in two distinct use cases, one handled by flowscript, and one by actions?
Mmm, Maybe just the definition of clever
In the mean time, actively hoping Betrand's ball is right...# Posted by mpo at 10:30 PM | TrackBack