cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Hunsberger" <peter.hunsber...@gmail.com>
Subject Re: Unified expression handling and unified object model
Date Wed, 21 Mar 2007 14:47:01 GMT
On 3/20/07, Daniel Fagerstrom <danielf@nada.kth.se> 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

Mime
View raw message