You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Joerg Heinicke <jo...@gmx.de> on 2005/09/05 21:04:29 UTC
Status of JXTemplate refactoring
Hello,
I was asked for a possible refactoring of the JXTemplateGenerator.
Somebody wants to provide only a very limited set of functionality to
his template writers: only JXPath (no JEXL), only one object model.
He started with patching the version of JXTemplateGenerator coming with
2.1.7. Simply extending it does not work because of to much private
stuff. But with the refactoring happened to the official
JXTemplateGenerator this also seems not to make much sense.
Now the questions: The refactoring happened only in the trunk, didn't
it? How far is it pluggable, how far are the above mentioned
requirements supported? Is there any obvious problem using the template
block in Cocoon 2.1?
Thanks for your answers.
Jörg
Re: Status of JXTemplate refactoring
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Leszek Gawron wrote:
> Daniel Fagerstrom wrote:
>
>> This could be DefaultStringCompiler or CTemplateStringCompiler.
>>
>>> Unfortunately both versions cannot exist at the same time. To make
>>> that happen I would have to extend DefaultScriptManager (to lookup
>>> different JXTExpressionCompiler) and JXTemplateGenerator (to lookup
>>> different ScriptManager). I wonder if there's a simpler solution for
>>> that.
>>
>>
>>
>> Hm, it is split into components in a somewhat strange way IMO.
>
> The naming and componentization is not a problem. It was just the
> shortest path to make it running. It is surely not the final state.
I know, had it been easy to refactor, I would have done that instead of
just having opinions ;)
/Daniel
Re: Status of JXTemplate refactoring
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Daniel Fagerstrom wrote:
> This could be DefaultStringCompiler or CTemplateStringCompiler.
>
>> Unfortunately both versions cannot exist at the same time. To make
>> that happen I would have to extend DefaultScriptManager (to lookup
>> different JXTExpressionCompiler) and JXTemplateGenerator (to lookup
>> different ScriptManager). I wonder if there's a simpler solution for
>> that.
>
>
> Hm, it is split into components in a somewhat strange way IMO.
The naming and componentization is not a problem. It was just the
shortest path to make it running. It is surely not the final state.
--
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
Re: Status of JXTemplate refactoring
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Daniel Fagerstrom wrote:
> Second, it is somewhat over componentisized for my taste: Does the
> default instruction factory really be a component? Wouldn't be enough to
> give it an URL to the script configuration in its constructor.
Thing is the instruction factory instantiation can be a little bit
heavy. The Instructions' constructors are looked up using reflection and
cached. Right now this is done once per cocoon instance (thread safe).
The way you propose it every jxtg instance would have to repeat those
steps which wouldn't be a good idea (think how much processing would be
needed to instantiate another jxtg instance in case the pool was empty).
> Same
> thing with the DefaultScriptManager, if you give it a name space, and a
> parser to its constructor, there is not that much need to make it a
> component. The parser could in turn be given an instruction factory and
> an JXTExpressionCompiler as arguments to its constructor.
Hmm:
public void service(ServiceManager manager) throws ServiceException {
this.manager = manager;
this.store = (Store) this.manager.lookup(Store.TRANSIENT_STORE);
this.instructionFactory = (InstructionFactory)
this.manager.lookup(InstructionFactory.ROLE);
this.jxtExpressionCompiler = (JXTExpressionCompiler)
this.manager.lookup(JXTExpressionCompiler.ROLE);
}
public void dispose() {
this.manager.release(this.store);
this.manager.release(this.instructionFactory);
this.manager.release(this.jxtExpressionCompiler);
}
We gain little, we lower the readability of JXTGenerator itself exposing
what the implementation ScriptManager is made of. After all: if it's
composed of 3 external beans it's a good candidate for a component (I
might not think straight after using Spring too much lately :))
> In the end I think it will be simplest if the generator looks up the
> plugable components and the configuration files, i.e. the
> JXTExpressionCompiler and the instruction configuration file and maybe
> some more stuff and just pass these components to the other classes in
> the template framework.
The last one: StringTemplateCompiler. If we are to unify expression
handling in whole cocoon it should be a component anyway.
> The most natural thing would be to have a generic template generator
> that you just configure with what instuctions and what expression
> compiler you want. But people didn't want that level of flexibility so
> therefore such things need to be hard coded in the generator class.
>
> In general, the main use for components is if one really know that one
> will need to be able to choose between several different implementations
> of the same interface at deploy time. And if one want to be able to use
> several implementations of the same interface at once in a plugable way,
> selectors is the way to go. Otherwise components are overkill.
Components are also a good thing if:
1. They are thread safe and creating them is somewhat costly
2. They reference a lot of other already componentized logic.
>
>> I assume we want to keep backward functionality.
>
>
> Yes!
>
>> Is it OK if I just create CTemplateGenerator extending current
>> JXTemplateGenerator?
>
>
> Better, create a common AbstractTemplateGenerator and let both
> JXTemplateGenerator and CTemplateGenerator extend it.
I hope I'll finish the refactoring this weekend.
--
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
Re: Status of JXTemplate refactoring
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Leszek Gawron wrote:
...
> OK. So we have pluggable expression parser.
Cool! Great that you work on this.
Would still rather call it StringTemplateParser or StringParser,
following the arguments from my previous post:
"asdf {2+3} sdfhg"
is a string template,
"2+3"
is an expression.
> I have tested it a bit but new test cases are a must.
>
> If you want to try it out replace one line in:
> src\blocks\template\trunk\WEB-INF\xconf\cocoon-template.xconf
>
> from:
> <component
> role="org.apache.cocoon.template.expression.JXTExpressionCompiler"
> class="org.apache.cocoon.template.expression.DefaultJXTExpressionCompiler"/>
>
Would prefer JXTGStringParser, default isn't future safe, as we want to
move to CTemplate.
> to
> <component
> role="org.apache.cocoon.template.expression.JXTExpressionCompiler"
> class="org.apache.cocoon.template.expression.NewStyleJXTExpressionCompiler"/>
>
This could be DefaultStringCompiler or CTemplateStringCompiler.
> Unfortunately both versions cannot exist at the same time. To make
> that happen I would have to extend DefaultScriptManager (to lookup
> different JXTExpressionCompiler) and JXTemplateGenerator (to lookup
> different ScriptManager). I wonder if there's a simpler solution for
> that.
Hm, it is split into components in a somewhat strange way IMO. First,
for things like the JXTExpressionCompiler where one have several
implementations of the same interface, it is natural to use selectors
(Avalon ones) in the component handling, take a look at the
o.a.c.compnents.expression.** and its configuration file for examples.
Second, it is somewhat over componentisized for my taste: Does the
default instruction factory really be a component? Wouldn't be enough to
give it an URL to the script configuration in its constructor. Same
thing with the DefaultScriptManager, if you give it a name space, and a
parser to its constructor, there is not that much need to make it a
component. The parser could in turn be given an instruction factory and
an JXTExpressionCompiler as arguments to its constructor.
In the end I think it will be simplest if the generator looks up the
plugable components and the configuration files, i.e. the
JXTExpressionCompiler and the instruction configuration file and maybe
some more stuff and just pass these components to the other classes in
the template framework.
The most natural thing would be to have a generic template generator
that you just configure with what instuctions and what expression
compiler you want. But people didn't want that level of flexibility so
therefore such things need to be hard coded in the generator class.
In general, the main use for components is if one really know that one
will need to be able to choose between several different implementations
of the same interface at deploy time. And if one want to be able to use
several implementations of the same interface at once in a plugable way,
selectors is the way to go. Otherwise components are overkill.
> I assume we want to keep backward functionality.
Yes!
> Is it OK if I just create CTemplateGenerator extending current
> JXTemplateGenerator?
Better, create a common AbstractTemplateGenerator and let both
JXTemplateGenerator and CTemplateGenerator extend it.
/Daniel
Re: Real blocks - current state and next steps
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thursday 08 September 2005 06:47, Daniel Fagerstrom wrote:
> Maybe we could work within Felix to make
> it possible to use the OBR functionality on M2 repositories?
Not sure if the M2 contains enough info, but otherwise I think it is a good
idea.
Currently, I have a live "publish" system, where you scp a bundle to a
directory and a cron job extracts the manifest data and convert to xml
snippet. A cgi script collates the snippets on requests to the expected
format.
Although this works, it is one more piece of software to maintain, and it
doesn't work for client-side-only since it is an aggregated XML file.
Don't expect a Felix Bundle Repository any time soon though... :o)
Cheers
Niclas
Re: Status of JXTemplate refactoring
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Joerg Heinicke wrote:
> On 07.09.2005 00:29, Leszek Gawron wrote:
>
>> OK. So we have pluggable expression parser.
>
>
> I just wanted to have answers, not new code :) But thanks very much for it.
> Are other things coming as fast as this time when I just ask for them?
> What about real blocks? ;)
>
> Jörg
Ask Daniel, real blocks are a bit too difficult for me (moreover I'm
loosing all Hackathon parties which makes it even harder).
--
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
Re: Real blocks - current state and next steps
Posted by Reinhard Poetz <re...@apache.org>.
Daniel Fagerstrom wrote:
> Reinhard Poetz wrote:
>
>> Daniel Fagerstrom wrote:
>>
>>> Deployement
>>> -----------
>>>
>>> During development it is easiest to deploy block by using an
>>> (possibly graphical) OSGi console. Is this ok for production systems,
>>> should we have some web gui?
>>
>>
>>
>> A graphical installer is fine for development but IMHO not for
>> production. I need a reproducible state of a system.
>>
>> Suppose you have a cluster of 5 app servers running Cocoon. I don't
>> want to connect to every server and install/uninstall blocks there.
>> This is way to error-prone.
>
>
> Agree. This can still be done using the OSGi configuration service as it
> just is a API, we could have an implementation that take an XML or a set
> of XML files that describes the deployment.
>
>> What I think is some kind of block-installation descriptor[1]. I think
>> M2 will help us here but I haven't had a closer look how this could be
>> done.
>
>
> Yes, something like that. I'm not up to speed yet with M2, so I don't
> know how we could use M2 here.
´
I hope I find some time before Amsterdam to learn more about M2 and also work on
the big picture of block deployment again.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Real blocks - current state and next steps
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Reinhard Poetz wrote:
> Daniel Fagerstrom wrote:
>
>> Deployement
>> -----------
>>
>> During development it is easiest to deploy block by using an
>> (possibly graphical) OSGi console. Is this ok for production systems,
>> should we have some web gui?
>
>
> A graphical installer is fine for development but IMHO not for
> production. I need a reproducible state of a system.
>
> Suppose you have a cluster of 5 app servers running Cocoon. I don't
> want to connect to every server and install/uninstall blocks there.
> This is way to error-prone.
Agree. This can still be done using the OSGi configuration service as it
just is a API, we could have an implementation that take an XML or a set
of XML files that describes the deployment.
> What I think is some kind of block-installation descriptor[1]. I think
> M2 will help us here but I haven't had a closer look how this could be
> done.
Yes, something like that. I'm not up to speed yet with M2, so I don't
know how we could use M2 here.
/Daniel
Re: Real blocks - current state and next steps
Posted by Reinhard Poetz <re...@apache.org>.
Daniel Fagerstrom wrote:
> Deployement
> -----------
>
> During development it is easiest to deploy block by using an (possibly
> graphical) OSGi console. Is this ok for production systems, should we
> have some web gui?
A graphical installer is fine for development but IMHO not for production. I
need a reproducible state of a system.
Suppose you have a cluster of 5 app servers running Cocoon. I don't want to
connect to every server and install/uninstall blocks there. This is way to
error-prone.
What I think is some kind of block-installation descriptor[1]. I think M2 will
help us here but I haven't had a closer look how this could be done.
[1]
http://svn.apache.org/repos/asf/cocoon/whiteboard/block-deployer/test/sample-descriptors/deploy_001.xml
just to give an idea what I mean, don't want to say that this *is* the solution.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Real blocks - current state and next steps
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Joerg Heinicke wrote:
...
> I just wanted to have answers, not new code :) But thanks very much
> for it.
> Are other things coming as fast as this time when I just ask for them?
> What about real blocks? ;)
Although there is a lot of work before we have converted everything to
real blocks and put all the infrastructure in place, we are fairly close
to get working "real blocks".
We allready have some of the main parts: the packaging and classloader
isolation is done with OSGi and we have a working Cocoon (with some
restrictions) in terms of OSGi bundles (see
http://wiki.apache.org/cocoon/osgi for references). I implemented the
sitemap part, http://marc.theaimsgroup.com/?t=111791022500004&r=1&w=2,
of it before knowing anything about OSGi. And Sylvain have implemented
component handling for blocks
http://marc.theaimsgroup.com/?t=112231957500003&r=1&w=2, but it is not
integrated yet. The main remaining work is to integrate these parts.
I just give an overview, we can discuss all the details while devloping
them.
Architecture
============
I only care for the servlet case now to not complicate things to much.
We can refactor to take care of other environments when we have
something that works.
The Blocks servlet
------------------
The main block is the blocks servlet bundle. It create the Cocoon Core
object (o.a.c.core.Core) and make it available to all other blocks as a
(OSGi) service (I committed o.a.c.core.osgi.OSGiBootstrapEnvironment
yesterday that can beused for creating a Core adapted to the OSGi
context). It also makes all components in the Cocoon core (src/java/**)
available as services. The blocks servlet does not necesarily contain
the core it might be an own library bundle that the blocks servlet just
depend on.
The blocks servlet bundle creats a servlet and register it in a (OSGi)
HttpService. The servlet dooes nothing in it self it just works as a
switch board for the blocks. When a block with sitemap functionality is
deployed in the OSGi container, it will register a Block service and the
service migth also be deployed at a certain mount point in the URI
space. The blocks servlet bundle will react (through OSGi event
handling) on the presence of a new sitemap block and redirect all http
calls to the blocks mount point to its Block service.
The blocks servlet bundle will contain part of the code from
o.a.c.components.blocks.BlocksManager. The main difference from the
BlocksManager is that the blocks servlet bundle will not be responsible
for deploy time configuration and creation of the individual blocks.
A Block
-------
An individual block will use some common BlockActivator as activator.
The BlockActivator will base its work on the block.xml file of the
block. If block.xml contains a reference to an .xconf file it will
create a parent service manager that contains all the components of the
.xconf file and exports the components as services so that other blocks
can use them. Furthermore it will translate all requests for components
that not is part of the local container to (OSGi) service requests so
that the component can be delivered from other blocks. Sylvain have
allready written most of the code for the component management and it
can befound in o.a.c.core.osgi.
The block.xml will be used for configure an
o.a.c.components.blocks.BlockManager. If there is a sitemap reference i
block.xml a Block service will be created and exposed. And if there is a
local component manager as described above, it will be used as parent
component manager for the sitemap.
One question is how to give deploy time configuration (the wiring.xml)
about mount point, block attributes, and connections to other blocks, to
a block. Maybe the block specific properties that Carsten is working on
could be used. At a later stage the configuration manager service of
OSGi could be useful.
After having implemented what is described above we have a first version
of real blocks. There are however some surrounding components and infra
stucture we need to make it really usefull.
Various
=======
Library bundles
---------------
Today all the jars that the core depend on is uncluded in the Cocoon
core bundle. It would be much more practical to package them as separate
bundles. There is a tool, Mangen
http://oscar-osgi.sourceforge.net/mangen/, that take a set of jars,
amalyze all interdependencies and generate the appropriate manifest
files with exports and imports. It is also configurable in various ways.
Using this tool would simplify the manifest creation a lot.
It wouuld be practical if the communities for the various jars supported
OSGi manifest files. We could probably do that within the Excalibur
project and maybe also in Jakarta commons.
Build system
------------
Currently we have some rather ad hoc tasks for building the bundles.
There is an ongoing OSGi Maven2 plugin project within Apache Felix (the
Apache OSGi incubator project). It would be good if we could take part
in that project so that the plugin works for us.
Block repository
----------------
The repository situation is not that clear to me. There is an Oscar
Bundle Repository (OBR)
http://oscar-osgi.sourceforge.net/repo/bundlerepository/ that has good
support for OSGi bundles. It handles dependencies among other things.
Eclipse also have bundle aware repository. OTH our build system is
connected to a M2 repository. Maybe we could work within Felix to make
it possible to use the OBR functionality on M2 repositories?
Deployement
-----------
During development it is easiest to deploy block by using an (possibly
graphical) OSGi console. Is this ok for production systems, should we
have some web gui?
Framework
---------
We are currently using the Knopflerfish OSGi framework, wich implements
release 3 of OSGi. It works well, but the licence isn't ASF compatible
(to week) and some functionality that we need is lacking (ability to
list directory content in bundles, and more advanced version handling).
OSGi R4 has a compatible licence and the features that we miss from R3.
Either we can use the OSGi R4 framework from Eclipse, it is stable and
rather complete, but not as easy to use. Or we can use the OSGi R4
framework from Felix that is under development, but it is Apache and
easier to influence.
/Daniel
Re: Status of JXTemplate refactoring
Posted by Joerg Heinicke <jo...@gmx.de>.
On 07.09.2005 00:29, Leszek Gawron wrote:
> OK. So we have pluggable expression parser.
I just wanted to have answers, not new code :) But thanks very much for it.
Are other things coming as fast as this time when I just ask for them?
What about real blocks? ;)
Jörg
Re: Status of JXTemplate refactoring
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Daniel Fagerstrom wrote:
> Leszek Gawron wrote:
>
>> Daniel Fagerstrom wrote:
>>
>>> No, I use faulty terminology, I didn't mean expression parser but
>>> rather string template parser (or whatever we should call it).
OK. So we have pluggable expression parser. I have tested it a bit but
new test cases are a must.
If you want to try it out replace one line in:
src\blocks\template\trunk\WEB-INF\xconf\cocoon-template.xconf
from:
<component
role="org.apache.cocoon.template.expression.JXTExpressionCompiler"
class="org.apache.cocoon.template.expression.DefaultJXTExpressionCompiler"/>
to
<component
role="org.apache.cocoon.template.expression.JXTExpressionCompiler"
class="org.apache.cocoon.template.expression.NewStyleJXTExpressionCompiler"/>
Unfortunately both versions cannot exist at the same time. To make that
happen I would have to extend DefaultScriptManager (to lookup different
JXTExpressionCompiler) and JXTemplateGenerator (to lookup different
ScriptManager). I wonder if there's a simpler solution for that.
I assume we want to keep backward functionality. Is it OK if I just
create CTemplateGenerator extending current JXTemplateGenerator?
--
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
Re: Status of JXTemplate refactoring
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Leszek Gawron wrote:
> Daniel Fagerstrom wrote:
>
>> No, I use faulty terminology, I didn't mean expression parser but
>> rather string template parser (or whatever we should call it).
>>
>> For those who don't remember the discussions (which seem to include me
>
> and me :)
>
> <snip/>
>
> Thanks for such a good summary. One more thing though. Did we happen
> to establish some pluggable expressions supporting convertors syntax?
The original thread is here
http://marc.theaimsgroup.com/?t=109941988300003&r=1&w=2 and it is quite
long so I have not had time to read all of it, but I don't think we
established a syntax.
> I mean something like:
> {wikify:jexl:myString?locale=a&wikiRenderingEngineParam=2}
>
> (gosh that's ugly :))
Don't know if we should go that far. The main application for plugable
coverters (within templates) is to convert a (simple) Java data type to
a string representation in the current locale, so a typical example does
not need any syntax at all:
{jexl:myFloat}
in some cases one want to be able to chose among several different kinds
of conversions, one might want to have a short and a long format for
numbers e.g., the idea was to solve that with different classes of
convertors Jonas Ekstedt proposed:
{jexl:myFloat#short}
i.e. fragment syntax for URIs
(http://www.gbiv.com/protocols/uri/rfc/rfc3986.html#fragment), IMO that
makes sense as:
"The fragment identifier component of a URI allows indirect
identification of a secondary resource by reference to a primary
resource and additional identifying information. The identified
secondary resource may be some portion or subset of the primary
resource, some view on representations of the primary resource, or some
other resource defined or described by those representations."
A specific class of convertors gives a "view on representations of the
primary resource".
I don't think we should start to have parameters to the converters and
so on, if you need more "programming" in your templates you can write
java code and call it from Jexl or JXPath. Convertors is intended to
decrease the need of programming in templates and have a more
declarative solution there typical conversion patterns allready are
predefined.
I'm also somewhat negative to have convertors that creates XML as some
people have suggested, I can understand that it can be useful in some
cases, but it makes the concern area for convertors more blurred and
complicates the architecture.
Lets start simple with the convertors.
/Daniel
Re: Status of JXTemplate refactoring
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Daniel Fagerstrom wrote:
> No, I use faulty terminology, I didn't mean expression parser but rather
> string template parser (or whatever we should call it).
>
> For those who don't remember the discussions (which seem to include me
and me :)
<snip/>
Thanks for such a good summary. One more thing though. Did we happen to
establish some pluggable expressions supporting convertors syntax?
I mean something like:
{wikify:jexl:myString?locale=a&wikiRenderingEngineParam=2}
(gosh that's ugly :))
--
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
Re: Status of JXTemplate refactoring
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Leszek Gawron wrote:
> Leszek Gawron wrote:
>
>>> To make the expressions completely plugable within the template
>>> framework, we need a expression parser interface and we need to make
>>> the expression parser implementation plugable in the Parser.
>>
>>
>> Plugging one expression parser into the Parser is not enough. Most of
>> users will still want to use both JEXL and JXPath in one template as
>> the functionality of both maps well on different areas of object model.
>
> Sorry, I'm only making noise here :). I found a proper thread.
No, I use faulty terminology, I didn't mean expression parser but rather
string template parser (or whatever we should call it).
For those who don't remember the discussions (which seem to include me
;) ), what we are talking about is the "string templates" in an template
language, i.e. the character data in elements and the value of
attributes. In JXTG string templates looks like:
"foo ${cocoon.continuations.id} bar #{2+3}"
The string template parser split the string into strings "foo " and "
bar " and expressions "cocoon.continuation.id" and "2+3". The
expressions are in turn sent to the expression parsers of Jexl and
JXPath respectively. And the result is a sequence (or iterator over)
strings and compiled expressions.
The idea now is to make this plugable so that one can replace the JXTG
default string parser mechanism with plugable ones. What we more
specifically have in mind is to have a new default string template
parser that use "{}" to embed expressions (following attribute value
templates in XSLT, with '{{' and '}}' for escaping '{' and '}') and that
let the expression parser (using the ExpressionFactory) of the plugable
expressions in template handle the expressions. This will lead to
expressions like:
"foo {jexl:cocoon.continuations.id} bar {jxpath:2+3}"
where "jexl" and "jxpath" are defined in a configuration file. The
plugable expressions also allow for a default exprssion language, so
that you just need to write e.g. {cocoon.continuations.id} if you chosed
Jexl as default template language.
Adding a more technical note: It is mainly the classes and interfaces in
o.a.c.template.expression that need to be generalized. The JXTExprssion
class both contain a parsing mechanism and embeds the compiled
expression with some type conversion stuff. When we add the conversion
stuff we can hopefully have better separated concerns and remove all the
use of the JXTExpression in the script instruction classes and use
converters and expressions instead.
At a later point we should move plugable expressions, string template
parsing and coversion to core and use it everywhere in Cocoon, to make
Cocoon more coherent while we at the same time can keep it back
compatible by keeping old behaviour as plugins.
/Daniel
Re: Status of JXTemplate refactoring
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Leszek Gawron wrote:
>> To make the expressions completely plugable within the template
>> framework, we need a expression parser interface and we need to make
>> the expression parser implementation plugable in the Parser.
>
> Plugging one expression parser into the Parser is not enough. Most of
> users will still want to use both JEXL and JXPath in one template as the
> functionality of both maps well on different areas of object model.
Sorry, I'm only making noise here :). I found a proper thread.
--
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
Re: Status of JXTemplate refactoring
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Daniel Fagerstrom wrote:
> Joerg Heinicke wrote:
>
>> Hello,
>>
>> I was asked for a possible refactoring of the JXTemplateGenerator.
>> Somebody wants to provide only a very limited set of functionality to
>> his template writers: only JXPath (no JEXL), only one object model.
>>
>> He started with patching the version of JXTemplateGenerator coming
>> with 2.1.7. Simply extending it does not work because of to much
>> private stuff. But with the refactoring happened to the official
>> JXTemplateGenerator this also seems not to make much sense.
>
>
> Redoing the refactoring work that Leszek and I already have done seem
> like wasting time.
>
>> Now the questions: The refactoring happened only in the trunk, didn't it?
>
>
> It only happened in trunk, keeping a synchronized copy in the 2.1.x
> branch while refactoring didn't seem that fun. It would probably easy to
> port it to 2.1.x if anyone feel like doing it.
The only problem is the object model that changed a little bit (this
makes one of the test cases fail in trunk).
> To make the expressions completely plugable within the template
> framework, we need a expression parser interface and we need to make the
> expression parser implementation plugable in the Parser.
Plugging one expression parser into the Parser is not enough. Most of
users will still want to use both JEXL and JXPath in one template as the
functionality of both maps well on different areas of object model.
I'll read previous discussions again and try to implement something both
pluggable and convertor ready.
>
>> Is there any obvious problem using the template block in Cocoon 2.1?
>
>
> No.
Nope.
>
> --- o0o ---
>
> Further links about the template block design and discussions can be
> found at http://wiki.apache.org/cocoon/Templates. There was also an
> agreement that JXTG should be renamed to CTemplate and get a new name
> space. We had some discussion about what CTemplate should contain:
> http://marc.theaimsgroup.com/?t=110942300500004&r=1&w=2. Among other
> things it was supposed to have more plugable expressions.
>
> /Daniel
--
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
Re: Status of JXTemplate refactoring
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Joerg Heinicke wrote:
> Hello,
>
> I was asked for a possible refactoring of the JXTemplateGenerator.
> Somebody wants to provide only a very limited set of functionality to
> his template writers: only JXPath (no JEXL), only one object model.
>
> He started with patching the version of JXTemplateGenerator coming with
> 2.1.7. Simply extending it does not work because of to much private
> stuff. But with the refactoring happened to the official
> JXTemplateGenerator this also seems not to make much sense.
Redoing the refactoring work that Leszek and I already have done seem
like wasting time.
> Now the questions: The refactoring happened only in the trunk, didn't
> it?
It only happened in trunk, keeping a synchronized copy in the 2.1.x
branch while refactoring didn't seem that fun. It would probably easy to
port it to 2.1.x if anyone feel like doing it.
> How far is it pluggable,
Concerning instructions sets it is completely pluggable, take a look at
the configuration and o.a.c.template.script.InstructionFactory and
DefaultInstructionFactory.
> how far are the above mentioned requirements supported?
Much of it is supported, but there is some refactoring work left to do.
Expressions are pluggable, see o.a.c.components.expression.**. There is
only one common object model for all Expression implementations:
ExpressionContext and the standard object model is created by
o.a.c.template.environment.FlowObjectModelHelper and pluged in in the
JXTemplateGenerator class.
But the actual expression parsing used in the template framework is not
plugable yet. Take a look at the class o.a.c.template.script.Parser, it
calls o.a.c.template.expression.JXTExpression for expression parsing.
JTExpression recognice the ${} and #{} syntax and create the right kind
of expression.
To make the expressions completely plugable within the template
framework, we need a expression parser interface and we need to make the
expression parser implementation plugable in the Parser.
> Is there any obvious problem using the template
> block in Cocoon 2.1?
No.
--- o0o ---
Further links about the template block design and discussions can be
found at http://wiki.apache.org/cocoon/Templates. There was also an
agreement that JXTG should be renamed to CTemplate and get a new name
space. We had some discussion about what CTemplate should contain:
http://marc.theaimsgroup.com/?t=110942300500004&r=1&w=2. Among other
things it was supposed to have more plugable expressions.
/Daniel