cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: GSoC
Date Sat, 17 Mar 2007 17:56:30 GMT
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 

>>  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.


View raw message