Re: [RT] CTemplate
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
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
Glen Ezkovich wrote:
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.
NB if the feature was enabled or disabled using an optional attribute on
the root element, it could still be controlled centrally through the
sitemap. To prevent template authors from enabling this feature, it
would be enough to transform their templates before execution to disable
the feature.
map:match pattern=*.jx
map:generate src={1}.jx/
map:transform src=xsl/disable-java.xsl/
map:serialize type=xml/
/map:match
So you could lock this feature (or any feature) away from your template
authors. NB this is just another application of the general pattern of
dynamic templates, something that was discussed at some length about a
month ago(?).
Cheers
Con
Re: [RT] CTemplate
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=10381803291r=1w=2 and the end of
http://marc.theaimsgroup.com/?t=11062301453r=1w=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
Daniel Fagerstrom wrote:
Now that we have decided to call JXTG CTemplate in the future
http://marc.theaimsgroup.com/?t=11090886612r=1w=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=11059582971r=1w=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] -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=11090773565r=1w=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-devm=110659947823196w=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=10381803291r=1w=2 and the end of
http://marc.theaimsgroup.com/?t=11062301453r=1w=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
Re: [RT] CTemplate
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
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=10381803291r=1w=2 and the end of
http://marc.theaimsgroup.com/?t=11062301453r=1w=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
[EMAIL PROTECTED] http://www.mobilebox.pl
Re: [RT] CTemplate
Leszek Gawron wrote:
Daniel Fagerstrom wrote:
Now that we have decided to call JXTG CTemplate in the future
http://marc.theaimsgroup.com/?t=11090886612r=1w=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=11059582971r=1w=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] -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=10381803291r=1w=2 and the end
of http://marc.theaimsgroup.com/?t=11062301453r=1w=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,
Re: [RT] CTemplate
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
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
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.
