Re: [RT] Attribute Driven Templates
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
Re: [RT] Attribute Driven Templates (Was: [RT] do me a favor, don't call them taglibs)
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 [EMAIL PROTECTED] Project ManagerMobileBox 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
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
Re: [RT] Attribute Driven Templates
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
Re: [RT] Attribute Driven Templates
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-devm=108604471307300w=2 Resolution description: http://marc.theaimsgroup.com/?l=xml-cocoon-devm=108627413529986w=2 -- Leszek Gawron [EMAIL PROTECTED] Project ManagerMobileBox 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
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-devm=108604471307300w=2
Resolution description:
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=108627413529986w=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 [EMAIL PROTECTED]
Project ManagerMobileBox 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
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...
Bertrand Delacretaz:
Interesting - do you envision using XSLT for this conversion?
Or doing
it in java code?
At NZETC we have used a similar system to what Sylvain describes: We use XSLT
to convert attribute-driven HTML to XSLT. The XSLT is attached (3.5kb).
It performs text substitution both in attribute values e.g. p
class={foo/bar} and also in the text content e.g. pBlah blah: {foo/bar}/p
It supports attributes for-each, if, apply-templates, and copy-of. e.g. li
nzetc:for-each=foo/bar{.}/li
Obviously the same thing could be easily done with JXT as the target language
rather than XSLT. To my mind, this could be a good thing: the JXT 2 language
could have a single (element-driven) syntax for everything, and we could use
XSLT to convert from this attribute-driven syntax, or indeed from any other
attribute-driven syntax that people wanted, if they felt a need for another
attribute (is that FS?)
Cheers
Con
html-to-xslt.xsl
Description: html-to-xslt.xsl
Re: [RT] Attribute Driven Templates (Was: [RT] do me a favor, don't call them taglibs)
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
pEx 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
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
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 [EMAIL PROTECTED] Project ManagerMobileBox 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)
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 [EMAIL PROTECTED]
Project ManagerMobileBox 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
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
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 [EMAIL PROTECTED] Project ManagerMobileBox 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
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
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 [EMAIL PROTECTED]
Project ManagerMobileBox 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
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
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
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
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
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
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
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
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 (Was: [RT] do me a favor, don't call them taglibs)
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 (Was: [RT] do me a favor, don't call them taglibs)
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)
thElem1/th
thElem2/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
thNo./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
thNo./th
tr
thElem1/th
thElem2/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
pEx 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 [EMAIL PROTECTED]
Project ManagerMobileBox 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)
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 [EMAIL PROTECTED] Project ManagerMobileBox 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
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)
thElem1/th
thElem2/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
thNo./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
thNo./th
tr
thElem1/th
thElem2/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)
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
tdspan jwcid=insertFirstNameJohn/span/td
tdspan jwcid=insertLastNameDoe/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/classEx 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...
Re: [RT] Attribute Driven Templates (Was: [RT] do me a favor, don't call them taglibs)
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
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/classEx 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
Re: [RT] Attribute Driven Templates
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
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
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
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
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
