Daniel Fagerstrom napisał(a):
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
Wow, lots of reading; luckily weekend has just started. Thanks! :)
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 think that refactoring would lead to cleaner contracts and lesser
amount of dependencies. Maybe I misunderstand "refactoring" word. Is
what I'm talking about mor a redesign?
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.
Thanks for bringing this. After thinking it over I agree that summer is
not good time for such a task. It would involve lots of question about
design decision made in the past and about those are going to happen etc.
It means that I think it's not good candidate for GSoC project but I do
not abandon the idea in general. If time permits I will return to this
issue.
--
Grzegorz Kossakowski
