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 [EMAIL PROTECTED]
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
