Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Grzegorz Kossakowski <grek <at> tuffmail.com>
Subject: GSoC final report
Newsgroups: gmane.text.xml.cocoon.devel
Date: Monday 20th August 2007 18:33:46 UTC (over 9 years ago)
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. ***
 
CD: 3ms