cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject [RFC] JXTG Refactoring (was: JXTG: invoke macro by name from expression)
Date Thu, 09 Dec 2004 10:51:09 GMT
Leszek and I have started refactoring JXTG, by breaking it up in its 
subclasses. Later we will work on creating more detailed interfaces 
between the different parts and all the other stuff that has been 
discussed on the list.

Now the question is: where should this work take place?

For the refactoring aspect its better to work on JXTG in core (BTW what 
is the correct terminology, before we refered to code not being in a 
block as core but now ECM++ is placed in a directory named core).

But considering that we are going to add stuff, and make it a framework 
for further template experiments, it makes more sense to place it in a 
block. Also our long time plan is to remove as much as possible from 
core, AFAIU.

So what I propose is that we do the refactoring in the template block. 
And that we call the refactored JXTG something else to avoid collisions 
with the original one, e.g. JXTemplateGenerator2 or 
o.a.c.template.generator.JXTemplateGenerator.

While doing this I suggest that we freeze development of the original 
JXTG, except for bug fixes. And after a while when the refactored 
version start to become stable, concerning functionality and contracts, 
we can discuss replacing the original JXTG with the refactored and 
improved one.

Is this a good plan or do you have other suggestions?

/Daniel


Some comments to Leszek's mail below.

Leszek Gawron wrote:

> Antonio Gallardo wrote:
>
>> On Jue, 9 de Diciembre de 2004, 3:01, Leszek Gawron dijo:
>>
>>>> If you already have something I should not commit - maybe I would send
>>>> you the source via email so you could use it if you wanted?
>>>
>>> http://www.apache.org/~lgawron/jxtg-20041209.zip
>>>
>>> Wasn't that hard with eclipse. Still took 4 hours so I'd appreciate if
>>> you looked at it :)
>>
>> I think you can commit the changes, if it is working. This way all of us
>> can review it.
>>
>> WDYT?
>
> The problem is that it will make all Daniel's changes uncommitable as 
> my changes are massive. Daniel - how many changes have you done already? 

Quite a lot of them, but mainly in other areas then the ones you have 
worked in. And I'm quite busy with other things the next few days so I 
think it is better that you commit your stuff than that I block the process.

I would prefer to divede all the classes in some different directories 
like environment for the code that connects to the "cocoon object", 
expression for epression related functionality, tag for executable tags, 
script for parsing, execution, basic xml event classes and interface for 
executable tags. But there is no hurry with that we can do such things 
later, you can commit it as is.

I set up some basic testing stuff that I can commit as soon as you have 
commited your stuff. I think creating a testing set for JXTG is an 
important part of our futire work.

I can see that I should start to use modern tools like Eclipse, I'm 
still using Emacs for everything and it is not ideal for large 
refactorings. OTH I don't create my own code with the same coding style 
as in JXTG, so most of the time I don't have such a clear need for 
automated refactoring help.

/Daniel



Mime
View raw message