cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leszek Gawron <>
Subject Re: [vote] Switching to refactored JXTG
Date Sat, 16 Apr 2005 14:33:53 GMT
Daniel Fagerstrom wrote:
> Leszek Gawron wrote:
>> Daniel Fagerstrom wrote:
> <snip/>
>>> 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.
If jx:attribute is not used it should be transparent to the user. I do 
not know if it's going to introduce performance issues.
> 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. 
Fine for me. I'll start with jx:attribute and jx:static-import (so it 
does not conflict with former jx:import).

> 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.
It is not that hard to turn some features off but I do not see a reason 
for that right now.

Leszek Gawron                            
IT Manager                                         MobileBox sp. z o.o.
+48 (61) 855 06 67                    
mobile: +48 (501) 720 812                       fax: +48 (61) 853 29 65

View raw message