You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Grzegorz Kossakowski <gr...@tuffmail.com> on 2007/07/23 14:28:01 UTC

What happened in cocoon-template and cocoon-expression-language

Hello,

I would like to give you a brief description of what happened in cocoon-template and cocoon-expression-language blocks/modules. All my 
changes were about introducing new ObjectModel API (COCOON-2086) and switching to it in cocoon-template (COCOON-2092). As a consequence of a 
switch I could finally get rid of ExpressionContext class (COCOON-2094) that I have not been happy with from the early beginning.

When it comes to ObjectModel API I experimented a lot. At the beginning I wanted Object Model to act exactly as MultiMap[1] from 
commons-collections. After introducing it I realized that returning *always* a Collection is very troublesome for evaluating expressions and 
decided to change semantics a little. However, after some more experiments it turned out that the approach is plainly wrong and there is no 
sense to continue in this direction. Finally I decided that Object Model is just a Map with special capabilities (more in javadocs of 
interface). I also covered expected behaviour by test cases which should make it easier for others to implement their own Object Models if 
needed.

Now I would like to discuss changes in cocoon-template. First of all, I decided that Object Model will not be abused for internal purposes 
(namespace handling) by JXTemplateGenerator as ExpressionContext class was. Thus, I introduced yet another parameter /namespaces/ that 
contains table of namespaces. Besides this change, the rest was about adapting generator's code to the new Object Model.

At the end I would like to share my loose thoughts. The most important statement in this paragraph, written with CAPITALS IS: WRITING TESTS 
IS INSANELY IMPORTANT, PERIOD.
Thanks to tests coverage in cocoon-template (not complete, though) I could spot silly and serious mistakes as early as possible and quickly 
fix flaws. It also made me more comfortable about serious changes that (possibly) could change some contracts. Guys, from my own experience 
I can tell you that writing tests *is* fun, especially inside Eclipse IDE and if you have to deal with Spring-managed components.
It's also a fun for someone else to play with your code in the future if code is has test coverage. I strongly believe that coding 
(especially in Open Source) should be a fun thus I officially join into Code Testing Supporters Camp. :-)

[1] http://jakarta.apache.org/commons/collections/api-release/org/apache/commons/collections/MultiMap.html

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