Grzegorz Kossakowski skrev:
Daniel Fagerstrom napisał(a):
...
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?
I don't think that you have misunderstood the "refactoring" word. I
wanted to point out that I think that refactoring where the only goal is
to clean up the design is a complicated business. The concept of a
"cleaner design" is rather vague.
I mean: How do you evaluate that the new design is cleaner? When is it
clean enough? Why should it be cleaner? How do you keep your motivation
when the works get tough?
In my experience it is much better to a refactoring with the explicit
goal of making it possible (or easier) to implement this or that
particular new functionality.
By doing that it will be much easier to find an answer of the above
questions. You know that the refactoring leads to a "better" design if
it allows both for the current tasks and the new one.
/Daniel
