Grzegorz Kossakowski skrev:
Reinhard Poetz wrote:
Grzegorz Kossakowski wrote:
...
And finally some more project ideas:
a) cleanup input modules: IIRC there was some discussion about
reducing the number of input modules in favor of one that uses an
expression
language that works on a well-defined object model.
b) cleanup expression language usage throughout Cocoon
Daniel, do you have any pointers?
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=110963086900150&w=2,
http://marc.theaimsgroup.com/?t=110595829700001&r=1&w=2,
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109941971317696&w=2,
http://svn.apache.org/repos/asf/cocoon/trunk/blocks/cocoon-template/cocoon-template-impl/src/test/java/org/apache/cocoon/components/accessor/AccessorTestCase.java
I would add even one more:
* refactoring of pipeline stuff
While working on improving HTTP-compliance of pipelines I had a
feeling (expressed in few comments) that pipeline code really needs
major redesign and refactoring. Current code is really obscure,
hard-to-follow and full of hacks. It's really a challenge to make a only
minor change in it being sure that nothing is going to break. Situation
is even worse, that there are only few tests provided for pipeline code.
My idea was to write lots of tests _before_ doing any refactorings
covering all the code in pipeline module and start reimplementing
classes with effort to not change APIs too much. However, small changes
would be needed IMHO.
Just refactoring something sounds a little bit boring. I think you
should add something also. One idea would be to make pipelines usable
outside Cocoon sitemaps. I started to work on it
http://svn.apache.org/repos/asf/cocoon/whiteboard/java-sitemap/src/main/java/org/apache/cocoon/javasitemap/JavaSitemapServlet.java.
But one still need to depend on the cocoon-core module. It would be
much neater to just need to depend on the cocoon-pipeline-impl.
I only wonder if there is a volunteer that woud like to mentor such a
project.
I could mentor it.
Also, I wonder if it's even doable in two months as this
changes would involve lots of discussion and the task in general is
really challenging.
As a refactoring consists of a sequence of behavior preserving
transformations you can stop in any moment, so it is of course doable in
two months or in any given period of time ;)
A possible problem with doing it during the summer is that the list
might be less responsive. So it requires that you are confident enough
to make some tough decisions without that much feedback.
/Daniel
