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/
