Daniel Fagerstrom napisał(a): > 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.
Agreed. What I wanted more to say was to "deprecate" them in our minds. We should emphasize in docs that there is better way to solve various problems than using IMs, show the examples and use new techniques all over the Cocoon's samples (at least those newly created). I wouldn't like to see the same story as it's with XSP. It was deprecated long time ago and still, people just starting to learn Cocoon try to use XSP... >> 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. +1 > >> 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. So how it would be done after implementing unified expressions? I thought that BlockPathModule would become just "servlet" expression and LinkRewriterTransformer would be given list of expressions instead of list of input modules. What's your idea? >> 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. +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/. Thanks for the pointers. It's good to hear that the stuff is already here. >> 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. I wasn't aware that they are already implemented and used in Cocoon. However, considering goals I outlined it's sure that some work with expression's itself is needed. I think that we should get rid of Avalon's dependencies and use Spring instead. As next step, class discovery should be implemented as we agreed earlier. Am I right I miss something again? >> * 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. I agree that work on converters would be more valuable than artificial fight with IMs. However I fail to see the scope of converters. Your original idea was to create type converters that able to do bidirectional conversion between particular type and string and you thought that it would be reasonable to have only one per type. Someone suggested that it would be great to have type<->XML converters too. Someone else asked for being able to have many converters for single type and be able to have a choice which to choose in particular situation. I think that I could take converters into account but would like to hear your opinion what are the limits of flexibility they should give. -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
