cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leszek Gawron <lgaw...@mobilebox.pl>
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: http://marc.theaimsgroup.com/?t=110963091600004&r=1&w=2, 
>>> 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:
>>>
>>> http://svn.apache.org/viewcvs.cgi/cocoon/blocks/unsupported/template/trunk/java/org/apache/cocoon/components/accessor/

>>>
>>> http://svn.apache.org/viewcvs.cgi/cocoon/blocks/unsupported/template/trunk/test/org/apache/cocoon/components/accessor/

>>
>>
>>
>> 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                                      lgawron@mobilebox.pl
IT Manager                                         MobileBox sp. z o.o.
+48 (61) 855 06 67                              http://www.mobilebox.pl
mobile: +48 (501) 720 812                       fax: +48 (61) 853 29 65

Mime
View raw message