cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: Unified expression handling and unified object model
Date Wed, 21 Mar 2007 00:02:55 GMT
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.

> 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.

> Now I would like to discuss expression configuration and extension. My 
> personal opinion is that this stuff should have *no configuration* at 
> all. I would like to see it as something that "just works". This doesn't 
> mean that one will not be able to introduce new expression language 
> implementation on his demand. What I want to say that this new 
> implementation should work without any configuration provided. This 
> means that classes implementing expression language interface should be 
> just discovered and then registered on runtime, we should try to avoid 
> any XML-based central registry.

+1

> Am I right that Spring is capable of class discovery implementing 
> particular interface?

Not OOTB, but Carsten implemented such a bean 
http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-configuration/cocoon-spring-configurator/src/main/java/org/apache/cocoon/spring/configurator/impl/BeanMap.java,

http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-configuration/cocoon-spring-configurator/src/main/resources/org/apache/cocoon/spring/configurator/schema/cocoon-configurator-1.0.1.xsd.

I don't know if there are any usage examples in the repos. The concept 
is discussed here 
http://marc.info/?l=xml-cocoon-dev&m=116967526831334&w=2 and here 
http://netzooid.com/blog/2007/01/27/component-discovery-with-spring/.

> I think it's worth to address some doubts. Yes, I really mean that all 
> classes available in classpath should be available for use in any place. 
> It should be expression language implementation resposibility to find 
> out if the context it's being called is valid and if not return null or 
> throw informative exception. I strive for that solution because any 
> other I can think of introduce complicated, scaring configuration which 
> one we really want to avoid.

Agree. We had an idea about having restricted environments before. But 
it didn't work out that well in practice. So I guess most of us have 
abandoned that idea.

> Actual work will consist of:
> * creation of approporiate, well-thought API
> * implementation of various expression languages, two main 
> implementations I want to focus on are: JXPath and Jexl/JS

Expression languages are implemented 
http://svn.apache.org/repos/asf/cocoon/trunk/blocks/cocoon-template/cocoon-template-impl/src/test/java/org/apache/cocoon/components/expression/,

what is lacking is using them outside the template block.

> * refactorings in various places where expressions are already handled 
> but incoherently, list includes:
>   - sitemap
>   - flowscript
>   - javaflow
>   - CForms
>   - Templates
> * documentation of whole process, migration guides, etc.
> 
> As result we should have expressions handled consistently in all over 
> the Cocoon (including samples).

Sounds great :)

I would propose that you look if the converter stuff could be within 
your project scope, possibly by decreasing the ambition in some other 
area. The converter idea is described here 
http://marc.info/?l=xml-cocoon-dev&m=109941971317696&w=2, 
http://marc.info/?l=xml-cocoon-dev&m=109960841308357&w=2, there is even 
a partial implementation: 
http://issues.apache.org/bugzilla/show_bug.cgi?id=32223.

The conveter would simplify both template and cforms use considerably. 
It would also allow us to cleanup the implementation of cforms.

> Last aspect I would like to discuss is development methodology. When 
> GSoC start I think we should discuss and agree on main requirements. At 
> implementation phase I would like to take a one week round. That 
> complete work will be broken into task suitable for one week period. 
> This will enable us to evaluate my work at the end of every week and see 
> if I progress in right direction.
> During completion of particular task I would like to write tests first 
> for the functionality I want to implement and then start implementation.
> Choosing that methodology guarantees that code produced during GSoC 
> period will be of high quality and be easy to maintain in the future.
> 
> What do you think? Is it fine for you?

Sure.

> PS. It's not detailed plan as I have to dive into the code a little bit 
> more to see what will demand more or less effort and focus. I'll come 
> with detailed plan later.


/Daniel

Mime
View raw message