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 2004/12/04 13:48:08 UTC
[RT] Attribute Driven Templates (Was: [RT] do me a favor, don't call
them taglibs)
Stefano Mazzocchi wrote:
> All I ask from a template language:
>
> 1) something that HTML designers can edit with Dreamweaver
> 2) something that doesn't use namespaced tags to identify dynamic
> scopes (clashes with #1)
> 3) something that doesn't use the name taglib
>
> That's pretty much all you have to do to make me happy.
Dreamweaver friendly means basically that it should be attribute driven
I guess?
I'll give some background info and then I'll show how an attribute
driven template language for Cocoon could look. The discussion is based
on TAL http://www.zope.org/Wikis/DevSite/Projects/ZPT/TAL, Tapestry
http://jakarta.apache.org/tapestry/ and some of the functionallity in JXTG.
--- o0o ---
We need two kinds of constructions: expressions and directives.
Expressions
===========
Expressions are the "${expr}" stuff in e.g. JXTG and should be use able
both in text in attributes and element content. Do we need the "$"?
Couldn't we just use "{expr}" as in XSLT?
IIUC TAL doen't use embeded expressions but instead replace element and
attribute content with replace directives (in attributes). It might make
it even more Dreamweaver friendly as you can look at example content
instead of expressions in your design window. But it makes template
writing much harder IMO. We could have such replacement directives if
people want it but, I would prefer having embeded expresions as well.
Directives
==========
TAL uses one name spaced attribute for each directive, e.g.:
<p tal:condition="here/copyright"
tal:content="here/copyright">(c) 2000</p>
Meaning that there will be a paragraph element with the content of
"here/copyright" if "here/copyright" has any content otherwise, no output.
Tapestry instead uses only one attribute, "jwcid", with the directive
name as content.
<tr jwcid="loop">
<td><span jwcid="insertFirstName">John</span></td>
<td><span jwcid="insertLastName">Doe</span></td>
</tr>
Having either one attribute for each directive or having one special
attribute with directives as content are the two main alternatives for
attribute driven templates I would presume.
A problem with "attribute name as directive" is that xml attributes are
unordered. So in the case you need e.g. a double loop over an element,
test if you want to perform a loop or do a loop and test each element, a
mechanism for deciding the order is needed. TAL uses a predetermined
order for the directives. That is far to implicit for my taste and it
doesn't solve the double loop. I would prefer to do something more
explicit like:
<p tal:define-1="x /a/long/path/from/the/root"
tal:condition-2="x"
tal:content-3="x/txt"
tal:attributes-4="class x/class">Ex Text</p>
The "-number" is my adition, TAL uses the predetermined order: define,
condition, content, attributes.
IMO the "attribute name as directive" becomes to complicated so I will
focus on the "attribute content as directive" approach. And give a
proposal on how we could use that in Cocoon.
NIH
===
First some motivation about why I don't think that TAL or Tapestry
templates are good alternatives for using as is in Cocoon (besides that
its much more fun to implement them ourselves ;) ). AFAIU both TAL and
Tapestries directives are very closely connected to the both frameworks
respective component models. We need something that works with our world
view. Furthermore TAL is develped by the Zope community so everything is
in Phyton style, and at that feels less natural, at least for me.
A Proposal
==========
Based on the previous I propse that the attribute driven template
language should be invoked like:
<element do="<directive>" attr1="...">
<content>...</content>
</element>
The idea is that the attribute "do" triger the execution of the
directive. "do" is just an example we could make the trigger attribute
configurable and/or namespaced so that it doesn't colide with your
"host" XML language.
When the directive is executed it has read only access to a context
object containing the same kind of info as FOM, (and maybe some more
stuff, more details have been discused earlier in the template design
threads). It also has access the result of executing its containing
element. I.e. the directive has access to the XML fragment:
<element attr1="...">
<content>...</content>
</element>
Where the attributes are expanded wrt expressions and the content is
evaluated.
Before describing how to handle the case with several directives for an
element I'll make it more concrete by listing some core directives. They
are mainly taken from JXTG and TAL.
if(<test>)
----------
example:
<div do="if(count(cart/item) == 0)">
Your cart is empty
<div>
forEach(<sequence>)
-------------------
example:
<table>
<tr do="forEach(cart/item)">
<td>${index}</td>
<td>${description}</td>
<td>${price}</td>
</tr>
</table>
for(var=<name>,begin=<expr>,end=<expr>,step=<expr>)
---------------------------------------------------
example:
<table>
<tr do="for(var=i,begin=1,end=10)">
<td>${cart[i]/index}</td>
<td>${cart[i]/description}</td>
<td>${cart[i]/price}</td>
</tr>
</table>
context=<expr>
--------------
Set the current evaluation context for expressions.
example:
<table do="context=/shopping/cart">
...
</table>
let(<name>=<expr>,...,<name>=<expr>)
------------------------------------
Define a number of variables for the current context. Observe that this
not is a set operation it just defines the content of the variable
$<name> in the current context, it doesn't intoduce any possibilities to
have side effects.
example:
<h1 do="let(greeting=concat('Hello', user)>
The value of greeting is ${$greeting}
<h1>
macro(<name>,<param-name>,...,<param-name>)
-------------------------------------------
example:
<table do="macro(mytable,list,td-class)">
<tr do="forEach($list)">
<td class="${$class}">${item}</td>
</tr>
</table>
We also need an evalBody as in JXTG. And maybe we should have a
possibilty to give a name space to the macro name.
eval(<name>,context=<expr>,<param-name>=<expr>,...,<param-name>=<expr>)
-----------------------------------------------------------------------
Evaluates the named macro in either the curent context or the
excplictliy chosen, with a number of forma parameters. The containing
element is replaced by the result of the evaluation. And the content of
the the containing element is available in the macro through "evalBody".
example:
<table do="eval(mytable,list=carts,class='checked-out')"/>
We could maybe even have the synatax:
<table do="mytable(list=carts,class='checked-out')"/>
for user defined macros.
replace(<expr>)
---------------
Replaces the containing element with the result of the expression,
useful for inserting DOM etc from the flow layer.
example:
<div do="replace(.)"/>
content(<expr>)
---------------
Like replace but replaces only the content.
attributes(<name>=<expr>,...,<name>=<expr>)
-------------------------------------------
Inserts an attribute.
Several directives
------------------
So, how do we handle multiple directives for one element? We could
handle the TAL example above like:
<p
do="let(x=/a/long/path/from/the/root;if(x);content(x/txt);attributes(class=x/class)">
Ex Text
</p>
The idea is that when the leftmost directive is executed it has the
ability to access the result of executing the directive sequence right
of it in its current context. It will be the rightmost directive that
has direct access to the containing element with evaluated attributes
and body.
The corresponding tag based template expression would be (in pseudo jx):
<jx:let name="x" value="/a/long/path/from/the/root">
<jx:if test="x">
<jx:content select="x/txt">
<jx:attribute name="class" value="x/class">
<p>Ex Text</p>
</jx:attribute>
</jx:content>
</jx:if>
<jx:let>
The jx:attribute and jx:content returns the patched variant of its
respectively body. Not particulary natural constructions in a tag based
template language, but hopefully it explains the direcive combination
construction.
Connection to JXTG
------------------
The directives are almoust defined in such a way that they could be
translated to a tag based templating language like:
directive(param_1=value_1,...,param_n=value_n)
<=>
<jx:directive param_1="value_1" ... param_n="value_n"/>
Maybe we could find a attribute directive language that allows for
complete correspondance. And make tag or directive syntax selectible and
in such way make this effort compatble with JXTG?
Externaly defined directives?
-----------------------------
If we chose to allow extenally defined directives they probably should
be given own namespaces to avoid clashes.
Formating?
----------
IMO most of the basic formating can be done in a special conversion
layer as we have discussed in the convertor thread.
--- o0o ---
I have not given any detailed thought to all of the constructions above,
just wanted to concretize what attribute driven templating could look
like in Cocoon.
WDYT?
Re: [RT] Attribute Driven Templates (Was: [RT] do me a favor, don't
call them taglibs)
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Vadim Gritsenko wrote:
>> for(var=<name>,begin=<expr>,end=<expr>,step=<expr>)
>> ---------------------------------------------------
>
>
> Is it necessary? Current jxtg does not have it (IIRC).
it does.
--
Leszek Gawron lgawron@mobilebox.pl
Project 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: [RT] Attribute Driven Templates
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 7 déc. 04, à 18:54, Sylvain Wallez a écrit :
> ...(hearing Stefano coming behind me, ready to shout "FS!!!" in my
> ears...)
Nahh...his detector exploded yesterday, don't worry.
> ...Now going back to the annotated-HTML-to-XSL compiler that we
> (Anyware) wrote many years ago, it allows to mix both syntax, as
> attributes are simply translated to their XSLT equivalent, and you
> therefore can write plain XSLT in the HTML file (aargh! I hear Stefano
> coming!)
>
> A similar approach could be used for the template language with a
> single engine, by simply converting on the fly
> directives-as-attributes to directives-as-elements...
Interesting - do you envision using XSLT for this conversion? Or doing
it in java code?
-Bertrand
Re: [RT] Attribute Driven Templates
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Sylvain Wallez wrote:
> Daniel Fagerstrom wrote:
> <snip/>
>
>> When I started working on a attribute template language (ATL)
>> proposal, it was obvious to me that it should be attribute name
>> driven. So why did I end up proposing a content driven one? While the
>> attribute driven is atractive for very simple examples it IMO very
>> soon becomes rather complicated as soon as you try to describe
>> something slightly more complicated. E.g. if we need more than one
>> parameter to the directive, how do we describe that? TAL uses the
>> syntax:
>>
>> <textarea rows="80" cols="20"
>> tal:attributes="rows request/rows;cols request/cols">
>
> The problem here is not exactly of having multiple parameters for one
> directive, but more multiple directives with the same name, which
> clashes with the fact that XML require distinct attribute names.
I chosed the example as I got the impression that TAL never uses more
than one argument. So the above was the closest to having more than one
argument. The main place where more than one argument i needed is for
macro definiton and call, and TAL only have Phyton defined macros.
Seeing the example again I realize that I was wrong it actually takes
two argument: in tal:attribute="rows request/rows", "rows" is one
argument and "request/rows" is another.
Somewhat OT, I also think that the "argument", and "content" directives
could be removed. They are used in TAL as they don't have any embeded
expressions (${<expr>}), so it is the only way of injecting data, an
advantage with their approach is that you see example content instead of
content with embeded "${<expr>}" in your WYSIWYG. The disadvantage is
that it is much harder to write the template.
What we need that I forgot is a mechanism for selectively inserting
attributes like:
<option tl:do="attribute-if(.=$current, name='selected')"
selected="selected" ...>
...
that let a named attribute be part of the output if a test is true.
> In our annotated-HTML-to-XSL compiler, we avoid this problem by using
> the following notation for attributes:
>
> <textarea rows="80" cols="20" tal:attribute-rows="request/rows"
> tal:attribute-cols="request/cols">
>
> The "tal:attribute-*" instruction allows any attribute name to be
> specified, while still imposing uniqueness of the names of dynamically
> evaluated attributes.
You instead create the problem that you can't use a scheme for checking
your attributes. Sorry, I just don't like the idea about leting part of
an attribute name become a parameter for the directive.
> <snip/>
>
>>> <tr t:forEach="cart/item">
>>> or
>>> <tr t:forEach="item in cart/item">
>>> for iterators.
>>
>> Here is the questions are if we want to work on a implicitly defined
>> context as in XSLT or if we want to define a loop variable and also
>> if we should use synatctic constructs that are close to natural
>> language like "item in cart/item". I prefer the implictely defined
>> context and would also prefer avoiding complicated syntactic
>> conctructs if possible.
>
> JXTemplate provides both approaches, depending if JXPath or Jexl is
> used [1]. But this is semantically similar to a java.util.Iterator()
> while the "varStatus" variant provides the feature of an indexed loop
> (i.e. "for (int i = 0; i < list.size(); i++)").
>
> This varStatus variant is much more complicated but is sometimes
> invaluable to know where you are in the iteration process.
When do you need that?
> Note than rather to use an approach or the other depending on the EL
> language used or the attribute, we could use different constructs.
>
> Modify the context object:
> <tr t:foreach="cart/item">
>
> Define an iterator:
> <tr t:loop="item in cart/item">
>
> Define an indexed loop:
> <tr t:indexed-loop="status in cart/item">
I don't get the difference between "loop and indexed-loop".
> (hearing Stefano coming behind me, ready to shout "FS!!!" in my ears...)
His new FS detector doesn't seem fully callibrated yet, so I do some
community service instead ;)
FS!!!
AFAIK the only reason to defiene a loop variable is that you don't want
to affect the context. But you can just save the context in a variable
instead:
<tr t:do="let(ctx=.);forEach(cart/item)">
No need to have two constructions.
Concering indexed loops, when do you need them? The idea with a template
is to present model data, so in most cases you just iterate over the
model data. I've used indexed loops in just a handfull of cases, and
that have been in cases where I probably put a little bit to much
programing logic in my view.
<snip/>
> > Needing to solve the same problem as you solved with JXTG but
> imposing an extra
> >constraint (the template must be able to show in Dreamweaver all the
> time) cannot
> >reasonably simplify the problem can it?
>
> Well, you presented some extreme cases. It's unlikely that a single
> tag will hold more that, say, two control structures (e.g. loop and
> if), which keeps the attributes quite readable.
The problem is not the number of directives, it is rather that you need
to understand in what order the two directives is going to be applied.
>> So to sum up, I believe that attribute name based syntax will create
>> more confusion than it is worth. And I'm affraid that the belief that
>> our templates, in some magical way should lose all complexity just by
>> changing their syntax, might be unjustified.
>
> Well finding a consensus between diverging requirements is always
> difficult, and the opinion of each person regarding one or the other
> solution is always related to its own skills, experience and work
> context. People with strong dreamweaver roundtrip requirements will
> use the attribute syntax even if it sometimes looks awkward, whereas
> people more XML-centric will prefer clear structures that show up in
> the outline view of an XML editor.
>
> We know that one size fits all doesn't exist.
>
> Now going back to the annotated-HTML-to-XSL compiler that we (Anyware)
> wrote many years ago, it allows to mix both syntax, as attributes are
> simply translated to their XSLT equivalent, and you therefore can
> write plain XSLT in the HTML file (aargh! I hear Stefano coming!).
There are some user requirements in the (annotated) TAL reference for
allowing mixed syntax in TAL just for handling the cases where the
predefined attribute order doesn't work. But then you break the main
reason for introducing ATL in the first place WYSIWYG friendliness,
don't you. With the syntax I proposed there is no need for mixed mode,
as you can express exactly the same thing with the ATL as you can with
tags (except for chose/when, that needs nested tags, but thats just
syntactic sugar for a sequnce of if).
Look, this is to a large part a matter on your taste and your priorities
when you design the language. I personally feel rather uneasy with a
language where:
<tr t:forEach="cart/item"
t:let"current=.">
and
<tr t:let"current=."
t:forEach="cart/item">
means the same thing, namely (if we chose the same predefined directives
order as in TAL) that "$current" will refer to the surrounding context
rather than to the current item. Also you can't express the second
meaning without introducing a dummy tag.
Also I think that a syntax that makes the directives look like
programming constructs is an advantage rather than an disadvantage. I
mean they happen to be programming constructs and are the concern area
of a programmer. Furthermore I believe that as the template contains two
concern areas: a visual and a more programatic, it is an advantage that
they have different visual "style". That makes it much easier for the
designer and programmer respectively, to selectively focus precognitive
attention on their concern area.
But thats just me, I might have a far to rigid view on language design
by requiring language meaning to explicit. Maybe we should instead
follow the Perl camp (and Humpty Dumpty) and let everything be implicit ;)
'When *I* use a word,' Humpty Dumpty said, in a rather scornful tone,'
it means just what I choose it to mean, neither more nor less.'
> A similar approach could be used for the template language with a
> single engine, by simply converting on the fly
> directives-as-attributes to directives-as-elements.
We can have a single engine with plugable syntax handling, but thats a
implemention issue.
/Daniel
Re: [RT] Attribute Driven Templates
Posted by Sylvain Wallez <sy...@apache.org>.
Daniel Fagerstrom wrote:
<snip/>
> When I started working on a attribute template language (ATL)
> proposal, it was obvious to me that it should be attribute name
> driven. So why did I end up proposing a content driven one? While the
> attribute driven is atractive for very simple examples it IMO very
> soon becomes rather complicated as soon as you try to describe
> something slightly more complicated. E.g. if we need more than one
> parameter to the directive, how do we describe that? TAL uses the syntax:
>
> <textarea rows="80" cols="20"
> tal:attributes="rows request/rows;cols request/cols">
The problem here is not exactly of having multiple parameters for one
directive, but more multiple directives with the same name, which
clashes with the fact that XML require distinct attribute names.
In our annotated-HTML-to-XSL compiler, we avoid this problem by using
the following notation for attributes:
<textarea rows="80" cols="20" tal:attribute-rows="request/rows"
tal:attribute-cols="request/cols">
The "tal:attribute-*" instruction allows any attribute name to be
specified, while still imposing uniqueness of the names of dynamically
evaluated attributes.
<snip/>
>> <tr t:forEach="cart/item">
>> or
>> <tr t:forEach="item in cart/item">
>> for iterators.
>
>
> Here is the questions are if we want to work on a implicitly defined
> context as in XSLT or if we want to define a loop variable and also if
> we should use synatctic constructs that are close to natural language
> like "item in cart/item". I prefer the implictely defined context and
> would also prefer avoiding complicated syntactic conctructs if possible.
JXTemplate provides both approaches, depending if JXPath or Jexl is used
[1]. But this is semantically similar to a java.util.Iterator() while
the "varStatus" variant provides the feature of an indexed loop (i.e.
"for (int i = 0; i < list.size(); i++)").
This varStatus variant is much more complicated but is sometimes
invaluable to know where you are in the iteration process.
Note than rather to use an approach or the other depending on the EL
language used or the attribute, we could use different constructs.
Modify the context object:
<tr t:foreach="cart/item">
Define an iterator:
<tr t:loop="item in cart/item">
Define an indexed loop:
<tr t:indexed-loop="status in cart/item">
(hearing Stefano coming behind me, ready to shout "FS!!!" in my ears...)
<snip/>
> Now, this is IMO, the main question: what level of complexty do we
> need to handle in Cocoon Templates?
>
> Visual Design and Programming SoC
> ==========================
>
> First the reason for caring about ATLs at all is that we want let a
> designer create examples of the pages in our webapp in Dreamweaver
> etc. The programmers can give the pages "life" by adding attribute
> directives. And after that the designers can continue to improve the
> design in their WYSIWYG tools without affecting or risking the
> template aspect of the page.
>
> The template covers two aspects, a visual design aspect and a data
> injection and controll structure aspect. The first handled by a
> designer and the second by a programmer. Of course the designer can
> learn some of the simpler directives by e.g. pattern matching and
> copying. Or maybe more complicated constructs if he/she happen to have
> interest and talent in that direction.
>
> But we should remember that geting data from an object model with an
> EL and selecting, repeating or recursively applying parts of the
> template, based on the data structure from the flowscript, _requires_
> programming skill. Believing something else is IMO wishfull thinking.
Yep. Adding ATL attributes on the HTML page is a developer's work.
> So, the ATL will make the designers life easier as they can use their
> favorite WYSIWYG tool. Will it make the programmer life easier? Yes,
> in the sense that they don't need to be that much involved in changes
> in the visual design anymore. And No, in the sense that using
> attribute directives is more complicated than using a tag based TL as
> JXTG. Now about everything will need to be done within an existing and
> more or less locked HTML (or other) tag structure.
>
> Needing to solve the same problem as you solved with JXTG but imposing
> an extra constraint (the template must be able to show in Dreamweaver
> all the time) cannot reasonably simplify the problem can it?
Well, you presented some extreme cases. It's unlikely that a single tag
will hold more that, say, two control structures (e.g. loop and if),
which keeps the attributes quite readable.
> Combining Directives
> ====================
>
> If you take a look at your current set of JXTG, Velocity, XSLT etc,
> you sometimes need to nest several tags from you TL, if, forEach, set
> etc. If you want to solve the same problem with an ATL, you either has
> to insert dummy tags that in some way or another doesn't going to
> effect the WYSIWYG or more realistically put several attribute
> directives in the same tag. Actually you may end up needing more
> attribute directives than tag directives, as you might need to remove
> the surrounding tag etc.
>
> But wasn't the ATL supposed to lead to much simpler templates than
> with my current tag based TL? There seem to be a common belief that
> this should be the case. But I just fail to understand why changing
> syntax and adding the WYSIWYG constraint should simplifying anything.
> Except for simplfying SoC between roles in an organization, which is
> enough as a motivation IMO.
>
> Ok, so until I am proved wrong I believe that the ability to combine
> directives is a must, if we want to use the ATL for anything more
> serious than some cool looking example snippets.
>
> So, as I wrote in my original post you can either combine directives
> by having several attributes for the attribute name approach or you
> can have a sequence of directives as attribute content. Atributes are
> a set rather than a sequence so you don't have a well defined order
> and to use the same directive name twice is not allowed.
>
> You have to impose a predefined order on the directives for the
> attribute name approach. This is ok if we can restrict the ATL to just
> contain a handfull directives (say 5). If we have more than so it will
> be hard to come upp with and remember a "natural" order of the
> directives. And remember that the order they happen to be written in
> the template doesn't influence the order they are executed in. If you
> doubt, think about the precedence order of operators in Java (no not
> you Vadim, I talk with people with more average attention to detail ;)
> ). The order between '*' and '+' is obvious, but what about '|' and '^'?
>
> I proposed 10 directives, Vadim sugested removing one and adding one
> and Leszek adding two. Remembering predefined order of 10+ directives
> just seem to complicated to me and maybe they have problems with that
> in TAL:
> http://zope.org/Wikis/DevSite/Projects/ZPT/RemoveInsaneConstructs.
>
> So to sum up, I believe that attribute name based syntax will create
> more confusion than it is worth. And I'm affraid that the belief that
> our templates, in some magical way should lose all complexity just by
> changing their syntax, might be unjustified.
Well finding a consensus between diverging requirements is always
difficult, and the opinion of each person regarding one or the other
solution is always related to its own skills, experience and work
context. People with strong dreamweaver roundtrip requirements will use
the attribute syntax even if it sometimes looks awkward, whereas people
more XML-centric will prefer clear structures that show up in the
outline view of an XML editor.
We know that one size fits all doesn't exist.
Now going back to the annotated-HTML-to-XSL compiler that we (Anyware)
wrote many years ago, it allows to mix both syntax, as attributes are
simply translated to their XSLT equivalent, and you therefore can write
plain XSLT in the HTML file (aargh! I hear Stefano coming!).
A similar approach could be used for the template language with a single
engine, by simply converting on the fly directives-as-attributes to
directives-as-elements.
Sylvain
[1] http://cocoon.apache.org/2.1/userdocs/flow/jxtemplate.html#forEach
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [RT] Attribute Driven Templates
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Vadim Gritsenko wrote:
> Daniel Fagerstrom wrote:
<snip what="thing discussed in another mail"/>
> Here, I just want to comment that I find way more intuitive and user
> friendly following constructs:
>
>> if(<test>)
>> ----------
>>
>> example:
>>
>> <div do="if(count(cart/item) == 0)">
>
>
> <div t:if="cart/item">
> and
> <div t:unless="cart/item">
> for conditions.
My example should have been:
<div do="if(cart/item)">
and I'm ok with
<div do="unless(cart/item)">
if people want it.
Concerning attribute name v.s. attribute content based syntax I agree
with you and others that the former is slightly easier to get used to
for simple examples. When studying TAL and Tapestry I found TAL examples
(that is based on attributes) easier to understand than the, IMO, rather
cryptic Tabestry syntax (based on attribute content). Tapestry make
things even worse by using "jwcid" as attribute name instead of e.g.
"do" or "tl:do".
When I started working on a attribute template language (ATL) proposal,
it was obvious to me that it should be attribute name driven. So why did
I end up proposing a content driven one? While the attribute driven is
atractive for very simple examples it IMO very soon becomes rather
complicated as soon as you try to describe something slightly more
complicated. E.g. if we need more than one parameter to the directive,
how do we describe that? TAL uses the syntax:
<textarea rows="80" cols="20"
tal:attributes="rows request/rows;cols request/cols">
While thinking about how to use a syntax like that for defining a macro
that both need a name and anumber of parameters, my entusiasm for the
approach started to decrease. We also have the question about how solve
the problem with having more than one. But before discussing that I'll
comment some more constructions.
>> Your cart is empty
>> <div>
>>
>> forEach(<sequence>)
>> -------------------
>>
>> example:
>>
>> <table>
>> <tr do="forEach(cart/item)">
>
>
> <tr t:forEach="cart/item">
> or
> <tr t:forEach="item in cart/item">
> for iterators.
Here is the questions are if we want to work on a implicitly defined
context as in XSLT or if we want to define a loop variable and also if
we should use synatctic constructs that are close to natural language
like "item in cart/item". I prefer the implictely defined context and
would also prefer avoiding complicated syntactic conctructs if possible.
>> <td>${index}</td>
>> <td>${description}</td>
>> <td>${price}</td>
>> </tr>
>> </table>
>>
>> for(var=<name>,begin=<expr>,end=<expr>,step=<expr>)
>> ---------------------------------------------------
>
> Is it necessary? Current jxtg does not have it (IIRC).
I don't think it is necessary. I included it as jxtg has it.
>> context=<expr>
>> --------------
>>
>> Set the current evaluation context for expressions.
>>
>> example:
>>
>> <table do="context=/shopping/cart">
>
>
> <table t:for="/shopping/cart">
> or t:context, or some such.
>
> ... and the rest is similar. I also feel that expressions like
> "if();context();let();for();etc;etc;etc" are too complicated for what
> is necessary in Cocoon Templates.
Now, this is IMO, the main question: what level of complexty do we need
to handle in Cocoon Templates?
Visual Design and Programming SoC
==========================
First the reason for caring about ATLs at all is that we want let a
designer create examples of the pages in our webapp in Dreamweaver etc.
The programmers can give the pages "life" by adding attribute
directives. And after that the designers can continue to improve the
design in their WYSIWYG tools without affecting or risking the template
aspect of the page.
The template covers two aspects, a visual design aspect and a data
injection and controll structure aspect. The first handled by a designer
and the second by a programmer. Of course the designer can learn some of
the simpler directives by e.g. pattern matching and copying. Or maybe
more complicated constructs if he/she happen to have interest and talent
in that direction.
But we should remember that geting data from an object model with an EL
and selecting, repeating or recursively applying parts of the template,
based on the data structure from the flowscript, _requires_ programming
skill. Believing something else is IMO wishfull thinking.
So, the ATL will make the designers life easier as they can use their
favorite WYSIWYG tool. Will it make the programmer life easier? Yes, in
the sense that they don't need to be that much involved in changes in
the visual design anymore. And No, in the sense that using attribute
directives is more complicated than using a tag based TL as JXTG. Now
about everything will need to be done within an existing and more or
less locked HTML (or other) tag structure.
Needing to solve the same problem as you solved with JXTG but imposing
an extra constraint (the template must be able to show in Dreamweaver
all the time) cannot reasonably simplify the problem can it?
Combining Directives
====================
If you take a look at your current set of JXTG, Velocity, XSLT etc, you
sometimes need to nest several tags from you TL, if, forEach, set etc.
If you want to solve the same problem with an ATL, you either has to
insert dummy tags that in some way or another doesn't going to effect
the WYSIWYG or more realistically put several attribute directives in
the same tag. Actually you may end up needing more attribute directives
than tag directives, as you might need to remove the surrounding tag etc.
But wasn't the ATL supposed to lead to much simpler templates than with
my current tag based TL? There seem to be a common belief that this
should be the case. But I just fail to understand why changing syntax
and adding the WYSIWYG constraint should simplifying anything. Except
for simplfying SoC between roles in an organization, which is enough as
a motivation IMO.
Ok, so until I am proved wrong I believe that the ability to combine
directives is a must, if we want to use the ATL for anything more
serious than some cool looking example snippets.
So, as I wrote in my original post you can either combine directives by
having several attributes for the attribute name approach or you can
have a sequence of directives as attribute content. Atributes are a set
rather than a sequence so you don't have a well defined order and to use
the same directive name twice is not allowed.
You have to impose a predefined order on the directives for the
attribute name approach. This is ok if we can restrict the ATL to just
contain a handfull directives (say 5). If we have more than so it will
be hard to come upp with and remember a "natural" order of the
directives. And remember that the order they happen to be written in the
template doesn't influence the order they are executed in. If you doubt,
think about the precedence order of operators in Java (no not you Vadim,
I talk with people with more average attention to detail ;) ). The order
between '*' and '+' is obvious, but what about '|' and '^'?
I proposed 10 directives, Vadim sugested removing one and adding one and
Leszek adding two. Remembering predefined order of 10+ directives just
seem to complicated to me and maybe they have problems with that in TAL:
http://zope.org/Wikis/DevSite/Projects/ZPT/RemoveInsaneConstructs.
So to sum up, I believe that attribute name based syntax will create
more confusion than it is worth. And I'm affraid that the belief that
our templates, in some magical way should lose all complexity just by
changing their syntax, might be unjustified.
/Daniel
Re: [Templates] Summary and Voting aspects
Posted by Glen Ezkovich <gl...@hard-bop.com>.
On Dec 8, 2004, at 5:37 AM, Daniel Fagerstrom wrote:
>>
>> You mean defining the language. No one wants to implement. ;-)
>
> Actually there are some people around here that prefer programming to
> discussing. And a few impresive persons who manage to be active in
> both areas :)
Ahhhh.... that explains why there is a Cocoon and not just a set of
requirements. :-)
Glen Ezkovich
HardBop Consulting
glen at hard-bop.com
http://www.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: [Templates] Summary and Voting aspects
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Glen Ezkovich wrote:
> On Dec 7, 2004, at 4:18 AM, Daniel Fagerstrom wrote:
>
>> Refactoring JXTG
>> ================
>
> I think everything starts here. Once this gets refactored the
> opportunities for further development should become apparent. There is
> nothing terribly wrong with JXTG, except that it is a monolithic class
> with monolithic methods.
Yes, my current view is that I feel unconfortable with starting from
scratch
(http://www.joelonsoftware.com/printerFriendly/articles/fog0000000348.html).
Fun or not, we should just build a large test set arround JXTG and
refactor it, towards the kind of architecture that we have discussed in
previous discussions.
We can do that work on a copy of JXTG in the template block. There is
not that much activity on the current codebase, so I think it easier to
keep them syncronized than working on everything whithin core. I have
started some work in that direction and will put them in SVN as soon as
I get my splitted version of JXTG to compile again :/
>> For 1), the back compabillity preserving refactoring of JXTG. I
>> cannot see any need for voting about this. Either it gains community
>> support in terms of that people joins in design, implementation and
>> testing, or it don't. And in that case we just remove it. Then if the
>> new refactored implementation should replace the current one and get
>> "oficial status", thats certainly something to vote about. Also if we
>> develop some new interfaces e.g. for ELs or formaters that we feel
>> that should be made part of core, it will also be something that
>> should be handled by proposals and votes.
>>
>> I can assure you that I have no urge to implement everything myself
>> at all (as some of you might have noticed I enjoy design descussions
>> and proposals more than implementing stuff ;) ),
>
> You mean some people actually LIKE to implement stuff? ;-)
I do, but not as much as discussing the design ;)
>> I will continue to strive for community involvment. And I will write
>> a proposal about how to continue the refactoring as soon as I find time.
>
>> Next Generation JXTG
>> ====================
>>
>> This is about how we should continue our development of the template
>> language beyond JXTG 1.0. It is purely at the RT stage, no concrete
>> design proposals yet. Later there might be proposals in form of
>> documents or proof of concept implementations. But that is a later
>> question.
>
> And an interesting discussion. I think once people look at the
> refactored JXTG and have an itch to scratch you will see a few
> attempts at expression language development.
Yes, the current monolith makes that far to hard.
>> Attribute Driven Templating
>> ===========================
>>
>> This is ongoing discussions. My hope is that we can design the
>> template engine in such a way that the synatx handling part is
>> plugable so that attribute and tag driven templates (JXTG) can
>> coexist, (although not in the same document ;) ).
>
> I'm guessing that after refactoring JXTG you will see that this is
> easily doable. I'm only guessing because I have only taken a brief
> look at JXTG's code, but one of the goals of refactoring is to
> organize the code properly.
Yes, it will be easily doable after refactoring.
>> But that is a technical quiestion IMO. Anyway, we need to discuss
>> the consequences of dirrerent syntaxes a little bit more before
>> implementing anything.
>
> You mean defining the language. No one wants to implement. ;-)
Actually there are some people around here that prefer programming to
discussing. And a few impresive persons who manage to be active in both
areas :)
> Glen Ezkovich
> HardBop Consulting
> glen at hard-bop.com
> http://www.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
Cool, one of my favourite books.
Re: [Templates] Summary and Voting aspects (was: [RT] Attribute Driven Templates)
Posted by Glen Ezkovich <gl...@hard-bop.com>.
On Dec 7, 2004, at 4:18 AM, Daniel Fagerstrom wrote:
>
> Refactoring JXTG
> ================
I think everything starts here. Once this gets refactored the
opportunities for further development should become apparent. There is
nothing terribly wrong with JXTG, except that it is a monolithic class
with monolithic methods.
>
> For 1), the back compabillity preserving refactoring of JXTG. I cannot
> see any need for voting about this. Either it gains community support
> in terms of that people joins in design, implementation and testing,
> or it don't. And in that case we just remove it. Then if the new
> refactored implementation should replace the current one and get
> "oficial status", thats certainly something to vote about. Also if we
> develop some new interfaces e.g. for ELs or formaters that we feel
> that should be made part of core, it will also be something that
> should be handled by proposals and votes.
>
> I can assure you that I have no urge to implement everything myself at
> all (as some of you might have noticed I enjoy design descussions and
> proposals more than implementing stuff ;) ),
You mean some people actually LIKE to implement stuff? ;-)
> I will continue to strive for community involvment. And I will write
> a proposal about how to continue the refactoring as soon as I find
> time.
>
> Next Generation JXTG
> ====================
>
> This is about how we should continue our development of the template
> language beyond JXTG 1.0. It is purely at the RT stage, no concrete
> design proposals yet. Later there might be proposals in form of
> documents or proof of concept implementations. But that is a later
> question.
And an interesting discussion. I think once people look at the
refactored JXTG and have an itch to scratch you will see a few attempts
at expression language development.
>
> Attribute Driven Templating
> ===========================
>
> This is ongoing discussions. My hope is that we can design the
> template engine in such a way that the synatx handling part is
> plugable so that attribute and tag driven templates (JXTG) can
> coexist, (although not in the same document ;) ).
I'm guessing that after refactoring JXTG you will see that this is
easily doable. I'm only guessing because I have only taken a brief look
at JXTG's code, but one of the goals of refactoring is to organize the
code properly.
> But that is a technical quiestion IMO. Anyway, we need to discuss the
> consequences of dirrerent syntaxes a little bit more before
> implementing anything.
You mean defining the language. No one wants to implement. ;-)
Glen Ezkovich
HardBop Consulting
glen at hard-bop.com
http://www.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
[Templates] Summary and Voting aspects (was: [RT] Attribute Driven
Templates)
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Vadim Gritsenko wrote:
> Daniel Fagerstrom wrote:
> Just a reminder; before you guys start implementing one or another
> template language, could we have [VOTE] for one of the variants, have
> [PROPOSAL], or at least [SUMMARY]? :)
We are discussing several tasks:
1) Refactoring of JXTG so that that it becomes easier to support and so
that some parts become reusable
2) Possibly designing a new version (2.0 maybe) of JXTG. Where some
sugestions has been: removing formating and placing it in a separate
layer, removing side effects, allowing (or forbiding ;) ) collections of
externaly defined tags written in Java.
3) An attribute driven template language, mainly for simplifying for
those using Dreamweaver and similar in their development, but there is
also a hope that such a template language could be less verbose and
easier to read.
My hope is that these three tasks can share most of the code and lead to
some new strcitly defined contracts between parts. But that is something
that we will see when the work continues.
I wrote some Wiki pages (http://wiki.apache.org/cocoon/Templates) with
some kind of overview, and liks to mail discussions. I also wikified my
design proposals, so that they can evolve based on our discussions.
Everyone is welcome in keeping them up to date and adding their comments
or proposals.
Refactoring JXTG
================
For 1), the back compabillity preserving refactoring of JXTG. I cannot
see any need for voting about this. Either it gains community support in
terms of that people joins in design, implementation and testing, or it
don't. And in that case we just remove it. Then if the new refactored
implementation should replace the current one and get "oficial status",
thats certainly something to vote about. Also if we develop some new
interfaces e.g. for ELs or formaters that we feel that should be made
part of core, it will also be something that should be handled by
proposals and votes.
I can assure you that I have no urge to implement everything myself at
all (as some of you might have noticed I enjoy design descussions and
proposals more than implementing stuff ;) ), I will continue to strive
for community involvment. And I will write a proposal about how to
continue the refactoring as soon as I find time.
Next Generation JXTG
====================
This is about how we should continue our development of the template
language beyond JXTG 1.0. It is purely at the RT stage, no concrete
design proposals yet. Later there might be proposals in form of
documents or proof of concept implementations. But that is a later question.
Attribute Driven Templating
===========================
This is ongoing discussions. My hope is that we can design the template
engine in such a way that the synatx handling part is plugable so that
attribute and tag driven templates (JXTG) can coexist, (although not in
the same document ;) ). But that is a technical quiestion IMO. Anyway,
we need to discuss the consequences of dirrerent syntaxes a little bit
more before implementing anything.
HTH
/Daniel
Re: [RT] Attribute Driven Templates (Was: [RT] do me a favor, don't
call them taglibs)
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Daniel Fagerstrom wrote:
>
Just a reminder; before you guys start implementing one or another template
language, could we have [VOTE] for one of the variants, have [PROPOSAL], or at
least [SUMMARY]? :)
Here, I just want to comment that I find way more intuitive and user friendly
following constructs:
> if(<test>)
> ----------
>
> example:
>
> <div do="if(count(cart/item) == 0)">
<div t:if="cart/item">
and
<div t:unless="cart/item">
for conditions.
> Your cart is empty
> <div>
>
>
> forEach(<sequence>)
> -------------------
>
> example:
>
> <table>
> <tr do="forEach(cart/item)">
<tr t:forEach="cart/item">
or
<tr t:forEach="item in cart/item">
for iterators.
> <td>${index}</td>
> <td>${description}</td>
> <td>${price}</td>
> </tr>
> </table>
>
>
> for(var=<name>,begin=<expr>,end=<expr>,step=<expr>)
> ---------------------------------------------------
Is it necessary? Current jxtg does not have it (IIRC).
> context=<expr>
> --------------
>
> Set the current evaluation context for expressions.
>
> example:
>
> <table do="context=/shopping/cart">
<table t:for="/shopping/cart">
or t:context, or some such.
... and the rest is similar. I also feel that expressions like
"if();context();let();for();etc;etc;etc" are too complicated for what is
necessary in Cocoon Templates.
Vadim
> ...
> </table>
>
>
> let(<name>=<expr>,...,<name>=<expr>)
> ------------------------------------
>
> Define a number of variables for the current context. Observe that this
> not is a set operation it just defines the content of the variable
> $<name> in the current context, it doesn't intoduce any possibilities to
> have side effects.
>
> example:
>
> <h1 do="let(greeting=concat('Hello', user)>
> The value of greeting is ${$greeting}
> <h1>
>
>
> macro(<name>,<param-name>,...,<param-name>)
> -------------------------------------------
>
> example:
>
> <table do="macro(mytable,list,td-class)">
> <tr do="forEach($list)">
> <td class="${$class}">${item}</td>
> </tr>
> </table>
>
> We also need an evalBody as in JXTG. And maybe we should have a
> possibilty to give a name space to the macro name.
>
>
> eval(<name>,context=<expr>,<param-name>=<expr>,...,<param-name>=<expr>)
> -----------------------------------------------------------------------
>
> Evaluates the named macro in either the curent context or the
> excplictliy chosen, with a number of forma parameters. The containing
> element is replaced by the result of the evaluation. And the content of
> the the containing element is available in the macro through "evalBody".
>
> example:
>
> <table do="eval(mytable,list=carts,class='checked-out')"/>
>
> We could maybe even have the synatax:
>
> <table do="mytable(list=carts,class='checked-out')"/>
>
> for user defined macros.
>
>
> replace(<expr>)
> ---------------
>
> Replaces the containing element with the result of the expression,
> useful for inserting DOM etc from the flow layer.
>
> example:
>
> <div do="replace(.)"/>
>
>
> content(<expr>)
> ---------------
>
> Like replace but replaces only the content.
>
>
> attributes(<name>=<expr>,...,<name>=<expr>)
> -------------------------------------------
>
> Inserts an attribute.
>
>
> Several directives
> ------------------
>
> So, how do we handle multiple directives for one element? We could
> handle the TAL example above like:
>
> <p
> do="let(x=/a/long/path/from/the/root;if(x);content(x/txt);attributes(class=x/class)">
>
> Ex Text
> </p>
>
> The idea is that when the leftmost directive is executed it has the
> ability to access the result of executing the directive sequence right
> of it in its current context. It will be the rightmost directive that
> has direct access to the containing element with evaluated attributes
> and body.
>
> The corresponding tag based template expression would be (in pseudo jx):
>
> <jx:let name="x" value="/a/long/path/from/the/root">
> <jx:if test="x">
> <jx:content select="x/txt">
> <jx:attribute name="class" value="x/class">
> <p>Ex Text</p>
> </jx:attribute>
> </jx:content>
> </jx:if>
> <jx:let>
>
> The jx:attribute and jx:content returns the patched variant of its
> respectively body. Not particulary natural constructions in a tag based
> template language, but hopefully it explains the direcive combination
> construction.
<snip/>
Re: [RT] Attribute Driven Templates
Posted by Reinhard Poetz <re...@apache.org>.
Leszek Gawron wrote:
> Reinhard Poetz wrote:
>
>> Leszek Gawron wrote:
>>
>>> Reinhard Poetz wrote:
>>>
>>>> But the Dreamweaver usecase is a valid one (It was me who started a
>>>> discussion about this in May after attenting a Tapestry seminar at a
>>>> conference) and so we should support it.
>>>>
>>>>>
>>>>> Now, having them cohexist in the page smells like FS, though ;-)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Can't agree more.
>>>
>>>
>>>
>>> What would you do then if you started simple (with attributes) and
>>> found out after a while (when the template is already quite big) that
>>> you need a tag syntax in some places?
>>>
>>
>> Aren't they completly equivalent?
>
> Yes they are (will/would be). Thing is you do not want them to coexist
> in a single template.
Without a usecase where it makes really sense to support both ways, no.
(Think of the complaints about the two syntax for expression languages.)
--
Reinhard
Re: [RT] Attribute Driven Templates
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Reinhard Poetz wrote:
> Leszek Gawron wrote:
>
>> Reinhard Poetz wrote:
>>
>>> But the Dreamweaver usecase is a valid one (It was me who started a
>>> discussion about this in May after attenting a Tapestry seminar at a
>>> conference) and so we should support it.
>>>
>>>>
>>>> Now, having them cohexist in the page smells like FS, though ;-)
>>>
>>>
>>>
>>>
>>> Can't agree more.
>>
>>
>> What would you do then if you started simple (with attributes) and
>> found out after a while (when the template is already quite big) that
>> you need a tag syntax in some places?
>>
>
> Aren't they completly equivalent?
Yes they are (will/would be). Thing is you do not want them to coexist
in a single template.
--
Leszek Gawron lgawron@mobilebox.pl
Project 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: [RT] Attribute Driven Templates
Posted by Reinhard Poetz <re...@apache.org>.
Leszek Gawron wrote:
> Reinhard Poetz wrote:
>
>> But the Dreamweaver usecase is a valid one (It was me who started a
>> discussion about this in May after attenting a Tapestry seminar at a
>> conference) and so we should support it.
>>
>>>
>>> Now, having them cohexist in the page smells like FS, though ;-)
>>
>>
>>
>> Can't agree more.
>
> What would you do then if you started simple (with attributes) and found
> out after a while (when the template is already quite big) that you need
> a tag syntax in some places?
>
Aren't they completly equivalent?
--
Reinhard
Re: [RT] Attribute Driven Templates
Posted by Stefano Mazzocchi <st...@apache.org>.
Leszek Gawron wrote:
> Reinhard Poetz wrote:
>
>> But the Dreamweaver usecase is a valid one (It was me who started a
>> discussion about this in May after attenting a Tapestry seminar at a
>> conference) and so we should support it.
>>
>>>
>>> Now, having them cohexist in the page smells like FS, though ;-)
>>
>>
>>
>> Can't agree more.
>
> What would you do then if you started simple (with attributes) and found
> out after a while (when the template is already quite big) that you need
> a tag syntax in some places?
You come back here and ask for that feature.
Clean design rule #1: avoid YAGNI.
--
Stefano.
Re: [RT] Attribute Driven Templates
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Reinhard Poetz wrote:
> But the Dreamweaver usecase is a valid one (It was me who started a
> discussion about this in May after attenting a Tapestry seminar at a
> conference) and so we should support it.
>
>>
>> Now, having them cohexist in the page smells like FS, though ;-)
>
>
> Can't agree more.
What would you do then if you started simple (with attributes) and found
out after a while (when the template is already quite big) that you need
a tag syntax in some places?
--
Leszek Gawron lgawron@mobilebox.pl
Project 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: [RT] Attribute Driven Templates
Posted by Reinhard Poetz <re...@apache.org>.
Stefano Mazzocchi wrote:
> Daniel Fagerstrom wrote:
>
>>> I like this idea very much. It would be a shame if the quirks of
>>> Dreamweaver should force everyone to use an awkward syntax.
>>
>>
>> The attribute driven synatax is new to me so I don't know if I find it
>> awkward or not, I'll need to see some larger examples. Anyway, we have
>> a user community (and our own webbaps) to think about, we cannot
>> change dirrection at every whim. We must support JXTG for the
>> forseable future so I would prefer if we could allow both syntaxes.
>>
>> Now, it will be interesting to see how long time it will take before
>> someone explains that: this is FS we only need to support one syntax,
>> namely the obviously optimal one, and those who believe that they need
>> the other one are generally less knowing and doesn't understand their
>> own best ;)
>
>
> I know you are looking at me :-) but interestingly enough, my FS alarm
> didn't go off.
>
> I really think that it makes sense to have two different syntaxes, one
> that uses elements and another one that uses attributes.
Yes, I think we need both ways. *I* prefer the element style because for me
expresions like
<p
do="let(x=/a/long/path/from/the/root;if(x);content(x/txt);attributes(class=x/class)">
Ex Text
</p>
are close to be unreadable - I have the feeling of looking at a regular
expression (and this is _not_ a good feeling)
But the Dreamweaver usecase is a valid one (It was me who started a discussion
about this in May after attenting a Tapestry seminar at a conference) and so we
should support it.
>
> Now, having them cohexist in the page smells like FS, though ;-)
Can't agree more.
--
Reinhard
Re: [RT] Attribute Driven Templates
Posted by Glen Ezkovich <gl...@hard-bop.com>.
On Dec 5, 2004, at 11:59 AM, Stefano Mazzocchi wrote:
> Glen Ezkovich wrote:
>> On Dec 5, 2004, at 10:02 AM, Daniel Fagerstrom wrote:
>>> Your alarm might have been desensitized by our continuos stream of
>>> FS ;) Actually it would be boring if you were easy to predict.
>>>
>>>> I really think that it makes sense to have two different syntaxes,
>>>> one that uses elements and another one that uses attributes.
>>>
>>>
>>> So do I.
>>>
>>>> Now, having them cohexist in the page smells like FS, though ;-)
>> Yes, thats why they should be in separate components. Pick your
>> poison. You know over time that one language will evolve past the
>> other. Having to maintain equivalence is a burden not needed. As I've
>> stated before picking the language should be a compile time decision.
>
> -1, that would make it impossible to use the two syntaxes in different
> parts of the site and there is no need to restrict that since it's
> perfectly valid that some parts of the templates will be edited by
> some people and some others by some others, with different skills.
Why? Just to be clear, I meant Java compile time. Use different
generators and transformers for each language. If you generate using
one, there is no reason to have to stick to the same language in the
transformation. Same goes for multiple transformations. I don't see the
need to use the same language in every step of a pipeline. The idea is
to provide as much flexibility as possible while constraining the use
of multiple languages in a single template.
Glen Ezkovich
HardBop Consulting
glen at hard-bop.com
http://www.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] Attribute Driven Templates
Posted by Stefano Mazzocchi <st...@apache.org>.
Glen Ezkovich wrote:
>
> On Dec 5, 2004, at 10:02 AM, Daniel Fagerstrom wrote:
>
>> Your alarm might have been desensitized by our continuos stream of FS
>> ;) Actually it would be boring if you were easy to predict.
>>
>>> I really think that it makes sense to have two different syntaxes,
>>> one that uses elements and another one that uses attributes.
>>
>>
>> So do I.
>>
>>> Now, having them cohexist in the page smells like FS, though ;-)
>
>
> Yes, thats why they should be in separate components. Pick your poison.
> You know over time that one language will evolve past the other. Having
> to maintain equivalence is a burden not needed. As I've stated before
> picking the language should be a compile time decision.
-1, that would make it impossible to use the two syntaxes in different
parts of the site and there is no need to restrict that since it's
perfectly valid that some parts of the templates will be edited by some
people and some others by some others, with different skills.
--
Stefano.
Re: [RT] Attribute Driven Templates
Posted by Glen Ezkovich <ge...@mac.com>.
On Dec 5, 2004, at 10:02 AM, Daniel Fagerstrom wrote:
> Your alarm might have been desensitized by our continuos stream of FS
> ;) Actually it would be boring if you were easy to predict.
>
>> I really think that it makes sense to have two different syntaxes,
>> one that uses elements and another one that uses attributes.
>
> So do I.
>
>> Now, having them cohexist in the page smells like FS, though ;-)
Yes, thats why they should be in separate components. Pick your poison.
You know over time that one language will evolve past the other. Having
to maintain equivalence is a burden not needed. As I've stated before
picking the language should be a compile time decision.
Glen Ezkovich
HardBop Consulting
glen at hard-bop.com
http://www.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] Attribute Driven Templates
Posted by Stefano Mazzocchi <st...@apache.org>.
Daniel Fagerstrom wrote:
> Stefano Mazzocchi wrote:
>
>> Daniel Fagerstrom wrote:
>>
>>>> I like this idea very much. It would be a shame if the quirks of
>>>> Dreamweaver should force everyone to use an awkward syntax.
>>>
>>>
>>> The attribute driven synatax is new to me so I don't know if I find
>>> it awkward or not, I'll need to see some larger examples. Anyway, we
>>> have a user community (and our own webbaps) to think about, we cannot
>>> change dirrection at every whim. We must support JXTG for the
>>> forseable future so I would prefer if we could allow both syntaxes.
>>>
>>> Now, it will be interesting to see how long time it will take before
>>> someone explains that: this is FS we only need to support one syntax,
>>> namely the obviously optimal one, and those who believe that they
>>> need the other one are generally less knowing and doesn't understand
>>> their own best ;)
>>
>>
>> I know you are looking at me :-) but interestingly enough, my FS alarm
>> didn't go off.
>
> Your alarm might have been desensitized by our continuos stream of FS ;)
no, well, FS is triggered when a solution is proposed for a problem that
has not been mentioned but it makes sense from a "completeness" point of
view. Here, things are different since all sort of problems and
requirements were put on the table and in order to make everybody happy
the compromise has to be rather flexible.
The problem I have is never how flexible (otherwise, cocoon wouldn't be
here, right?) is "how more flexible than needed".
> Actually it would be boring if you were easy to predict.
Not only that, I would be useless. My only contributions to this project
are basically to scream "FS!!!" once and a while :-)
>> I really think that it makes sense to have two different syntaxes, one
>> that uses elements and another one that uses attributes.
>
> So do I.
>
>> Now, having them cohexist in the page smells like FS, though ;-)
>
> How did you know that I was going to propose that?
ehm, I can spot people that design by constrain vs. those that design by
symmetry. The second are the one I watch more closely because those are
the one more likely to incurr in FS.
> And teling about my
> idea about how to make the choice of tag language compiler and
> implementation language triggered on each template tag is no idea any
> more, I guess ;)
I should make T-shirts with YAGNI written on the front and on the back
for some of you people ;-)
--
Stefano.
Re: [RT] Attribute Driven Templates
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Stefano Mazzocchi wrote:
> Daniel Fagerstrom wrote:
>
>>> I like this idea very much. It would be a shame if the quirks of
>>> Dreamweaver should force everyone to use an awkward syntax.
>>
>> The attribute driven synatax is new to me so I don't know if I find it
>> awkward or not, I'll need to see some larger examples. Anyway, we have
>> a user community (and our own webbaps) to think about, we cannot
>> change dirrection at every whim. We must support JXTG for the
>> forseable future so I would prefer if we could allow both syntaxes.
>>
>> Now, it will be interesting to see how long time it will take before
>> someone explains that: this is FS we only need to support one syntax,
>> namely the obviously optimal one, and those who believe that they need
>> the other one are generally less knowing and doesn't understand their
>> own best ;)
>
> I know you are looking at me :-) but interestingly enough, my FS alarm
> didn't go off.
Your alarm might have been desensitized by our continuos stream of FS ;)
Actually it would be boring if you were easy to predict.
> I really think that it makes sense to have two different syntaxes, one
> that uses elements and another one that uses attributes.
So do I.
> Now, having them cohexist in the page smells like FS, though ;-)
How did you know that I was going to propose that? And teling about my
idea about how to make the choice of tag language compiler and
implementation language triggered on each template tag is no idea any
more, I guess ;)
/Daniel
Re: [RT] Attribute Driven Templates
Posted by Stefano Mazzocchi <st...@apache.org>.
Daniel Fagerstrom wrote:
>> I like this idea very much. It would be a shame if the quirks of
>> Dreamweaver should force everyone to use an awkward syntax.
>
> The attribute driven synatax is new to me so I don't know if I find it
> awkward or not, I'll need to see some larger examples. Anyway, we have a
> user community (and our own webbaps) to think about, we cannot change
> dirrection at every whim. We must support JXTG for the forseable future
> so I would prefer if we could allow both syntaxes.
>
> Now, it will be interesting to see how long time it will take before
> someone explains that: this is FS we only need to support one syntax,
> namely the obviously optimal one, and those who believe that they need
> the other one are generally less knowing and doesn't understand their
> own best ;)
I know you are looking at me :-) but interestingly enough, my FS alarm
didn't go off.
I really think that it makes sense to have two different syntaxes, one
that uses elements and another one that uses attributes.
Now, having them cohexist in the page smells like FS, though ;-)
--
Stefano.
Re: [RT] Attribute Driven Templates
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Jonas Ekstedt wrote:
> On Sat, 4 Dec 2004, Daniel Fagerstrom wrote:
>
> snip...
>
>>if(<test>)
>>----------
>>
>>example:
>>
>><div do="if(count(cart/item) == 0)">
>> Your cart is empty
>><div>
>>
>
> How would you implement choose/when?
I woudn't, don't think it works that well with Dreamweaver and such
things. You can use a number of if instead. I would also assume that
there is an upper bound on complexity when "fill in the blanks"-style
templating isn't feasible anymore and when it becomes more or less
meaningsless to try to edit it in dreamweaver. In such cases rule based
templates are better.
Anyway, my Dreamweaver experience is quite limited, I used it for
implementing a site design from Illustrator to HTML and CSS. It was fun
for a short while. But I'm not the right kind of person for using
dreamweaver. I'm fanatic in avoiding any style elements in HTML so I do
everything in CSS and DWs CSS support didn't impress me. So after a
while I went back to emacs again :)
Hopefully people that have succeded in using DW to their advantage will
tell whats needed and usefull.
> snip...
>
>>Several directives
>>------------------
>>
>>So, how do we handle multiple directives for one element? We could
>>handle the TAL example above like:
>>
>><p
>>do="let(x=/a/long/path/from/the/root;if(x);content(x/txt);attributes(class=x/class)">
>> Ex Text
>></p>
>
>
> Isn't there a risk that attribute templates become unreadable?
As said above, I don't think they are intended for complicated designs.
I would use XSLT in such cases. My example above was chosen more for
desscribing the mechanism than for being realistic.
Furthermore I forgot a paranthese in a place that was quite bad from a
pedagogical POV. It should have been:
<p
do="let(x=/a/long/path/from/the/root);if(x);content(x/txt);attributes(class=x/class)">
Ex Text
</p>
I find it actually quite readable, but thats probably because I designed
it ;) and also have spend a lot of time with functional programming
languages (e.g. that in Mathematica). You can think of ';' as functional
composition.
> snip...
>
>>Connection to JXTG
>>------------------
>>
>>The directives are almoust defined in such a way that they could be
>>translated to a tag based templating language like:
>>
>>directive(param_1=value_1,...,param_n=value_n)
>>
>><=>
>>
>><jx:directive param_1="value_1" ... param_n="value_n"/>
>>
>>Maybe we could find a attribute directive language that allows for
>>complete correspondance. And make tag or directive syntax selectible and
>>in such way make this effort compatble with JXTG?
>
> I like this idea very much. It would be a shame if the quirks of
> Dreamweaver should force everyone to use an awkward syntax.
The attribute driven synatax is new to me so I don't know if I find it
awkward or not, I'll need to see some larger examples. Anyway, we have a
user community (and our own webbaps) to think about, we cannot change
dirrection at every whim. We must support JXTG for the forseable future
so I would prefer if we could allow both syntaxes.
Now, it will be interesting to see how long time it will take before
someone explains that: this is FS we only need to support one syntax,
namely the obviously optimal one, and those who believe that they need
the other one are generally less knowing and doesn't understand their
own best ;)
/Daniel
Re: [RT] Attribute Driven Templates (Was: [RT] do me a favor, don't
call them taglibs)
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Jonas Ekstedt wrote:
>>Several directives
>>------------------
>>
>>So, how do we handle multiple directives for one element? We could
>>handle the TAL example above like:
>>
>><p
>>do="let(x=/a/long/path/from/the/root;if(x);content(x/txt);attributes(class=x/class)">
>> Ex Text
>></p>
>
>
> Isn't there a risk that attribute templates become unreadable?
That is quite true: the attribute value could become lengthy.
I feel a little bit that the attribute syntax should be a 1:1
alternative for simpler cases to tag syntax. This way the developer is
the one to choose what he pleases.
The tag syntax is: simpler to teach, simpler to understand (it is
similar to a programming language structure). Still the syntax Daniel
proposes is kind of "sexy" and I would surely like to try it out.
--
Leszek Gawron lgawron@mobilebox.pl
Project 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: [RT] Attribute Driven Templates (Was: [RT] do me a favor, don't
call them taglibs)
Posted by Jonas Ekstedt <ek...@ibg.uu.se>.
On Sat, 4 Dec 2004, Daniel Fagerstrom wrote:
snip...
>
> if(<test>)
> ----------
>
> example:
>
> <div do="if(count(cart/item) == 0)">
> Your cart is empty
> <div>
>
How would you implement choose/when?
snip...
>
> Several directives
> ------------------
>
> So, how do we handle multiple directives for one element? We could
> handle the TAL example above like:
>
> <p
> do="let(x=/a/long/path/from/the/root;if(x);content(x/txt);attributes(class=x/class)">
> Ex Text
> </p>
Isn't there a risk that attribute templates become unreadable?
snip...
>
> Connection to JXTG
> ------------------
>
> The directives are almoust defined in such a way that they could be
> translated to a tag based templating language like:
>
> directive(param_1=value_1,...,param_n=value_n)
>
> <=>
>
> <jx:directive param_1="value_1" ... param_n="value_n"/>
>
> Maybe we could find a attribute directive language that allows for
> complete correspondance. And make tag or directive syntax selectible and
> in such way make this effort compatble with JXTG?
I like this idea very much. It would be a shame if the quirks of
Dreamweaver should force everyone to use an awkward syntax.
Cheers Jonas
Re: [RT] Attribute Driven Templates
Posted by Glen Ezkovich <ge...@mac.com>.
On Dec 5, 2004, at 8:04 AM, Leszek Gawron wrote:
> Fine by me. The only concern is the performance here. Macro would have
> to be played, output recorded and after that omitTag invoked. I'd
> rather do it otherwise.
As is usually, my advice is that unless you know what the performance
hit will be in advance, implement, test and if the performance is
unacceptable, profile and only when you know exactly what the cause is,
optimize. Quite often the obvious performance bottleneck, isn't.
Similarly, though the expected bottleneck shows up just where expected,
the performance hit is much milder then expected and performance is
acceptable.
I don't mean to suggest that you don't even think about performance at
this point, just that we concentrate on functionality. If you can show
by past experience that implementing in a certain way will slow things
to a crawl, then by all means, show us and suggest a way around them.
Glen Ezkovich
HardBop Consulting
glen at hard-bop.com
http://www.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] Attribute Driven Templates
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Leszek Gawron wrote:
> Daniel Fagerstrom wrote:
>
>> Leszek Gawron wrote:
>>
>>> Daniel Fagerstrom wrote:
>>>
>>>> Leszek Gawron wrote:
>>
>>
>> <snip/>
>>
>>>>> We also need:
>>>>> - some script compiler directives i.e. for cache control (as in JXTG)
>>>
>>>
>>> > Seem reasonable, sugest some mechanism.
>>>
>>> <ignore do="processingInstruction( 'cache-key', $cacheKey )"/> if we
>>> want the directive to remove element at which it was declare. Or we
>>> could pass processing instructions at page root (or any element) if
>>> the element would stay in the template.
>>
>>
>>
>> Ok.
>> What will the $cacheKey typically be? Can you give an example or a
>> pointer to the docu or discussion about how it work in JXTG?
>
> The whole thread:
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=108604471307300&w=2
>
> Resolution description:
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=108627413529986&w=2
>
And the implementation details, which I forgot to add:
The cache key and cache validity are JXTExpressions that are passed via
<root jx:cache-key="${expr}" jx:cache-validity="${expr2}">
</root>
The expressions are stored in a map attached to the compiled script.
Every time cocoon asks the generator for key or validity an appropriate
expression gets evaluated in current context. The rest is being done by
cocoon core itself.
--
Leszek Gawron lgawron@mobilebox.pl
Project 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: [RT] Attribute Driven Templates
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Daniel Fagerstrom wrote:
> Leszek Gawron wrote:
>
>> Daniel Fagerstrom wrote:
>>
>>> Leszek Gawron wrote:
>
> <snip/>
>
>>>> We also need:
>>>> - some script compiler directives i.e. for cache control (as in JXTG)
>>
>> > Seem reasonable, sugest some mechanism.
>>
>> <ignore do="processingInstruction( 'cache-key', $cacheKey )"/> if we
>> want the directive to remove element at which it was declare. Or we
>> could pass processing instructions at page root (or any element) if
>> the element would stay in the template.
>
>
> Ok.
> What will the $cacheKey typically be? Can you give an example or a
> pointer to the docu or discussion about how it work in JXTG?
The whole thread:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=108604471307300&w=2
Resolution description:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=108627413529986&w=2
--
Leszek Gawron lgawron@mobilebox.pl
Project 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: [RT] Attribute Driven Templates
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Leszek Gawron wrote:
> Daniel Fagerstrom wrote:
>> Leszek Gawron wrote:
<snip/>
>>> We also need:
>>> - some script compiler directives i.e. for cache control (as in JXTG)
> > Seem reasonable, sugest some mechanism.
>
> <ignore do="processingInstruction( 'cache-key', $cacheKey )"/> if we
> want the directive to remove element at which it was declare. Or we
> could pass processing instructions at page root (or any element) if the
> element would stay in the template.
Ok.
What will the $cacheKey typically be? Can you give an example or a
pointer to the docu or discussion about how it work in JXTG?
>> <tr do="macro(singleRowContent,context);omitTag(true)">
>> <td>{context.elem1}</td>
>> <td>{context.elem2}</td>
>> </tr>
>
> Fine by me. The only concern is the performance here. Macro would have
> to be played, output recorded and after that omitTag invoked. I'd rather
> do it otherwise.
There will not be any performance problems, the work can be done at
script compile time AFAICS.
/Daniel
Re: [RT] Attribute Driven Templates
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Daniel Fagerstrom wrote:
> Leszek Gawron wrote:
>
>> Daniel Fagerstrom wrote:
>>
>>> macro(<name>,<param-name>,...,<param-name>)
>>> -------------------------------------------
>>>
>>> example:
>>>
>>> <table do="macro(mytable,list,td-class)">
>>> <tr do="forEach($list)">
>>> <td class="${$class}">${item}</td>
>>> </tr>
>>> </table>
>>>
>>> We also need an evalBody as in JXTG. And maybe we should have a
>>> possibilty to give a name space to the macro name.
>>
>>
>> We also need:
>> - some script compiler directives i.e. for cache control (as in JXTG)
>
> Seem reasonable, sugest some mechanism.
<ignore do="processingInstruction( 'cache-key', $cacheKey )"/> if we
want the directive to remove element at which it was declare. Or we
could pass processing instructions at page root (or any element) if the
element would stay in the template.
> <tr do="macro(singleRowContent,context);omitTag(true)">
> <td>{context.elem1}</td>
> <td>{context.elem2}</td>
> </tr>
Fine by me. The only concern is the performance here. Macro would have
to be played, output recorded and after that omitTag invoked. I'd rather
do it otherwise.
--
Leszek Gawron lgawron@mobilebox.pl
Project 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: [RT] Attribute Driven Templates
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Leszek Gawron wrote:
> Daniel Fagerstrom wrote:
>
>> macro(<name>,<param-name>,...,<param-name>)
>> -------------------------------------------
>>
>> example:
>>
>> <table do="macro(mytable,list,td-class)">
>> <tr do="forEach($list)">
>> <td class="${$class}">${item}</td>
>> </tr>
>> </table>
>>
>> We also need an evalBody as in JXTG. And maybe we should have a
>> possibilty to give a name space to the macro name.
>
> We also need:
> - some script compiler directives i.e. for cache control (as in JXTG)
Seem reasonable, sugest some mechanism.
> - template inclusion so the templates may be defined in a separate file
Absolutely.
> Named macros rock! This way we can completely eliminate the need for
> this hack:
> http://cocoon.apache.org/2.1/userdocs/flow/jxtemplate.html#eval
>
> Imagine that user wants to render a fancy table providing only a header
> rendering macro and a row template:
>
> <tr do="macro(tableHeader,context)">
> <th>Elem1</th>
> <th>Elem2</th>
> </tr>
>
> <tr do="macro(singleRow,context)">
> <td>{context.elem1}</td>
> <td>{context.elem2}</td>
> </tr>
>
> <table do="macro(mytable,list,headerMacro,rowMacro)">
> <!-- some fancy longish code here -->
> <tr>
> <th>No.</th>
> <th do="eval($headerMacro)"/>
> </tr>
> <tr do="forEach($list)">
> <td>${index}</td>
> <td do="eval($rowMacro,context=.)"/><!-- problem here -->
> </tr>
> </table>
>
> Lovely!
>
> Still I see one problem: as every directive is bound to some tag one
> should be able to eval the macro and strip the root element. In my case
> the output would look like this:
>
> <tr>
> <th>No.</th>
> <tr>
> <th>Elem1</th>
> <th>Elem2</th>
> </tr>
> </tr>
>
> This would fix it: <th do="eval($headerMacro,stripRoot=true)"/>
>
> If we used tags we would be able to introduce <jx:template> as in jxtg
> that would not show up in the output. Here we have no such possibility.
TAL has an omit-tag(<test>) directive that takes away the surrounding
tag if <test> is true, it always keeps the content.
It would solve both cases.
The macro would be:
<tr do="macro(singleRowContent,context);omitTag(true)">
<td>{context.elem1}</td>
<td>{context.elem2}</td>
</tr>
One could also have something like:
<th do="xpath(tr/*);eval($headerMacro)"/>
Or some more specialized childs() directive, but I think it starts to
get to complicated if we add such things.
>> Several directives
>> ------------------
>>
>> So, how do we handle multiple directives for one element? We could
>> handle the TAL example above like:
>>
>> <p
>> do="let(x=/a/long/path/from/the/root;if(x);content(x/txt);attributes(class=x/class)">
>
>
> IMO this one is not that clear as the same syntax using tags.
Agree, but most uses will not get this complex but if they will I think
tags or using XSLT is better.
> This will
> be also a lot harder to implement as we will have to create much more
> sophisticated parser. With tags, the xml syntax does 95% of parsing
> itself with only a little amount of additional coding.
If we keep it as simple as directive(par[=expr],...,par[=expr]);..., it
will not be that complicated to parse, and we only need to write the
parser once. The complicated thing is to parse the expre, and the
expression library take care of that. Don't worry ;)
<snip/>
> I am only afraid how I will explain the directive ordering to my
> developers. Moreover: how many mistakes they will make, which IMO will
> be much harder to trace comparing to old verbose syntax.
Start by showing examples with single directives, that covers most
cases. The show some simple combinations of two directives ;) Honestly,
I don't know some larger examples are needed. Maybe it will be clearer
with some other composition charachter than ";".
/Daniel
Re: [RT] Attribute Driven Templates (Was: [RT] do me a favor, don't
call them taglibs)
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Daniel Fagerstrom wrote:
> macro(<name>,<param-name>,...,<param-name>)
> -------------------------------------------
>
> example:
>
> <table do="macro(mytable,list,td-class)">
> <tr do="forEach($list)">
> <td class="${$class}">${item}</td>
> </tr>
> </table>
>
> We also need an evalBody as in JXTG. And maybe we should have a
> possibilty to give a name space to the macro name.
We also need:
- some script compiler directives i.e. for cache control (as in JXTG)
- template inclusion so the templates may be defined in a separate file
Named macros rock! This way we can completely eliminate the need for
this hack:
http://cocoon.apache.org/2.1/userdocs/flow/jxtemplate.html#eval
Imagine that user wants to render a fancy table providing only a header
rendering macro and a row template:
<tr do="macro(tableHeader,context)">
<th>Elem1</th>
<th>Elem2</th>
</tr>
<tr do="macro(singleRow,context)">
<td>{context.elem1}</td>
<td>{context.elem2}</td>
</tr>
<table do="macro(mytable,list,headerMacro,rowMacro)">
<!-- some fancy longish code here -->
<tr>
<th>No.</th>
<th do="eval($headerMacro)"/>
</tr>
<tr do="forEach($list)">
<td>${index}</td>
<td do="eval($rowMacro,context=.)"/><!-- problem here -->
</tr>
</table>
Lovely!
Still I see one problem: as every directive is bound to some tag one
should be able to eval the macro and strip the root element. In my case
the output would look like this:
<tr>
<th>No.</th>
<tr>
<th>Elem1</th>
<th>Elem2</th>
</tr>
</tr>
This would fix it: <th do="eval($headerMacro,stripRoot=true)"/>
If we used tags we would be able to introduce <jx:template> as in jxtg
that would not show up in the output. Here we have no such possibility.
> Several directives
> ------------------
>
> So, how do we handle multiple directives for one element? We could
> handle the TAL example above like:
>
> <p
> do="let(x=/a/long/path/from/the/root;if(x);content(x/txt);attributes(class=x/class)">
IMO this one is not that clear as the same syntax using tags. This will
be also a lot harder to implement as we will have to create much more
sophisticated parser. With tags, the xml syntax does 95% of parsing
itself with only a little amount of additional coding.
> <jx:let name="x" value="/a/long/path/from/the/root">
> <jx:if test="x">
> <jx:content select="x/txt">
> <jx:attribute name="class" value="x/class">
> <p>Ex Text</p>
> </jx:attribute>
> </jx:content>
> </jx:if>
> <jx:let>
What hits me is how the attribute based syntax can be compact comparing
to this monster :)
> Formating?
> ----------
>
> IMO most of the basic formating can be done in a special conversion
> layer as we have discussed in the convertor thread.
I understand this is completely orthogonal functionality to the one you
described.
> I have not given any detailed thought to all of the constructions above,
> just wanted to concretize what attribute driven templating could look
> like in Cocoon.
>
> WDYT?
I am only afraid how I will explain the directive ordering to my
developers. Moreover: how many mistakes they will make, which IMO will
be much harder to trace comparing to old verbose syntax.
--
Leszek Gawron lgawron@mobilebox.pl
Project 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: [RT] Attribute Driven Templates (Was: [RT] do me a favor, don't
call them taglibs)
Posted by "Roy G. Biv" <mi...@pcextremist.com>.
Roy G. Biv wrote:
> 2. Namespaced tag or attribute: may not be compatible with Dreamweaver
> (strikes me as a serious limitation that needs to be addressed by the
> Dreamweaver developers IMHO), but can guarantee well-formedness.
Nevermind. Forget I said this. Dreamweaver supports namespaced attributes.
- Miles Elam
Re: [RT] Attribute Driven Templates (Was: [RT] do me a favor, don't
call them taglibs)
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Roy G. Biv wrote:
> Any prohibition on (non-HTML) namespaced tags would imply to me that
> arbitrary namespaced attributes would be a no-no in Dreamweaver as
> well. Stefano, as I haven't ever used Dreamweaver for more than ten
> minutes, is this limitation a rendering issue or data entry issue? I
> question the position though. Taking two obvious possibilites:
>
> 1. Velocity syntax: just plugs in in the best-case scenario as text but
> suffers from the danger of having the text "#foreach" wrapped in a tag
> by the editor. Well-formedness is not guaranteed. (I think. Correct
> em if I'm wrong.)
There are more side effects with Velocity, FreeMarker and similar: as
they generate text they also introduce problems with encoding manipulation.
>> Expressions are the "${expr}" stuff in e.g. JXTG and should be use
>> able both in text in attributes and element content. Do we need the
>> "$"? Couldn't we just use "{expr}" as in XSLT?
>
>
> I'm glad someone else said this. I totally agree. If I understand
> correctly, the reason behind the '$' character was to differentiate
> JXPath and JEXL expressions. Since the current thought is that we'll
> standardize the lookup syntax, why the extra character. It can be said
> that people are used to JXTG, but far more people are used to XSLT-style
> attribute value substitution.
I think we did not agree on standarized lookup syntax. On the contrary:
some of us want to use Jexl-like syntax (when working with beans), some
want to use XPath(working with pure xml).
It's sometimes problematic to use XPath on beans (I had problems with
comparing values and issues with types). It's completely unnatural to
use Jexl syntax on xml data.
We rather agreed that we need ELs to be pluggable.
--
Leszek Gawron lgawron@mobilebox.pl
Project 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: [RT] Attribute Driven Templates
Posted by Glen Ezkovich <ge...@mac.com>.
On Dec 4, 2004, at 11:40 PM, Stefano Mazzocchi wrote:
> Daniel Fagerstrom wrote:
>
>> Stefano's focus seem to be on HTML.
>
> For the record: my focus is on having a template language for cocoon
> that is as powerful as XSP but avoids all the problems.
Then it won't be as powerful ;-) The power is not needed. We have flow
now.
Glen Ezkovich
HardBop Consulting
glen at hard-bop.com
http://www.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] Attribute Driven Templates
Posted by Stefano Mazzocchi <st...@apache.org>.
Roy G. Biv wrote:
> Stefano Mazzocchi wrote:
>
>> For the record: my focus is on having a template language for cocoon
>> that is as powerful as XSP but avoids all the problems.
>
>
> Is that realistic? I can see logicsheets, but XSP was arbitrary Java
> code. I find it hard to believe that *anything* will be as
> powerful/flexible as that.
Sorry, I should have said "template system". That means the sum of the
controller (the script that pupulates the data) + the view (the template
that lays it out)
--
Stefano.
Re: [RT] Attribute Driven Templates
Posted by "Roy G. Biv" <mi...@pcextremist.com>.
Stefano Mazzocchi wrote:
> For the record: my focus is on having a template language for cocoon
> that is as powerful as XSP but avoids all the problems.
Is that realistic? I can see logicsheets, but XSP was arbitrary Java
code. I find it hard to believe that *anything* will be as
powerful/flexible as that.
> Dealing with strict constrains is also a very good exercise of design
> because it forces you to think rather than just work by symmetry.
Indeed. My constraint has been a Simplified DocBook variant which I
find to be a much stronger data model than XHTML, but that doesn't make
me right.
For example:
http://geekspeak.org/articles/12/article.xml
and the page it produces
http://geekspeak.org/articles/12/
Just trying to find the cleanest, most maintainable way there.
- Miles Elam
Re: [RT] Attribute Driven Templates
Posted by Stefano Mazzocchi <st...@apache.org>.
Daniel Fagerstrom wrote:
> Stefano's focus seem to be on HTML.
For the record: my focus is on having a template language for cocoon
that is as powerful as XSP but avoids all the problems.
Also, I think that XHTML markup offers the best possible usecase of how
that template language should work.
Also, I think that being friendly to existing authoring tools is not
only a plus but a very interesting usecase that makes us think about the
hows and whys on the syntaxes and models that we use.
for example, Daniel proposed numbered-attributes to solve the problem of
loop nesting. Well, I think that's a problem we don't have, because it's
very unlikely that somebody will nest loops without nesting elements!
Dealing with strict constrains is also a very good exercise of design
because it forces you to think rather than just work by symmetry.
--
Stefano.
Re: [RT] Attribute Driven Templates
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Roy G. Biv wrote:
> Daniel Fagerstrom wrote:
<snip/>
> I as well. In addition, I think that the optimum template language
> would be as close to the appearance of the output document as possible.
> (Yet another reason I don't personally care for explicit forEach, if and
> chose elements; they make it harder to see at a glance how it will look
> after processing.)
Tend to agree, I use XSLT (2.0) for all kind of things, and am happy
whith many aspects of it, but sometimes it is a little bit of "write
only", i.e. it easy to expres things in it (once you get used), but it's
verbosity can hide the message, when you try to understand your or
others code.
<snip/>
> I'm a big fan of namespacing the attribute for reasons of versioning as
> well as clearly marking which directives belong to which processor --
> both for the processor and for the template author.
Agree, no idea why Tapestry don't use name space for marking directives.
>> A problem with "attribute name as directive" is that xml attributes
>> are unordered. So in the case you need e.g. a double loop over an
>> element, test if you want to perform a loop or do a loop and test each
>> element, a mechanism for deciding the order is needed. TAL uses a
>> predetermined order for the directives. That is far to implicit for my
>> taste and it doesn't solve the double loop. I would prefer to do
>> something more explicit like:
>>
>> <p tal:define-1="x /a/long/path/from/the/root"
>> tal:condition-2="x"
>> tal:content-3="x/txt"
>> tal:attributes-4="class x/class">Ex Text</p>
>
>
> Sounds good on paper, sounds like a royal PITA in practice. Determining
> whether attribute A should be set before the first condition but after
> the second condition which determines the content... Complexity can
> rise dramatically and quickly with this. I'd say the template should
> lose the ability to do a small set of corner cases if, 95% of the time,
> the simpler syntax has noticeably lower complexity.
Might be, I have not used TAL. When I read about the default ordering I
thought that in most cases I will only use one directive, so in the
cases where I use several I will need to check the manual anyway. As I
want to avoid "to much magic" being explicit seemed better. But maybe
the default order is so natural so that you learn it at once?
> I think the desire for this comes from the desire to make HTML-oriented
> templates from the template directives. Is this correct and is this the
> correct focus?
Stefano's focus seem to be on HTML. My focus is lost long time ago ;)
Designing a attribute driven template language seemed like a fun thing
to do.
Is it the correct focus? If we find an efficient and easy to understand
way of writing HTML templates, it will work well for numerous other XML
formats that have similar structure, so it should be important enough. I
don't know if the concept of "correct focus" is that relevant in open
source development. Things will be done by people who have a itch to
scratch, if it seem fun and interesting enough, if it gets enough
attention, if influencial people says that it is important and by
numerous other reasons.
> If the template language is focused on producing
> semantic XML -- where the XML reflects the structure of the problem at
> hand and not its presentational form -- simpler syntaxes are much more
> useful. As is the case with Plone, the focus on HTML output mandates
> more complex processing options than is otherwise necessary.
I think that having complicated processing options only is a problem if
they make simple things complicated. As long as you can resist spending
to much time talking about complicated corner cases when you teach the
technology, it will work well even for those who are less comfortable
with complicated constructs.
> If HTML output is a primary design concern and HTML templates are made
> so much easier/possible, will anyone on a deadline keep SoC firmly in
> their heads?
Do they now?
IMO HTML already gives you god SoC in many cases. As long as you write
for modern browsers, HTML is an excelent language for describing content
in a rather wide area. Then you put all styling in CSS.
In more complex use cases or when you have regularity along dimensions
that not is covered by the HTML-template/CSS solution, a solution with
more layers might be better. But it all depends on the task, excecive
layering for simple tasks is IMO an anti pattern.
> Once this happens, what advantage does Cocoon have over
> JSP w/ taglibs? I'm honestly curious.
Cocoon had the advantage that you can put all your side effects in the
flow layer, and let the pipeline be completely declarative. Which
reduces complexity and make things easier to test and understand. You
can in a simple way choose how in how many step you will handle your
output based on the SoC you find best for the problem at hand. Also you
will get standard components for everything that people find important
enough to invest time in it.
> If HTML-oriented templates are
> the norm, and the pipelines would consist of the successor to JXTG and
> an HTML serializer, what's the point? I don't mean to invoke a
> slippery-slope fallacy as I think this is a real possibility.
I just can't see this as a problem, If people can solve simple things in
a simple way, isn't that much better.
In my webapps I use short pipelines for some stuff and long for other,
it all depends on what problem decomposition I found reasonable and
wortwhile.
I doubt that the people who constructed pipelines in UNIX consider it a
failure that UNIX have so many well designed commands for simple tasks,
that most of the time the commands are executed without being in a pipeline.
> When the XML and the logical data structure are intimately related,
> things tend to fall into place with a minimum of decision making. Then
> transform. Then serialize.
In many cases yes, in many other cases no ;)
<snip/>
> So much for avoiding the complexity of a general programming language.
> Simpler may leave fewer options, but that's not always a bad thing. If
> all options need to be handled, you're looking back at XSP, the ultimate
> in this area.
It doesn't have side effects and it have quite limited access to data in
Cocoon, thats important differences.
>> Several directives
>> ------------------
>>
>> So, how do we handle multiple directives for one element? We could
>> handle the TAL example above like:
>>
>> <p
>> do="let(x=/a/long/path/from/the/root;if(x);content(x/txt);attributes(class=x/class)">
>>
>> Ex Text
>> </p>
>
>
> Yeah, that's what I thought. I pity the template writer that much
> content with someone else's templates.
No one forces you to use it, it will not hurt you as long as you don't
use it, as the syntax is simple for simple cases. The example was taken
from the TAL manual for illustrating a mechanism, not for being a
realistic example.
> I still think macros should be handled in transformations rather than
> Java code, but there it is.
Macros are written in the template language it self, no need for Java or
a foreign transformation language. Basic directives like if are written
in Java.
/Daniel
Re: [RT] Attribute Driven Templates (Was: [RT] do me a favor, don't
call them taglibs)
Posted by "Roy G. Biv" <mi...@pcextremist.com>.
Daniel Fagerstrom wrote:
> Stefano Mazzocchi wrote:
>
>> All I ask from a template language:
>>
>> 1) something that HTML designers can edit with Dreamweaver
>> 2) something that doesn't use namespaced tags to identify dynamic
>> scopes (clashes with #1)
>> 3) something that doesn't use the name taglib
>>
>> That's pretty much all you have to do to make me happy.
>
>
> Dreamweaver friendly means basically that it should be attribute
> driven I guess?
Any prohibition on (non-HTML) namespaced tags would imply to me that
arbitrary namespaced attributes would be a no-no in Dreamweaver as
well. Stefano, as I haven't ever used Dreamweaver for more than ten
minutes, is this limitation a rendering issue or data entry issue? I
question the position though. Taking two obvious possibilites:
1. Velocity syntax: just plugs in in the best-case scenario as text but
suffers from the danger of having the text "#foreach" wrapped in a tag
by the editor. Well-formedness is not guaranteed. (I think. Correct
em if I'm wrong.)
2. Namespaced tag or attribute: may not be compatible with Dreamweaver
(strikes me as a serious limitation that needs to be addressed by the
Dreamweaver developers IMHO), but can guarantee well-formedness.
I don't think any solution will be perfect. The best we can hope for is
straightforward workarounds.
> I'll give some background info and then I'll show how an attribute
> driven template language for Cocoon could look. The discussion is
> based on TAL http://www.zope.org/Wikis/DevSite/Projects/ZPT/TAL,
> Tapestry http://jakarta.apache.org/tapestry/ and some of the
> functionallity in JXTG.
Lucky me, I just made my first site with Plone a couple of months ago.
> We need two kinds of constructions: expressions and directives.
>
> Expressions
> ===========
>
> Expressions are the "${expr}" stuff in e.g. JXTG and should be use
> able both in text in attributes and element content. Do we need the
> "$"? Couldn't we just use "{expr}" as in XSLT?
I'm glad someone else said this. I totally agree. If I understand
correctly, the reason behind the '$' character was to differentiate
JXPath and JEXL expressions. Since the current thought is that we'll
standardize the lookup syntax, why the extra character. It can be said
that people are used to JXTG, but far more people are used to XSLT-style
attribute value substitution.
Also bear in mind that JXTemplateGenerator is already written and code
complete. Any new syntactic sugar would presumably be in a different
sitemap component (even if it were abusively named
org.apache.cocoon.transformation.JXTemplateGeneratorV2). Everyone used
to the old syntax just uses the old JXTG implementation in their sitemap
declarations (I love Cocoon's design for this by the way).
> IIUC TAL doen't use embeded expressions but instead replace element
> and attribute content with replace directives (in attributes). It
> might make it even more Dreamweaver friendly as you can look at
> example content instead of expressions in your design window. But it
> makes template writing much harder IMO. We could have such replacement
> directives if people want it but, I would prefer having embeded
> expresions as well.
I as well. In addition, I think that the optimum template language
would be as close to the appearance of the output document as possible.
(Yet another reason I don't personally care for explicit forEach, if and
chose elements; they make it harder to see at a glance how it will look
after processing.)
> Directives
> ==========
>
> TAL uses one name spaced attribute for each directive, e.g.:
>
> <p tal:condition="here/copyright"
> tal:content="here/copyright">(c) 2000</p>
Other than the fact that I would have rathered the attribute were
tal:test instead of tal:condition for brevity's sake, this syntax had
proven to be extremely powerful and easy to understand in my experience.
> Tapestry instead uses only one attribute, "jwcid", with the directive
> name as content.
>
> <tr jwcid="loop">
> <td><span jwcid="insertFirstName">John</span></td>
> <td><span jwcid="insertLastName">Doe</span></td>
> </tr>
I'm a big fan of namespacing the attribute for reasons of versioning as
well as clearly marking which directives belong to which processor --
both for the processor and for the template author.
.
> A problem with "attribute name as directive" is that xml attributes
> are unordered. So in the case you need e.g. a double loop over an
> element, test if you want to perform a loop or do a loop and test each
> element, a mechanism for deciding the order is needed. TAL uses a
> predetermined order for the directives. That is far to implicit for my
> taste and it doesn't solve the double loop. I would prefer to do
> something more explicit like:
>
> <p tal:define-1="x /a/long/path/from/the/root"
> tal:condition-2="x"
> tal:content-3="x/txt"
> tal:attributes-4="class x/class">Ex Text</p>
Sounds good on paper, sounds like a royal PITA in practice. Determining
whether attribute A should be set before the first condition but after
the second condition which determines the content... Complexity can
rise dramatically and quickly with this. I'd say the template should
lose the ability to do a small set of corner cases if, 95% of the time,
the simpler syntax has noticeably lower complexity.
I think the desire for this comes from the desire to make HTML-oriented
templates from the template directives. Is this correct and is this the
correct focus? If the template language is focused on producing
semantic XML -- where the XML reflects the structure of the problem at
hand and not its presentational form -- simpler syntaxes are much more
useful. As is the case with Plone, the focus on HTML output mandates
more complex processing options than is otherwise necessary.
If HTML output is a primary design concern and HTML templates are made
so much easier/possible, will anyone on a deadline keep SoC firmly in
their heads? Once this happens, what advantage does Cocoon have over
JSP w/ taglibs? I'm honestly curious. If HTML-oriented templates are
the norm, and the pipelines would consist of the successor to JXTG and
an HTML serializer, what's the point? I don't mean to invoke a
slippery-slope fallacy as I think this is a real possibility.
When the XML and the logical data structure are intimately related,
things tend to fall into place with a minimum of decision making. Then
transform. Then serialize.
> NIH
> ===
>
> First some motivation about why I don't think that TAL or Tapestry
> templates are good alternatives for using as is in Cocoon (besides
> that its much more fun to implement them ourselves ;) ). AFAIU both
> TAL and Tapestries directives are very closely connected to the both
> frameworks respective component models. We need something that works
> with our world view. Furthermore TAL is develped by the Zope community
> so everything is in Phyton style, and at that feels less natural, at
> least for me.
Yes, the TAL processor doesn't even enforce well-formedness. It's a
pattern matching replacement syntax that would require some reworking of
assumptions in order to work with Cocoon. It also takes away the
ability to easily drop a ${value} directive in your attributes and
content areas, thereby increasing the directive-to-normal markup ratio
which I care about so much.
> A Proposal
> ==========
>
> Based on the previous I propse that the attribute driven template
> language should be invoked like:
>
> <element do="<directive>" attr1="...">
> <content>...</content>
> </element>
>
> The idea is that the attribute "do" triger the execution of the
> directive. "do" is just an example we could make the trigger attribute
> configurable and/or namespaced so that it doesn't colide with your
> "host" XML language.
Interesting, but it worries me. It helps with the attribute ordering
issue, but starts to feel a little too much like a formal programming
language to me. Today, the syntax handles conditionals, data
replacement, etc. As time goes on, the desire to add new directives (or
God forbid, arbitrary pluggable processing directives) will come.
Namespace URI versioning would be very important here. I'm more
inclined to simply back up and say, "Conditionals get processed first,
then looping, then content replacement," and be done with it. As I said
before, I think more flexible "do" constructs just lend themselves to
easier handling of complex HTML output-oriented templates. Once again,
I'm uneasy with this is direction.
> example:
>
> <div do="if(count(cart/item) == 0)">
> Your cart is empty
> <div>
<snip what="forEach, for, context, let, macro, eval, content, replace"/>
And would these be chained?
<table>
<tr do="if(count(cart/item) == 0); forEach(cart/item)">
<td>${index}</td>
<td>${description}</td>
<td>${price}</td>
</tr>
</table>
So much for avoiding the complexity of a general programming language.
Simpler may leave fewer options, but that's not always a bad thing. If
all options need to be handled, you're looking back at XSP, the ultimate
in this area.
> Several directives
> ------------------
>
> So, how do we handle multiple directives for one element? We could
> handle the TAL example above like:
>
> <p
> do="let(x=/a/long/path/from/the/root;if(x);content(x/txt);attributes(class=x/class)">
>
> Ex Text
> </p>
Yeah, that's what I thought. I pity the template writer that much
content with someone else's templates.
> Connection to JXTG
> ------------------
>
> The directives are almoust defined in such a way that they could be
> translated to a tag based templating language like:
>
> directive(param_1=value_1,...,param_n=value_n)
>
> <=>
>
> <jx:directive param_1="value_1" ... param_n="value_n"/>
>
> Maybe we could find a attribute directive language that allows for
> complete correspondance. And make tag or directive syntax selectible
> and in such way make this effort compatble with JXTG?
We're talking about a radically different syntax. Shouldn't we refer to
it with another name even if that name is temporary and trite? From
where these discussions are headed, JXTG is frozen in time. If the
syntax is changed radically, backward compatibility is out the window.
JX2?
JX-ng?
CTemplates
XTemplates
FlowTemplates
Eugene
Whatever
That or there are substantial redundancies in the code. A Perl-like
"there are at least two ways of doing everything." If that's what
people here want, so be it. Not worth starting a fight over.
> Externaly defined directives?
> -----------------------------
>
> If we chose to allow extenally defined directives they probably should
> be given own namespaces to avoid clashes.
Absolutely agree! Different problem scopes warrant different identifiers.
> Formating?
> ----------
>
> IMO most of the basic formating can be done in a special conversion
> layer as we have discussed in the convertor thread.
Agreed.
I still think macros should be handled in transformations rather than
Java code, but there it is.
- Miles Elam