cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: [vote] Switching to refactored JXTG
Date Sat, 16 Apr 2005 13:49:19 GMT
Leszek Gawron wrote:
> Daniel Fagerstrom wrote:
>> We have discussed configurable and unified environment (object model) 
>> handling:, 
>> which would mean that you can decide what you want JXTG to depend on, 
>> e.g. if it should allow the use of Java packages in expressions or not.
>> I started on a prototype:


> I missed that code though.

It's not integrated in JXTG yet, what is missing is accessors for 
"java.*" and "Package.*" which wouldn't be that hard to add. One have to 
think a little bit about how to avoid creating a lot of new Rhino 
context. What is more complicated is how to handle sitemap parameters as 
they don't fit together with the rest of the environment handling that 
only uses the object model and the service manager.

>> but there are other things that has higher priority for me, so if no 
>> one else jumps on it it will take some while before anything happens.
> I have some doubts if we are able to make new JXTG official, create a 
> CTemplate and work on it without duplicating the code.

I have no doubts that it is possible :) Most of the template code is, or 
should be framework code that is reusable, only the instructions, 
expression parsing and maybe some other parts need to differ. And all 
such parts is or should be made pluggable.

> For example: I would like to start working on implementing a 
> jx:attribute. Apart from new tag I will have to create some kind of 
> enhanced ContentHandler that also takes attributes as events. This means 
> that official jxtg should not define jx:attribute and not use that new 
> ContentHandler.

Is the new ContentHandler goin to introduce any incompability, or give 
some extra fetaures without the attrribute tag? Otherwise it can be part 
of both languages without any problem.

As long as you only add functionallity and only in trunk I think you can 
continue to work on the JXTG language. We can wait with splitting it 
until we need to make incompatible things. Then we of course need to 
decide if the additions should be part of JXTG before we release 2.2. 
But we don't need to handle everything right now.


View raw message