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
