You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Daniel Fagerstrom <da...@nada.kth.se> on 2005/02/26 14:02:44 UTC
[RT] CTemplate
Now that we have decided to call JXTG CTemplate in the future
http://marc.theaimsgroup.com/?t=110908866100002&r=1&w=2, is it a good
opportunity to discuss what CTemplate should become.
IMO CTemplate should be close to JXTG but we should remove all of the
peculiarities and make it as side effect free as possible. And as simple
as possible. I also think that we should try to follow the principles
from StrinngTemplate
http://www.cs.usfca.edu/~parrt/papers/mvc.templates.pdf, but without to
much fundamentalism.
See http://wiki.apache.org/cocoon/Templates for references to earlier
discussions about templates.
Expression handling
===================
We should get rid of the confusing #{}, ${} syntax. I would prefer using
{} as in XSLT. With the new pluggable expressions
(http://marc.theaimsgroup.com/?t=110595829700001&r=1&w=2) one can use:
{jxpath:$a+$b}
or
{jexl:a+b}
when wanting to chose expression language (EL). We need to decide if
JXPath or Jexl should be the default EL, so that one just need to write:
{$a+$b}
for the default EL ;).
We should also IMO remove the Java package mechanism from the
environment in CTemplate, i.e. the possibillity to do:
${java.util.HashMap()}
and the like, as discussed in
http://marc.theaimsgroup.com/?t=110907735600005&r=1&w=2. If there are
important use cases where one need to create Java objects, we should try
to find cleaner ways to solve them.
Instructions
============
Following the order in
http://cocoon.apache.org/2.1/userdocs/flow/jxtemplate.html
template
--------
Could be kept as is.
import
------
The current import construction must be performed during template
execution (see
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=110659947823196&w=2),
instead of during template compilation. This makes macros slower. I
would like to remove the dynamic aspects of imports so that it works
like include or import in xslt.
set
---
The current behaviour of set is somewhat weird as it works as an
asignement in the current context but you cannot affect a variable that
is created outside the current context, e.g. outside a loop (see
http://marc.theaimsgroup.com/?a=103818032900001&r=1&w=2 and the end of
http://marc.theaimsgroup.com/?t=110623014500003&r=1&w=2 for examples and
discussion).
There are two reasonable solutions:
* Having it declarative and replace set with a let (or declare, define,
variable etc) that just defines the variable, no assignement anymore
(like in e.g. XSLT).
* Replacing set with declare and assign, where the first introduces a
variable with possibly an initial value and an assign that change the
value of an allready existing variable.
I prefer the first solution.
if, choose
----------
if and choose are OK as is IMO.
out
---
It is unclear to me if out is needed. Possibly we could be stricter
concerning output of XML in CTemplate so that an expression whithin a
text only is allowed to return text. And then out should be used for
outputing XML.
forEach
-------
forEach is to complicated for my taste, I would prefer to only have the
select attribute as in XSLT, but I know to little about the Jexl use
cases to know if it is realistic.
formatDate, formatNumber
------------------------
The formating instructions should IMO be removed and replaced with the
convertor mechanism discussed in
http://marc.theaimsgroup.com/?t=109941988300003&r=1&w=2.
macro, eval, evalBody
---------------------
The macro stuff should be replaced with Leszek's new constructions
http://marc.theaimsgroup.com/?t=110940836200001&r=1&w=2.
attribute
---------
An xsl:attribute like construction would be usefull. Seem tricky to
implement though.
caching directives
------------------
Have not spent much thought about caching directives.
Attribute templates
===================
We have also discussed attribute driven template languages (ATL) (see
references in http://wiki.apache.org/cocoon/Templates). Everything above
applies to such an ATL as well, but there might be need for some extra
instructions in an ATL as an ATL constrains how one can write templates
further.
We could even be so radical that we decide that CTemplate should be an
ATL. But I prefer having a separate ATL generator. I need more
experience from writing ATL templates before I'm convinced that it is
the way to go for all templating needs.
--- o0o ---
WDYT?
/Daniel
Re: [RT] CTemplate
Posted by Glen Ezkovich <gl...@hard-bop.com>.
Ralph,
I have no doubt that if the ability to create objects is included it
would be best for you if you could turn it off in the sitemap or
cocoon.xconf. I don't think this feature is necessary. I also think
that if the community decides it is, it should just be available. The
idea of making things difficult to discourage their use is wrong. If
you don't think a feature should be used then don't include the
feature. Show me the use case where creating Java objects in a template
is necessary, then we can evaluate whether there are other better
alternatives and ultimately decide whether this feature is necessary.
On Feb 27, 2005, at 1:03 PM, Ralph Goers wrote:
>> I think we share the same sentiment. On the other hand, you can not
>> be sure that someone has not turned this feature on unless you check
>> and if the feature is there you can check to see if it has been used.
>> Either way you have to check. Admittedly, checking wether it is
>> turned on is easier then checking if it has been used. If you are in
>> charge and you say "do not write Java programs in the template", then
>> the compliance is not voluntary.
>
> On the contrary, we have one group that creates the XSLTs and
> templates. They don't have access to the sitemaps or cocoon.xconf. So
> using a configuration switch is sufficient.
You seem to be assuming this is a global configuration issue. If I
were to make this configurable I would do it on template by template
basis, since it seems that in the general case this would not be
necessary but in a special case it might be expedient. Once you turn it
on globally, say hello to Barbara Eden, the genie is out of the bottle.
Now if you could turn it on by pipeline in the sitemap, you'd be
golden. From a user perspective I think it makes more sense to turn it
on in the template as a processing instruction.
This particular battle is not that important. The feature currently
exists. Its much harder to take it away. It is used. So be it. If you
want to make it configurable and default to off, its better then
nothing. It just adds one more complexity to Cocoon.
Simplification is such hard work. ;-)
P.S.
> Build systems can't check templates that are brought in from a content
> management system at run-time.
Can't you run scripts in you CMS when content is added and/or before it
is published?
Glen Ezkovich
HardBop Consulting
glen at hard-bop.com
A Proverb for Paranoids:
"If they can get you asking the wrong questions, they don't have to
worry about answers."
- Thomas Pynchon Gravity's Rainbow
Re: [RT] CTemplate
Posted by Ralph Goers <Ra...@dslextreme.com>.
Glen Ezkovich wrote:
> I think we share the same sentiment. On the other hand, you can not be
> sure that someone has not turned this feature on unless you check and
> if the feature is there you can check to see if it has been used.
> Either way you have to check. Admittedly, checking wether it is turned
> on is easier then checking if it has been used. If you are in charge
> and you say "do not write Java programs in the template", then the
> compliance is not voluntary.
On the contrary, we have one group that creates the XSLTs and templates.
They don't have access to the sitemaps or cocoon.xconf. So using a
configuration switch is sufficient.
>
> Until recently, I believed that "features" such as this should be
> configurable because as you say, not everyone shares the same view.
> What I've come to realize is that the more there is to configure the
> more difficult and annoying a product becomes to use. I've also come
> to realize that if I believe strongly about a policy and can build
> consensus, then its probably a good thing to enforce that policy in
> code. There is a reason that you will have your organization prohibit
> this feature. Why, in a product that you are contributing to will you
> allow users to make bad decisions? Stand up for your convictions.
> While CTemplate will be Cocoon's template framework, nothing precludes
> those who want the ability to write Java programs in their templates
> from implementing there own template generator or using the current JXTG.
Most Cocoon users don't want to write Java code, and if you have been
following the user's list you'll see that many don't even know how to
write Java. They expect us to give them what they need.
>
> The feature of configuring the ability to write Java programs in a
> template smells of featuritis and MS Office syndrome. If you feel that
> there are currently valid reasons to allow Java programming in a
> template leave the ability in and add a script to your build system
> that checks for this in your templates. If you, like me, can see no
> valid and appropriate use case at this time, take it out. Keep things
> simple.
Build systems can't check templates that are brought in from a content
management system at run-time.
Ralph
Re: [RT] CTemplate
Posted by Glen Ezkovich <gl...@hard-bop.com>.
On Feb 26, 2005, at 4:01 PM, Ralph Goers wrote:
> Glen Ezkovich wrote:
>
>>
>> They will always find a special case where this is most expedient or
>> only solution they see because they don't realize that there are
>> other more appropriate solutions. Making this configurable just adds
>> one more complexity to the equation. I suggest that it be decided one
>> way or the other. If you want users to be able to hang themselves by
>> writing Java code in their templates if they choose, let them. If
>> not, don't.
>>
> The problem is, it isn't our place to be prohibiting this. This is a
> policy decision user's of Cocoon need to make. You can be sure that in
> my organization I would have a policy that prohibits enabling this
> feature, but I am also sure that there are plenty of folks who don't
> share the same view and consider the ability to invoke aribitrary
> stuff from a template a necessity. In that sense it has to be
> configurable, because I want to absolutely be sure the feature cannot
> be used and not rely on folks voluntarily complying.
I think we share the same sentiment. On the other hand, you can not be
sure that someone has not turned this feature on unless you check and
if the feature is there you can check to see if it has been used.
Either way you have to check. Admittedly, checking wether it is turned
on is easier then checking if it has been used. If you are in charge
and you say "do not write Java programs in the template", then the
compliance is not voluntary.
Until recently, I believed that "features" such as this should be
configurable because as you say, not everyone shares the same view.
What I've come to realize is that the more there is to configure the
more difficult and annoying a product becomes to use. I've also come to
realize that if I believe strongly about a policy and can build
consensus, then its probably a good thing to enforce that policy in
code. There is a reason that you will have your organization prohibit
this feature. Why, in a product that you are contributing to will you
allow users to make bad decisions? Stand up for your convictions. While
CTemplate will be Cocoon's template framework, nothing precludes those
who want the ability to write Java programs in their templates from
implementing there own template generator or using the current JXTG.
The feature of configuring the ability to write Java programs in a
template smells of featuritis and MS Office syndrome. If you feel that
there are currently valid reasons to allow Java programming in a
template leave the ability in and add a script to your build system
that checks for this in your templates. If you, like me, can see no
valid and appropriate use case at this time, take it out. Keep things
simple.
Glen Ezkovich
HardBop Consulting
glen at hard-bop.com
A Proverb for Paranoids:
"If they can get you asking the wrong questions, they don't have to
worry about answers."
- Thomas Pynchon Gravity's Rainbow
Re: [RT] CTemplate
Posted by Ralph Goers <Ra...@dslextreme.com>.
Glen Ezkovich wrote:
>
> They will always find a special case where this is most expedient or
> only solution they see because they don't realize that there are other
> more appropriate solutions. Making this configurable just adds one
> more complexity to the equation. I suggest that it be decided one way
> or the other. If you want users to be able to hang themselves by
> writing Java code in their templates if they choose, let them. If not,
> don't.
>
The problem is, it isn't our place to be prohibiting this. This is a
policy decision user's of Cocoon need to make. You can be sure that in
my organization I would have a policy that prohibits enabling this
feature, but I am also sure that there are plenty of folks who don't
share the same view and consider the ability to invoke aribitrary stuff
from a template a necessity. In that sense it has to be configurable,
because I want to absolutely be sure the feature cannot be used and not
rely on folks voluntarily complying.
Re: [RT] CTemplate
Posted by Glen Ezkovich <gl...@hard-bop.com>.
On Feb 26, 2005, at 11:33 AM, Ralph Goers wrote:
> Daniel Fagerstrom wrote:
>
>>
>> We should also IMO remove the Java package mechanism from the
>> environment in CTemplate, i.e. the possibillity to do:
>>
>> ${java.util.HashMap()}
>>
> While I agree that good practice would be to not allow this, I would
> prefer that this behavior be configurable either when the component is
> declared or when it is used. It should not be allowed to be overridden
> in the template. The default should be to not allow this. The reason
> to allow this is that some users will always find some special case
> where this is needed, and not having the ability to do it will make
> their life miserable.
They will always find a special case where this is most expedient or
only solution they see because they don't realize that there are other
more appropriate solutions. Making this configurable just adds one more
complexity to the equation. I suggest that it be decided one way or the
other. If you want users to be able to hang themselves by writing Java
code in their templates if they choose, let them. If not, don't.
The idea of turning dangerous things on and off based on need is
attractive. In the end either this ability gets overlooked or there is
a great explosion and the world comes to an end. ;-)
Glen Ezkovich
HardBop Consulting
glen at hard-bop.com
A Proverb for Paranoids:
"If they can get you asking the wrong questions, they don't have to
worry about answers."
- Thomas Pynchon Gravity's Rainbow
Re: [RT] CTemplate
Posted by Ralph Goers <Ra...@dslextreme.com>.
Daniel Fagerstrom wrote:
>
> We should also IMO remove the Java package mechanism from the
> environment in CTemplate, i.e. the possibillity to do:
>
> ${java.util.HashMap()}
>
While I agree that good practice would be to not allow this, I would
prefer that this behavior be configurable either when the component is
declared or when it is used. It should not be allowed to be overridden
in the template. The default should be to not allow this. The reason
to allow this is that some users will always find some special case
where this is needed, and not having the ability to do it will make
their life miserable.
Re: [RT] CTemplate
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Vadim Gritsenko wrote:
> Daniel Fagerstrom wrote:
>
> <snip/>
>
>> We need to decide if JXPath or Jexl should be the default EL, so that
>> one just need to write:
>>
>> {$a+$b}
>>
>> for the default EL ;).
>
> jx:language="jxpath" on the root element can specify the default for a
> page. IIRC, default on generator level was deemed not granular enough.
Thats ok for me.
>> We should also IMO remove the Java package mechanism from the
>> environment in CTemplate, i.e. the possibillity to do:
>>
>> ${java.util.HashMap()}
>
> Does it mean you'd remove support for Packages.java.util.HashMap as well?
Yes.
This of course require that we can find cleaner replacements for
important use cases of the Package and java environment (given that
there are any). But IMO we should as far as possible discourage Java
programming in templates.
<snip/>
>> caching directives
>> ------------------
>>
>> Have not spent much thought about caching directives.
>
> It must support caching in one way or another, otherwise it's use will
> be limited to non caching pipelines only...
Agree completely with that, but forgot to write it.
/Daniel
Re: [RT] CTemplate
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Leszek Gawron wrote:
> Vadim Gritsenko wrote:
>
>> jx:language="jxpath" on the root element can specify the default for a
>> page. IIRC, default on generator level was deemed not granular enough.
>
> and if there is:
>
> <root param="{variable}" jx:language="jxpath">
> </root>
> would you first check if there is a jx:language attribute
Start element always comes with all attributes in an array, I do not see any
issues quering for jx:language as a first step.
Additionally, it is consistent with approach in many other server page
technologies, including ASP, JSP, XSP.
> I'd prefer <jx:processing-instruction name="language" value="jxpath"/>
You can't have two root elements. Probably you meant:
<?jx-language jxpath?>
That's the syntax for processing instructions. I'd be -0.5 on PIs on the grounds
that nowhere else in Cocoon we make use of them, and there is no good reason for
introducing PIs here.
> Moreover:
> if we use jx:import src="othertemplate.jx" that other template might
> have a different default language.
This is the case regardless of what syntax you choose. Included XML files can
have PIs, and must have a root element.
>>> We should also IMO remove the Java package mechanism from the
>>> environment in CTemplate, i.e. the possibillity to do:
>>>
>>> ${java.util.HashMap()}
>>
>> Does it mean you'd remove support for Packages.java.util.HashMap as well?
>
> Yes he does. This is the same mechanism used.
I'm with Ralph: we should leave a way to make calls to Java. This way does not
have to be easy (I'm +1 on removing support for java, org, etc packages - so
there is no syntactic sugar), but it should be possible (please leave support
for Packages. in).
PS Caching directives probably should be allowed on the root element only - so
no need for scanning in the whole document.
Vadim
Re: [RT] CTemplate
Posted by Leszek Gawron <lg...@apache.org>.
Vadim Gritsenko wrote:
> Daniel Fagerstrom wrote:
>
> <snip/>
>
>> We need to decide if JXPath or Jexl should be the default EL, so that
>> one just need to write:
>>
>> {$a+$b}
>>
>> for the default EL ;).
>
>
> jx:language="jxpath" on the root element can specify the default for a
> page. IIRC, default on generator level was deemed not granular enough.
and if there is:
<root param="{variable}" jx:language="jxpath">
</root>
would you first check if there is a jx:language attribute
I'd prefer <jx:processing-instruction name="language" value="jxpath"/>
Moreover:
if we use jx:import src="othertemplate.jx" that other template might
have a different default language.
>
>
>> We should also IMO remove the Java package mechanism from the
>> environment in CTemplate, i.e. the possibillity to do:
>>
>> ${java.util.HashMap()}
>
>
> Does it mean you'd remove support for Packages.java.util.HashMap as well?
Yes he does. This is the same mechanism used.
>
>
>> set
>> ---
>>
>> The current behaviour of set is somewhat weird as it works as an
>> asignement in the current context but you cannot affect a variable
>> that is created outside the current context, e.g. outside a loop (see
>> http://marc.theaimsgroup.com/?a=103818032900001&r=1&w=2 and the end of
>> http://marc.theaimsgroup.com/?t=110623014500003&r=1&w=2 for examples
>> and discussion).
>>
>> There are two reasonable solutions:
>>
>> * Having it declarative and replace set with a let (or declare,
>> define, variable etc) that just defines the variable, no assignement
>> anymore (like in e.g. XSLT).
>
>
> +1 :-)
Seems like I'm in minority. How would you solve the "looping" problem then?
>
>
>> * Replacing set with declare and assign, where the first introduces a
>> variable with possibly an initial value and an assign that change the
>> value of an allready existing variable.
>>
>> I prefer the first solution.
>
>
> <snip/>
>
>> attribute
>> ---------
>>
>> An xsl:attribute like construction would be usefull. Seem tricky to
>> implement though.
>
>
> It can be implemented with limitations - if those limitations are
> clearly documented, it's ok with me.
>
>
>> caching directives
>> ------------------
>>
>> Have not spent much thought about caching directives.
>
>
> It must support caching in one way or another, otherwise it's use will
> be limited to non caching pipelines only...
Already working. Still I do not know if there is anyone else but me that
has ever used it :)
--
Leszek Gawron MobileBox
lgawron@apache.org http://www.mobilebox.pl
Re: [RT] CTemplate
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Daniel Fagerstrom wrote:
<snip/>
> We need to decide if
> JXPath or Jexl should be the default EL, so that one just need to write:
>
> {$a+$b}
>
> for the default EL ;).
jx:language="jxpath" on the root element can specify the default for a page.
IIRC, default on generator level was deemed not granular enough.
> We should also IMO remove the Java package mechanism from the
> environment in CTemplate, i.e. the possibillity to do:
>
> ${java.util.HashMap()}
Does it mean you'd remove support for Packages.java.util.HashMap as well?
> set
> ---
>
> The current behaviour of set is somewhat weird as it works as an
> asignement in the current context but you cannot affect a variable that
> is created outside the current context, e.g. outside a loop (see
> http://marc.theaimsgroup.com/?a=103818032900001&r=1&w=2 and the end of
> http://marc.theaimsgroup.com/?t=110623014500003&r=1&w=2 for examples and
> discussion).
>
> There are two reasonable solutions:
>
> * Having it declarative and replace set with a let (or declare, define,
> variable etc) that just defines the variable, no assignement anymore
> (like in e.g. XSLT).
+1 :-)
> * Replacing set with declare and assign, where the first introduces a
> variable with possibly an initial value and an assign that change the
> value of an allready existing variable.
>
> I prefer the first solution.
<snip/>
> attribute
> ---------
>
> An xsl:attribute like construction would be usefull. Seem tricky to
> implement though.
It can be implemented with limitations - if those limitations are clearly
documented, it's ok with me.
> caching directives
> ------------------
>
> Have not spent much thought about caching directives.
It must support caching in one way or another, otherwise it's use will be
limited to non caching pipelines only...
Vadim
Re: [RT] CTemplate
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Leszek Gawron wrote:
> Daniel Fagerstrom wrote:
>
>> Now that we have decided to call JXTG CTemplate in the future
>> http://marc.theaimsgroup.com/?t=110908866100002&r=1&w=2, is it a good
>> opportunity to discuss what CTemplate should become.
>>
>> IMO CTemplate should be close to JXTG but we should remove all of the
>> peculiarities and make it as side effect free as possible. And as
>> simple as possible. I also think that we should try to follow the
>> principles from StrinngTemplate
>> http://www.cs.usfca.edu/~parrt/papers/mvc.templates.pdf, but without
>> to much fundamentalism.
>>
>> See http://wiki.apache.org/cocoon/Templates for references to earlier
>> discussions about templates.
>>
>> Expression handling
>> ===================
>>
>> We should get rid of the confusing #{}, ${} syntax. I would prefer
>> using {} as in XSLT. With the new pluggable expressions
>> (http://marc.theaimsgroup.com/?t=110595829700001&r=1&w=2) one can use:
>>
>>
>> {jxpath:$a+$b}
>> or
>> {jexl:a+b}
>>
>> when wanting to chose expression language (EL). We need to decide if
>> JXPath or Jexl should be the default EL, so that one just need to write:
>>
>> {$a+$b}
>>
>> for the default EL ;).
>
> We should make the default language easily configurable.
It is, see
http://svn.apache.org/viewcvs.cgi/cocoon/trunk/src/blocks/template/WEB-INF/xconf/cocoon-template-expression.xconf?view=markup
And we can also use the "jx:language="jxpath" on the root element" that
Vadim reminded about.
> We won't reach a consensus in the battle Jexl vs. JXPath.
No, but the Jexl side is wrong ;)
>> We should also IMO remove the Java package mechanism from the
>> environment in CTemplate, i.e. the possibillity to do:
>>
>> ${java.util.HashMap()}
>
> Note that this is not feature you remove. You won't be able:
> - to construct java objects (which you should not be)
> - to call static methods (which if properly used could be replaced
> with convertors)
> - to access constants defined in classes:
> public class Constants {
> public final static String WEEK_DATE_FORMAT = "['T'ww] yyyy-MM-dd, E";
> }
> and then:
>
> <jx:formatDate value="${date}"
> pattern="${Packages.com.myproject.Constants.WEEK_DATE_FORMAT}"/>
> (this is not a problem of format date if you want to point out
> convertors - it's the general problem of using constants in template)
Yes I know about this, and it is intensional ;) As long as one can solve
those things with more or less ugly Java hacks within the template no
one will be motivated enough to find clean and easy to understand
solutions for important use cases. And this means that we don't care
enough for template authors with limited or no Java skills.
> maybe this could be replaced by the feature of merging input modules
> into template object model.
Might be, but I'm not particulary found of the idea of adding the
bloated and FS ridden input modules to the template object model. It
will certainly not make Cocoon easier to understand for newbies.
If we can throw out the meta modules and other FS from core to some
block with huge warning signs on, and just keep the input modules that
just returns environment objects and the like, whothout to much fancy
extras. In that case it would be OK for me to build template object
model from input modules. But just merging input modules into the object
template model without working on tidying things up first makes the
result far to complex for my taste. But I'm not going to give any -1,
just complaining violently ;)
<snip/>
>> set
>> ---
>>
>> The current behaviour of set is somewhat weird as it works as an
>> asignement in the current context but you cannot affect a variable
>> that is created outside the current context, e.g. outside a loop (see
>> http://marc.theaimsgroup.com/?a=103818032900001&r=1&w=2 and the end
>> of http://marc.theaimsgroup.com/?t=110623014500003&r=1&w=2 for
>> examples and discussion).
>>
>> There are two reasonable solutions:
>>
>> * Having it declarative and replace set with a let (or declare,
>> define, variable etc) that just defines the variable, no assignement
>> anymore (like in e.g. XSLT).
>> * Replacing set with declare and assign, where the first introduces a
>> variable with possibly an initial value and an assign that change the
>> value of an allready existing variable.
>>
>> I prefer the first solution.
>
> As long as we do not have a solution for "looping problem" (which is
> not that rare - got into hacks myself many times) I opt for the second
> solution.
I know that you want assignment. In the end I think that it is about
personal taste and what you think should be part of the view and what
should not. We see what people think and decide based on that.
And even if we decide to not have an assignment, no one can hinder you
from sending a counter object from the control to the view, so you will
be able to hack around anyway. But IMO we should keep CTemplate minimal.
> To keep the template as side effects free as it's possible I would go
> for a solution that I proposed some time ago:
>
> Initially the object model consists of 2 levels:
> - root level that contains all cocoon.* environment beans - you cannot
> do a declare, assign here. This could prevent from modifying the
> environment.
> - first template level. empty at start of template generation. This is
> the level for declaring template variables.
>
> I do not know if that helps anything.
Seem to complicated to me.
>> if, choose
>> ----------
>>
>> if and choose are OK as is IMO.
>>
>> out
>> ---
>>
>> It is unclear to me if out is needed. Possibly we could be stricter
>> concerning output of XML in CTemplate so that an expression whithin a
>> text only is allowed to return text. And then out should be used for
>> outputing XML.
>
> Why do you need jx:out to output xml?
> ${node} is enough to generate sax events automatically.
I know. I find ${node} slightly to powerfull as it not is particulary
obvious from what it looks like that it can generate XML and would
(maybe) like to restrict it to only text generating expressions. In that
case we would need jx:out for generating XML. But that is not to
important to me.
> Are you suggesting that jx:out should automatically parse text
> variables and generate SAX events?
No.
<snip/>
>> attribute
>> ---------
>>
>> An xsl:attribute like construction would be usefull. Seem tricky to
>> implement though.
>
> doable with some kind of extended ContentHandler that
> - introduces a new "attribute" event instead of plain startElement
> - caches element and characters emiting until we are sure there will
> be no more attributes generated.
Ok
>> caching directives
>> ------------------
>>
>> Have not spent much thought about caching directives.
>
> right now anywhere in template you can do:
>
> <someElement jx:cache-key="${key}"/>
>
> This is my fault. It slows down template parsing (all jx:* attributes
> have to be stripped out). Could be much better implemented with:
> jx:processing-instruction name="cache-key" value="${key}"/>
Seem better.
/Daniel
Re: [RT] CTemplate
Posted by Leszek Gawron <lg...@apache.org>.
Daniel Fagerstrom wrote:
> Now that we have decided to call JXTG CTemplate in the future
> http://marc.theaimsgroup.com/?t=110908866100002&r=1&w=2, is it a good
> opportunity to discuss what CTemplate should become.
>
> IMO CTemplate should be close to JXTG but we should remove all of the
> peculiarities and make it as side effect free as possible. And as simple
> as possible. I also think that we should try to follow the principles
> from StrinngTemplate
> http://www.cs.usfca.edu/~parrt/papers/mvc.templates.pdf, but without to
> much fundamentalism.
>
> See http://wiki.apache.org/cocoon/Templates for references to earlier
> discussions about templates.
>
> Expression handling
> ===================
>
> We should get rid of the confusing #{}, ${} syntax. I would prefer using
> {} as in XSLT. With the new pluggable expressions
> (http://marc.theaimsgroup.com/?t=110595829700001&r=1&w=2) one can use:
>
>
> {jxpath:$a+$b}
> or
> {jexl:a+b}
>
> when wanting to chose expression language (EL). We need to decide if
> JXPath or Jexl should be the default EL, so that one just need to write:
>
> {$a+$b}
>
> for the default EL ;).
We should make the default language easily configurable. We won't reach
a consensus in the battle Jexl vs. JXPath.
>
> We should also IMO remove the Java package mechanism from the
> environment in CTemplate, i.e. the possibillity to do:
>
> ${java.util.HashMap()}
Note that this is not feature you remove. You won't be able:
- to construct java objects (which you should not be)
- to call static methods (which if properly used could be replaced with
convertors)
- to access constants defined in classes:
public class Constants {
public final static String WEEK_DATE_FORMAT = "['T'ww] yyyy-MM-dd, E";
}
and then:
<jx:formatDate value="${date}"
pattern="${Packages.com.myproject.Constants.WEEK_DATE_FORMAT}"/>
(this is not a problem of format date if you want to point out
convertors - it's the general problem of using constants in template)
maybe this could be replaced by the feature of merging input modules
into template object model.
>
>
> and the like, as discussed in
> http://marc.theaimsgroup.com/?t=110907735600005&r=1&w=2. If there are
> important use cases where one need to create Java objects, we should try
> to find cleaner ways to solve them.
>
>
> Instructions
> ============
>
> Following the order in
> http://cocoon.apache.org/2.1/userdocs/flow/jxtemplate.html
>
> template
> --------
>
> Could be kept as is.
>
> import
> ------
>
> The current import construction must be performed during template
> execution (see
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=110659947823196&w=2),
> instead of during template compilation. This makes macros slower. I
> would like to remove the dynamic aspects of imports so that it works
> like include or import in xslt.
Agreed. There is no single (and reasonable) use case I can think of that
would require dynamic imports.
>
> set
> ---
>
> The current behaviour of set is somewhat weird as it works as an
> asignement in the current context but you cannot affect a variable that
> is created outside the current context, e.g. outside a loop (see
> http://marc.theaimsgroup.com/?a=103818032900001&r=1&w=2 and the end of
> http://marc.theaimsgroup.com/?t=110623014500003&r=1&w=2 for examples and
> discussion).
>
> There are two reasonable solutions:
>
> * Having it declarative and replace set with a let (or declare, define,
> variable etc) that just defines the variable, no assignement anymore
> (like in e.g. XSLT).
> * Replacing set with declare and assign, where the first introduces a
> variable with possibly an initial value and an assign that change the
> value of an allready existing variable.
>
> I prefer the first solution.
As long as we do not have a solution for "looping problem" (which is not
that rare - got into hacks myself many times) I opt for the second
solution. To keep the template as side effects free as it's possible I
would go for a solution that I proposed some time ago:
Initially the object model consists of 2 levels:
- root level that contains all cocoon.* environment beans - you cannot
do a declare, assign here. This could prevent from modifying the
environment.
- first template level. empty at start of template generation. This is
the level for declaring template variables.
I do not know if that helps anything.
>
> if, choose
> ----------
>
> if and choose are OK as is IMO.
>
> out
> ---
>
> It is unclear to me if out is needed. Possibly we could be stricter
> concerning output of XML in CTemplate so that an expression whithin a
> text only is allowed to return text. And then out should be used for
> outputing XML.
Why do you need jx:out to output xml?
${node} is enough to generate sax events automatically.
Are you suggesting that jx:out should automatically parse text variables
and generate SAX events?
>
> forEach
> -------
>
> forEach is to complicated for my taste, I would prefer to only have the
> select attribute as in XSLT, but I know to little about the Jexl use
> cases to know if it is realistic.
>
> formatDate, formatNumber
> ------------------------
>
> The formating instructions should IMO be removed and replaced with the
> convertor mechanism discussed in
> http://marc.theaimsgroup.com/?t=109941988300003&r=1&w=2.
>
> macro, eval, evalBody
> ---------------------
>
> The macro stuff should be replaced with Leszek's new constructions
> http://marc.theaimsgroup.com/?t=110940836200001&r=1&w=2.
summing up:
jx:macro defines, jx:call invokes
no more jx:eval
jx:evalBody stays as is.
There is a case with invoking macros only by creating an element with
macro's name. Sylvain has got some comments about that in paralell thread.
> attribute
> ---------
>
> An xsl:attribute like construction would be usefull. Seem tricky to
> implement though.
doable with some kind of extended ContentHandler that
- introduces a new "attribute" event instead of plain startElement
- caches element and characters emiting until we are sure there will be
no more attributes generated.
> caching directives
> ------------------
>
> Have not spent much thought about caching directives.
right now anywhere in template you can do:
<someElement jx:cache-key="${key}"/>
This is my fault. It slows down template parsing (all jx:* attributes
have to be stripped out). Could be much better implemented with:
jx:processing-instruction name="cache-key" value="${key}"/>
> Attribute templates
> ===================
>
> We have also discussed attribute driven template languages (ATL) (see
> references in http://wiki.apache.org/cocoon/Templates). Everything above
> applies to such an ATL as well, but there might be need for some extra
> instructions in an ATL as an ATL constrains how one can write templates
> further.
>
> We could even be so radical that we decide that CTemplate should be an
> ATL. But I prefer having a separate ATL generator. I need more
> experience from writing ATL templates before I'm convinced that it is
> the way to go for all templating needs.
Cannot comment anything useful :)
--
Leszek Gawron MobileBox
lgawron@apache.org http://www.mobilebox.pl