cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <gkossakow...@apache.org>
Subject Unified expression handling and unified object model
Date Tue, 20 Mar 2007 18:03:44 GMT
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. 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.
2. exposing some kind of expression language. The most prominent example 
is JXPathMetaModule 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.

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.
I do not think that we have think of corresponding mechanism for output 
modules as they already are used seldom if ever.

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.
Am I right that Spring is capable of class discovery implementing 
particular interface?

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.

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

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?

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.

-- 
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/


Mime
View raw message