On 3/20/07, Daniel Fagerstrom <[EMAIL PROTECTED]> wrote:
Grzegorz Kossakowski skrev:
> Hello,
>
> In this e-mail I would like to discuss my random thoughts on unified
> expression handling and unified object model in
> Cocoon. Fundamentals has been outlined by Daniel in this thread:
> http://article.gmane.org/gmane.text.xml.cocoon.devel/47854 and I'm not
> going to repeat it. My aim is to comment original
> proposal and talk about actual plan how to get it implemented.
>
> First of, I agree that we should focus on Object Model and start
> deprecating Input Modules.
Don't know if we really should deprecate them. It would be enough to
move them to a optional block, and make them usable through some
adapter. In this way you don't need to feel the pressure to reimplement
every single module ever invented. And you also will make people with
tons of legacy sitemaps less nervous.
> Functionality covered by
> them should be move to the Object Model or new expression languages.
> There are two main types of IM:
> 1. exposing graph of objects like request-param, session-attr etc. Their
> responsibility should be replaced by extended
> object model including object graphs provided by input modules.
Yes.
Whatever the model is make it easily extensible; I think you want some
kind of class discovery mechanism here as well as on the expression
language side?
> 2. exposing some kind of expression language. The most prominent example
> is JXPathMetaModule
The "program with modules" concept didn't work out that well. It is a
much better idea to write flowscript or some other controller for the
more complicated uses. Focus on the simple and common cases.
> or newly introduced
> BlockPathModule (broadly known as "servlet:" in sitemap references).
> This modules can be viewed as expression languages
> and their equivalents should be plugged into our unified expression
> handling mechanisms.
I implemented the BlockPathModule to be able to use the
LinkRewriterTransformer, not because it is particularly elegant to
implement it in this way. I would give this part lower priority.
> During GSoC work period I would inspect all the existing modules and
> make suggestion on what to do with each one. This
> process should lead to correspondence of functionality covered by IMs
> and expression handling mechanisms. After reaching that point we could
> deprecate all IMs and interfaces related to them.
See above.
> I do not think that we have think of corresponding mechanism for output
> modules as they already are used seldom if ever.
I don't think they are used within the core, so they could be moved to
an own block that in turn could be regulated to some dark corner of our
repository.
There's a set of use cases that use coupled output and input modules
you should be aware of; basically the pattern is to have a side
pipeline from flow using cocoon.processPipelineTo. This side pipeline
then runs and leaves some results hanging around via an output module
and the main pipeline then picks the results up via a corresponding
input module (eg. RequestAttributeOutputModule and
input.RequestAttributeModule). Our use case is forms validation via
Schemeatron where we create the result of the validation in the side
pipeline. Other people apparently use a similar pattern to do SOAP
processing.
I can send you are flow script and pipelines for this if you want, or
it may all be outside of the scope of the changes you are making and
not matter?
Whatever is done, I think we need a SOAP example that works with the
recommended implementation?
<snip/>
--
Peter Hunsberger
