cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <g...@tuffmail.com>
Subject GSoC final report
Date Mon, 20 Aug 2007 18:33:46 GMT
Hello,

I would like to present final report on my GSoC final progress to you. Before going into details,
I 
would like to thank you all who helped me by giving advices, suggestions and useful criticism.
I 
would like to give special thanks to Daniel who accepted to be my mentor.

While working on Uunified Object Model and unified handling of expression langues I created
and 
resolved eighteen JIRA issues:
Key            Summary
COCOON-2125    Remove dependency on cocoon-pipeline-impl in cocoon-expression-language-impl
COCOON-2124    Change scope of Object Model to pipelineComponent
COCOON-2122    Implement pipeline component scope
COCOON-2121    Servlets mounted at "/" are handled improperly.
COCOON-2120    Move sitemap.xmap and other stuff from cocoon-webapp to it's own block
COCOON-2117    Put sitemap variables on Object Model
COCOON-2115    Implement evaluation of sitemap expressions in a class implementing 
StringTemplateParser interface
COCOON-2113    Switch pluggable String parsers from Avalon to Spring
COCOON-2112    Move pluggable string parsers from cocoon-template to cocoon-expression
COCOON-2110    Evaluate expressions defined in cocooon-expression-language-api in Sitemap
engine
COCOON-2103    Replace Initialization of Object Model by helper classes with more solid mechanisms
COCOON-2095    Make Object Model a Spring bean
COCOON-2094    Get rid of ExpressionContext usage
COCOON-2092    Switch to new Object Model implementation in cocoon-template
COCOON-2086    Invent API for Object Model and use it in template block
COCOON-2085    Implement new, universal Object Model
COCOON-2082    Get rid of Avalon dependencies in cocoon-expression-language code
COCOON-2081    Move api and implementation of expression languages to separate module

All generated 163 commits in our repository.

Since a while I believe in saying "Show me dependencies of your code and I'll tell you how
good it 
is." :-)

Le'ts take a look at dependencies of cocoon-language-expression-impl:

* org.apache.cocoon:cocoon-expression-language-impl:jar
     o org.apache.cocoon:cocoon-expression-language-api:jar
     o org.apache.cocoon:cocoon-xml-util:jar
         + xml-apis:xml-apis:jar
     o commons-lang:commons-lang:jar
     o commons-collections:commons-collections:jar
     o commons-jexl:commons-jexl:jar
     o commons-jxpath:commons-jxpath:jar
         + commons-logging:commons-logging:jar
             # log4j:log4j:jar
             # logkit:logkit:jar
             # avalon-framework:avalon-framework:jar
     o rhino:js:jar
     o org.springframework:spring-beans:jar
         + org.springframework:spring-core:jar
     o javax.servlet:servlet-api:jar
     o xmlunit:xmlunit:jar
     o junit:junit:jar

(this list includes all transitive dependencies, generated by mvn project-info-reports:dependencies)

I must admit that I'm very proud of this list, as you see there is no other Cocoon module
here. 
There is no Avalon (except weird dependency of commons-logging) dependencies here because
I got rid 
of all Avalon code while moving/creating code in EL modules. Some of you may don't like that
this 
module depends on Rhino or JXPath. It's not a big deal with current structure of EL module
and 
dependencies between classes. If you want to factor out e.g. Javascript expression langauge
it's 
really matter of creating new Maven module and moving few files, only.

Next thing is that I managed to fully switch cocoon-template to new expression languages and
remove 
complicated and error-prone code responsible for initialization of Object Model. Situation
has been 
improved dramatically because all initialization happens in beans implementing ObjectModelProvider

interface that itself is very lightweight (it contains one method only). What's more important,

various object model providers are in responsibility of parts of Cocoon that actually handle
exposed 
data. For example, $cocoon variable in Object Model gives access to environmental data like
request. 
Since Request interface and implementation is in cocoon-sitemap-* modules, Object Model provider
is 
also there.

In fact, it was Daniel's suggestion to do it that way and following this practise I could
quickly 
remove most of crappy dependencies that coupled various modules together. I guess that similar

practises would help us to cut dependencies amongst Cocoon modules in general. When we are
at 
reducing dependencies, I think I managed to remove most of code relying on Avalon from 
cocoon-template so it should be quite easy to switch it from Avalon to Spring. Any volunteers?
:-)

Next thing I managed to do is to make sitemap variable resolution pluggable. Again, following

Daniel's suggestion I created special VariableResolver that delegates parsing and resolution
of 
string templates to the classes implementing StringTemplateParser interface. Now it's matter
of one 
line of configuration file to switch sitemap to new expression language handling code and
start to 
use exactly the same Object Model and ELs as in templates. I must give a word of caution here:
I 
tested this functionality briefly with new ELs so there may be some bugs and if you are going
to try 
it out don't hesitate to ask question. I'll be very happy to help.

Last big thing I managed to do is introduction of pipeline component scope. It was really
tricky 
subject for me (and as we have seen, for others too) and I'm very happy with my current solution

that, even needs adjustments, in general is very convenient and elegant IMHO. Now, if you
want to 
put parameters on Object Model it's few lines of code in class implementing MethodInterceptor

interface (you just need to catch calls to the setup() method and put parameters on ObjectModel
there).

Now I would like to focus on things that I didn't managed to do. First of all, I didn't implement

convertor concept. At the beginning I was lost a little bit in thread discussing possible
reuse of 
code from Spring. Then I thought that it should not have a high priority because it's a concept
that 
will be easy to implement later and it's more important to focus on things that are more 
effort-demanding and involve expertise in lots of Cocoon areas. That was the main reason why
I 
decided to finish off OM initialization code and sitemap refactorings. It really took handful
amount 
of time (and stress sometimes) to feel comfortable and productive in these areas. I did want
to 
provide solid basis for other enhancements that can be built on top of it.

I also didn't touch Forms even I really wanted. There was only one reason for this: lack of
time. 
When planning things I was going to do I really wasn't aware of how how hard it would be to
get 
familiar with all Cocoon guts. In short: I planned to do too much underestimating my goals.
While 
planning I did take into account that there is a real life out there and sometime I couldn't

hack/learn all the day. There were also extremely annoying issues like my ISP behaviour that
forced 
me to put this ugly disclaimer on my e-mail's signature.

Approaching the end of this e-mail I must admit that I failed on even one more thing: communication.

I promised to give weekly reports on progress but I didn't manage to do it. It was mainly
because I 
didn't want to write about highly technical, detailed things that occurred while refactoring
old 
code. I've been also very confused for many times and didn't know if it's right time to report
on 
progress. Complexity of the task was so high for me sometimes that I was just lost and wouldn't

report anything with confidence, at all ;)

Thinking about it further, GSoC organizers constantly say that GSoC isn't just about deliverables

and thousands of lines of code. It's a chance for students to get involved into OS project,
to 
gather enough knowledge and excitement to stay with project after GSoC period ends. You can
be sure 
that I'm excited and I'm going to continue my work. However, remember that it's no longer
GSoC work 
so it's really desirable that others will join the effort. I would really like to avoid one-man
show.

When talking about continuation of my work I should say that I'll not be able to do much until
15th 
of September because I'm going to have exams at university and I'll really, really need to
focus on 
this now. Up to this date I'll limit my activity to occasional discussing and helping others
if 
there is some problem with my recent work.

Thank you for cooperation.

-- 
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
*** My Internet Service Provider breaks my internet connection                ***
*** incessantly so I'll not be able to respond to e-mails                     ***
*** regularly and my work will be somehow irregular.                          ***
*** I'm already trying to switch ISP but it will take handful amount of time. ***

Mime
View raw message