You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Stefano Mazzocchi <st...@apache.org> on 2004/12/03 21:50:30 UTC
[RT] do me a favor, don't call them taglibs
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.
--
Stefano.
Re: [RT] do me a favor, don't call them taglibs
Posted by Davanum Srinivas <da...@gmail.com>.
What's the closest equivalent to what you have in mind :)
-- dims
On Fri, 03 Dec 2004 15:50:30 -0500, Stefano Mazzocchi
<st...@apache.org> 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.
>
> --
> Stefano.
>
>
--
Davanum Srinivas - http://webservices.apache.org/~dims/
Re: [RT] do me a favor, don't call them taglibs
Posted by Ugo Cei <ug...@apache.org>.
Il giorno 03/dic/04, alle 21:50, Stefano Mazzocchi ha scritto:
> 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
Something like Tapestry?
Ugo
--
Ugo Cei - http://beblogging.com/
Re: [RT] do me a favor, don't call them taglibs (Please describe DreamWeaver)
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Sunday 05 December 2004 02:00, Tim Larson wrote:
> Perhaps I am not the only person on this list that has never
> used DreamWeaver...
DreamWeaver is loved by many page designers as it manages the various
resources and on-page placements "well" (seen from the eye of the designer).
The concept is basically like this;
Let the page designer use whatever tool he want, to create a rough mock-up of
the page with just placeholders for the dynamic data.
Give those to the web developer, and he inserts the hidden attributes required
to make the dynamic part work. Then the page designer can continue to refine
the design in his favourite tool, for instance DreamWeaver, while the
programming effort continues in parallel.
I don't think DreamWeaver is any better or any worse than other tools
regarding "unknown" elements. AFAIU, you can have special tags in the HTML
and DW will preserve them, but they will show up as ugly icons, disrupting
the overall look. <span> and <div> elements is containing the mock-data
within them, which will display as expected, and just be 'dynamic' in the
live case.
We occasionally use Tapestry for this type of work flow and it works pretty
well. For one thing, it is just about impossible to get the artist to learn
XSLT, HTML and CSS... let people do what they are good at.
Cheers
Niclas
--
+------//-------------------+
/ http://www.dpml.net /
/ http://niclas.hedhman.org /
+------//-------------------+
Re: [RT] do me a favor, don't call them taglibs (Please describe
DreamWeaver)
Posted by Stefano Mazzocchi <st...@apache.org>.
Tim Larson wrote:
> On Sat, Dec 04, 2004 at 09:37:10AM +0100, Bertrand Delacretaz wrote:
>
>>For b), being dreamweaver-compatible would be a big plus, allowing less
>>technical people to create templates themselves. Using Dreamweaver or
>>not, that's not the point: DW-compatibility also means that the
>>templating system is "simple enough" for such people to grasp.
>
>
> Perhaps I am not the only person on this list that has never
> used DreamWeaver...
I've tried it once and I found my text editors to be way more
productive. And power web designers use text editors too (or DW source
mode), but that's a minority.
> would anybody care to list or describe the
> how's and why's of its benefits and limitations?
>
> For context, all I have managed to glean so far from this
> discussion is a vague idea that visual people like it,
What's critical in the discussion is that XSLT is not the right tool for
content presentation. There are many exceptions but XSLT is a
programming language with a markup syntax, it looks friendly at first
and its template declarativity is easy to understand for HTML designers
because of CSS selectors, but it's extremely verbose and, most of all,
it's not supported by visual HTML tools (or, it if is, in a very poor way).
What I want is to be able to have HTML people design the template of the
page in the simplest possible way for them.
> that it does not work well with namespaced tags
One of the problems with any WYSIWYG editors is how to select things
that don't have a visual representation. Because if you add a visual
representation to them, it's not WYSIWIG anymore, if you keep them
hidden, it's easy to screw them (either write inline or to remove them)
without noticing.
> and that it does
> seem to work ok with custom attributes.
attributes don't have a visual representation themselves, but they are
always glued to the markup, so they move with them. DW is smart enough
to allow namespaced attributes and work on the elements without
disturbing those attributes.
Basically, they are like attached labels that you move on with your code.
The designers love this, because all they have to understand to start
working on this is "don't touch the attributes which name starts with xxx:"
Let on, they will understand, by try/fail, what these attribute means
and pretty soon they master the whole template language, allowing the
programmers to work away from their templates.
> Not having ever used it, I do not know why visual designers
> like it, why it does not like namespaced tags, etc. Could
> somebody knowledgeable on the topic expand on the description?
DW is as smart with namespaced elements as it is with namespaced
attributes, the problem is that the workflow of a web designer is a
continous try/fail of new things and moving things around.
In the process of cut/paste/delete, if done on the WYSIWYG canvas, it's
almost impossible to guarantee that those invisible namespaced elements
will remain there after you have moved them around.
Attributes carry their own problems (as Daniel explained very well in
the other email) but way safer.
--
Stefano.
Re: [RT] do me a favor, don't call them taglibs (Please describe DreamWeaver)
Posted by Tim Larson <ti...@keow.org>.
On Sat, Dec 04, 2004 at 09:37:10AM +0100, Bertrand Delacretaz wrote:
> For b), being dreamweaver-compatible would be a big plus, allowing less
> technical people to create templates themselves. Using Dreamweaver or
> not, that's not the point: DW-compatibility also means that the
> templating system is "simple enough" for such people to grasp.
Perhaps I am not the only person on this list that has never
used DreamWeaver...would anybody care to list or describe the
how's and why's of its benefits and limitations?
For context, all I have managed to glean so far from this
discussion is a vague idea that visual people like it, that
it does not work well with namespaced tags, and that it does
seem to work ok with custom attributes.
Not having ever used it, I do not know why visual designers
like it, why it does not like namespaced tags, etc. Could
somebody knowledgeable on the topic expand on the description?
--Tim Larson
Re: [RT] do me a favor, don't call them taglibs (TAL-like two-step templating?)
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 4 déc. 04, à 18:56, Stefano Mazzocchi a écrit :
> Bertrand Delacretaz wrote:
>> ...I think we need
>> a) "data templates" (for a lack of a better word), to generate XML
>> out of data (what JXTG does now),
>> and
>> b) "presentation templates" downstream to convert the XML to HTML or
>> other presentation markup (currently covered by XSLT, far from ideal)
>
> I very much disagree with this.
>
> The notion of separating a data template from a presentation template
> is arbitrary and nothing really generally useful from a SoC point of
> view.
I didn't mean two different *template mechanisms*, rather that we need
templates at two (or several) points in a pipeline, not only at the
beginning of the pipeline as the G in JXTG implies.
Thinking about it, what I was talking about is two *use cases* for the
templating system, with very different point of views and users skills.
> ...What we need is a template language. Period. Something that
> converts data *structures* into SAX events. Whether you use it for
> data or presentation or whatever else, it's up to you...
Fully agreed.
-Bertrand
Re: [RT] do me a favor, don't call them taglibs (TAL-like two-step
templating?)
Posted by "Roy G. Biv" <mi...@pcextremist.com>.
Stefano Mazzocchi wrote:
> What we need is a template language. Period. Something that converts
> data *structures* into SAX events. Whether you use it for data or
> presentation or whatever else, it's up to you.
Once again, it looks like I should have just read all the comments
before replying again. *sigh*
For what it's worth, concept resonation has occurred. (aka "I agree
completely")
- Miles Elam
Re: [RT] do me a favor, don't call them taglibs (TAL-like two-step
templating?)
Posted by Stefano Mazzocchi <st...@apache.org>.
Bertrand Delacretaz wrote:
> Le 3 déc. 04, à 22:35, Christian Stocker a écrit :
>
>> ....On 3.12.2004 21:50 Uhr, 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.
>>
>> Maybe Zope's TAL idea is something for you.
>> http://www.zope.org/Wikis/DevSite/Projects/ZPT/TAL
>>
>> They are very fond of the fact that it's "Dreamweaver-Compatible"
>
>
> I think we need
>
> a) "data templates" (for a lack of a better word), to generate XML out
> of data (what JXTG does now),
>
> and
>
> b) "presentation templates" downstream to convert the XML to HTML or
> other presentation markup (currently covered by XSLT, far from ideal)
I very much disagree with this.
The notion of separating a data template from a presentation template is
arbitrary and nothing really generally useful from a SoC point of view.
I, personally, don't create XML anymore but I just work with XHTML tags
(intermixed with other namespaced content) right from the beginning of
my pipelines.
Tell me, is
<ul>
<li>blah</li>
</ul>
data or presentation?
Also, I don't do "stylying" anymore with XSLT, I use CSS and all I use
XSLT for is to "adapt" my XHTML in those cases (fewer and fewer as
browsers and my CSS knowldge advance) where CSS can't do the job directly.
What we need is a template language. Period. Something that converts
data *structures* into SAX events. Whether you use it for data or
presentation or whatever else, it's up to you.
> - oo -
>
> For a), JXTG does a good job currently, but having a single mechanism
> for both would make a big difference in the number of things that people
> have to learn to be productive with Cocoon.
Sure, that's the goal: the template system should be markup agnostic, so
how you use it is up to you.
> For b), being dreamweaver-compatible would be a big plus, allowing less
> technical people to create templates themselves. Using Dreamweaver or
> not, that's not the point: DW-compatibility also means that the
> templating system is "simple enough" for such people to grasp.
Yes, that's my point. I don't use DW or anything else of that sort, but
the fact that you *can* use it with that means that it's simple to learn
*and* doesn't get in the way of what they are trying to do normally.
> - oo -
>
> To me, TAL's design looks simple for simple things, yet powerful and
> extensible. Looks like an example to follow, maybe even like a spec to
> adopt instead of reinventing it..
will take a look at this.
--
Stefano.
Re: [RT] do me a favor, don't call them taglibs (TAL-like two-step
templating?)
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Roy G. Biv wrote:
> Daniel Fagerstrom wrote:
<snip/>
>> You're right no need to optimize until we know if it is needed. AFAICS
>> the only reasonable way of accessing the XML input is things like
>> XPath that in general need access to the complete XML-tree. And in
>> that case we can reuse XSLT processor technology if needed. Going for
>> something like STX-style access would be far to complecated for the
>> intended audience.
>
>
> Why is STX considered more complex than XSLT?
I mean for writing a simple to use template language that works like
XSLT: XML->XML driven by a stylesheet. If the template writer want to
render data in another order than that of the input document, the
streaming, non-buffering nature of STX will bite them. They need to
write rules that are trigered by the correct input events and buffer the
data. This requires some thinking even for experienced programmers.
In XSLT you have random access to the whole tree and don't need to care
about temporal order of things. Much easier.
> Sure it doesn't have
> arbitrary source tree access, but the syntax is very similar to XSLT by
> design. Instead of <xsl:template>, you have <stx:template>.
I have written a number of STX style sheets for a number of different
application, where avoiding buffering was important for performance. I
would say that syntax is its only similarity with XSLT. Or do you have
different experience.
> I still
> think that STX would act as an effective macro expansion mechanism
> instead of having macros in Java/SAX.
As said in another letter: macro expansion is written in the template
language it self.
/Daniel
Re: [RT] do me a favor, don't call them taglibs (TAL-like two-step
templating?)
Posted by "Roy G. Biv" <mi...@pcextremist.com>.
Daniel Fagerstrom wrote:
>> And it might make a big difference, from the users point of view, by
>> making it possible to use a single tool for the whole presentation
>> pipeline, and making presentation templates way easier than raw XSLT,
>> which is a major stumbling block for many people.
>>
>> We might want to make it work first, to see how much people like it.
>> If they like it, I'm sure someone will find a way to make it fast, if
>> needed.
>
>
> You're right no need to optimize until we know if it is needed. AFAICS
> the only reasonable way of accessing the XML input is things like
> XPath that in general need access to the complete XML-tree. And in
> that case we can reuse XSLT processor technology if needed. Going for
> something like STX-style access would be far to complecated for the
> intended audience.
Why is STX considered more complex than XSLT? Sure it doesn't have
arbitrary source tree access, but the syntax is very similar to XSLT by
design. Instead of <xsl:template>, you have <stx:template>. I still
think that STX would act as an effective macro expansion mechanism
instead of having macros in Java/SAX.
- Miles Elam
Re: [RT] do me a favor, don't call them taglibs (TAL-like two-step
templating?)
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Bertrand Delacretaz wrote:
> Le 4 déc. 04, à 14:14, Daniel Fagerstrom a écrit :
>> Bertrand Delacretaz wrote:
>>
>>> ...b) "presentation templates" downstream to convert the XML to HTML
>>> or other presentation markup (currently covered by XSLT, far from ideal)
>
>
>>> ...For b), being dreamweaver-compatible would be a big plus, allowing
>>> less technical people to create templates themselves....
>>
>>
>> b) would be nice but it is quite complicated to implement in an
>> efficient way. One can of course stream the transformer input to a DOM
>> tree that is made available in the context object and then let a JXTG
>> like script work on that. But the question is if we would be happy wih
>> the performance...
>
>
> It's hard to say without trying it, but IIUC we can essentially get this
> (i.e. reuse the data-to-XML templating mechanism for downstream
> transformations) for free, if taken into acount in the design. Just a
> simple stream-to-DOM implementation would allow people to experiment.
Yes, we would get that for free AFAIU. The design discussed this far
should handle that without any problems. We need a convention for where
to find the input DOM. Either implicitly like xslt or some special
variable "$input".
> And it might make a big difference, from the users point of view, by
> making it possible to use a single tool for the whole presentation
> pipeline, and making presentation templates way easier than raw XSLT,
> which is a major stumbling block for many people.
>
> We might want to make it work first, to see how much people like it. If
> they like it, I'm sure someone will find a way to make it fast, if needed.
You're right no need to optimize until we know if it is needed. AFAICS
the only reasonable way of accessing the XML input is things like XPath
that in general need access to the complete XML-tree. And in that case
we can reuse XSLT processor technology if needed. Going for something
like STX-style access would be far to complecated for the intended audience.
/Daniel
Re: [RT] do me a favor, don't call them taglibs (TAL-like two-step templating?)
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 4 déc. 04, à 14:14, Daniel Fagerstrom a écrit :
> Bertrand Delacretaz wrote:
>> ...b) "presentation templates" downstream to convert the XML to HTML
>> or other presentation markup (currently covered by XSLT, far from
>> ideal)
>> ...For b), being dreamweaver-compatible would be a big plus, allowing
>> less technical people to create templates themselves....
>
> b) would be nice but it is quite complicated to implement in an
> efficient way. One can of course stream the transformer input to a DOM
> tree that is made available in the context object and then let a JXTG
> like script work on that. But the question is if we would be happy wih
> the performance...
It's hard to say without trying it, but IIUC we can essentially get
this (i.e. reuse the data-to-XML templating mechanism for downstream
transformations) for free, if taken into acount in the design. Just a
simple stream-to-DOM implementation would allow people to experiment.
And it might make a big difference, from the users point of view, by
making it possible to use a single tool for the whole presentation
pipeline, and making presentation templates way easier than raw XSLT,
which is a major stumbling block for many people.
We might want to make it work first, to see how much people like it. If
they like it, I'm sure someone will find a way to make it fast, if
needed.
-Bertrand
Re: [RT] do me a favor, don't call them taglibs (TAL-like two-step
templating?)
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Bertrand Delacretaz wrote:
<snip/>
> I think we need
>
> a) "data templates" (for a lack of a better word), to generate XML out
> of data (what JXTG does now),
>
> and
>
> b) "presentation templates" downstream to convert the XML to HTML or
> other presentation markup (currently covered by XSLT, far from ideal)
>
> - oo -
>
> For a), JXTG does a good job currently, but having a single mechanism
> for both would make a big difference in the number of things that people
> have to learn to be productive with Cocoon.
>
> For b), being dreamweaver-compatible would be a big plus, allowing less
> technical people to create templates themselves. Using Dreamweaver or
> not, that's not the point: DW-compatibility also means that the
> templating system is "simple enough" for such people to grasp.
b) would be nice but it is quite complicated to implement in an
efficient way. One can of course stream the transformer input to a DOM
tree that is made available in the context object and then let a JXTG
like script work on that. But the question is if we would be happy wih
the performance. Otherwise we would need to build a more light weight
tree representation of XML and write adapters to it so that it work with
an XPath processor, Jaxen e.g. Or maybe there are light weight XML tree
implementations that we could reuse.
>
> - oo -
>
> To me, TAL's design looks simple for simple things, yet powerful and
> extensible. Looks like an example to follow, maybe even like a spec to
> adopt instead of reinventing it..
Didn't like the Phyton syntax, but we can certainly find some good ideas
from it.
/Daniel
Re: [RT] do me a favor, don't call them taglibs (TAL-like two-step templating?)
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 3 déc. 04, à 22:35, Christian Stocker a écrit :
> ....On 3.12.2004 21:50 Uhr, 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.
>
> Maybe Zope's TAL idea is something for you.
> http://www.zope.org/Wikis/DevSite/Projects/ZPT/TAL
>
> They are very fond of the fact that it's "Dreamweaver-Compatible"
I think we need
a) "data templates" (for a lack of a better word), to generate XML out
of data (what JXTG does now),
and
b) "presentation templates" downstream to convert the XML to HTML or
other presentation markup (currently covered by XSLT, far from ideal)
- oo -
For a), JXTG does a good job currently, but having a single mechanism
for both would make a big difference in the number of things that
people have to learn to be productive with Cocoon.
For b), being dreamweaver-compatible would be a big plus, allowing less
technical people to create templates themselves. Using Dreamweaver or
not, that's not the point: DW-compatibility also means that the
templating system is "simple enough" for such people to grasp.
- oo -
To me, TAL's design looks simple for simple things, yet powerful and
extensible. Looks like an example to follow, maybe even like a spec to
adopt instead of reinventing it..
> ...I once started implementing that in my own framework (a php based
> cocoon ripoff ;)
ah good. sometimes people ask what popoon is, now we know how to
describe it ;-) ;-)
-Bertrand
Re: [RT] do me a favor, don't call them taglibs
Posted by Christian Stocker <ch...@bitflux.ch>.
On 3.12.2004 21:50 Uhr, 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.
Maybe Zope's TAL idea is something for you.
http://www.zope.org/Wikis/DevSite/Projects/ZPT/TAL
They are very fond of the fact that it's "Dreamweaver-Compatible"
I once started implementing that in my own framework (a php based cocoon
ripoff ;) ), but with using XSLT for transforming the TAL to another
XSLT, which then transformed the actual content. I never really finished
it (meaning implementing most of the specs), but it was basically
working. Take it as a proof of concept ;)
The XSLT can be found here:
http://svn.bitflux.ch/repos/public/popoon/trunk/components/transformers/xsltal/tal2xslt.xsl
(the bxf:tales function is framework specific and would have to be
adjusted a little bit for general use, IIRC)
chregu
--
christian stocker | Bitflux GmbH | schoeneggstrasse 5 | ch-8004 zurich
phone +41 1 240 56 70 | mobile +41 76 561 88 60 | fax +41 1 240 56 71
http://www.bitflux.ch | chregu@bitflux.ch | gnupg-keyid 0x5CE1DECB
Re: [RT] do me a favor, don't call them taglibs
Posted by Stefano Mazzocchi <st...@apache.org>.
Daniel Fagerstrom wrote:
> Stefano Mazzocchi wrote:
> <snip/>
>
>> Still, CSS is not enough because is not able to change the layout of
>> things and, even worse, sometimes the style dictates the markup
>> (example: if you want to use stuff like rounded boxes).
>
>
> <OT>
> For rounded corners at tabs you can use :before and :after pseudo
> selectors http://www.w3.org/TR/REC-CSS2/selector.html#before-and-after,
> unfortionally it only works in modern browsers and not in the popular
> broken one that our custommers tend to have :/
>
> Then if you feel that your CSS style sheets are by far to easy to
> understand, there are a couple of interesting CSS tricks for getting
> rounded corners even in IE:
>
> http://www.alistapart.com/articles/slidingdoors/,
> http://www.alistapart.com/articles/slidingdoors2/,
> http://www.alistapart.com/articles/customcorners/
>
> They are so subtle that the XSLT solution probably is better idea.
> </OT>
I do that. The problem is that you have *4* corners, not 2 ;-) that's
why it forces you to use two elements, so that you can have the top
corner be the :before of the first and the bottom corner to be the
:before of the second.
That's my favorite example of why CSS is not powerful enough for what
people need.
--
Stefano.
Re: [RT] do me a favor, don't call them taglibs
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Roy G. Biv wrote:
> Daniel Fagerstrom wrote:
>
>> Stefano Mazzocchi wrote:
>> <snip/>
>>
>>> Still, CSS is not enough because is not able to change the layout of
>>> things and, even worse, sometimes the style dictates the markup
>>> (example: if you want to use stuff like rounded boxes).
>>
>>
>> <OT>
>> For rounded corners at tabs you can use :before and :after pseudo
>> selectors
>> http://www.w3.org/TR/REC-CSS2/selector.html#before-and-after,
>> unfortionally it only works in modern browsers and not in the popular
>> broken one that our custommers tend to have :/
>
>
> http://dean.edwards.name/IE7/
Nice, I have to test that. Might be able to remove some of my uglier CSS
hacks for showing thing in IE :)
/Daniel
Re: [RT] do me a favor, don't call them taglibs
Posted by "Roy G. Biv" <mi...@pcextremist.com>.
Daniel Fagerstrom wrote:
> Stefano Mazzocchi wrote:
> <snip/>
>
>> Still, CSS is not enough because is not able to change the layout of
>> things and, even worse, sometimes the style dictates the markup
>> (example: if you want to use stuff like rounded boxes).
>
> <OT>
> For rounded corners at tabs you can use :before and :after pseudo
> selectors
> http://www.w3.org/TR/REC-CSS2/selector.html#before-and-after,
> unfortionally it only works in modern browsers and not in the popular
> broken one that our custommers tend to have :/
http://dean.edwards.name/IE7/
- Miles Elam
Re: [RT] do me a favor, don't call them taglibs
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Stefano Mazzocchi wrote:
<snip/>
> Still, CSS is not enough because is not able to change the layout of
> things and, even worse, sometimes the style dictates the markup
> (example: if you want to use stuff like rounded boxes).
<OT>
For rounded corners at tabs you can use :before and :after pseudo
selectors http://www.w3.org/TR/REC-CSS2/selector.html#before-and-after,
unfortionally it only works in modern browsers and not in the popular
broken one that our custommers tend to have :/
Then if you feel that your CSS style sheets are by far to easy to
understand, there are a couple of interesting CSS tricks for getting
rounded corners even in IE:
http://www.alistapart.com/articles/slidingdoors/,
http://www.alistapart.com/articles/slidingdoors2/,
http://www.alistapart.com/articles/customcorners/
They are so subtle that the XSLT solution probably is better idea.
</OT>
/Daniel
Re: [RT] do me a favor, don't call them taglibs
Posted by Glen Ezkovich <gl...@hard-bop.com>.
On Dec 4, 2004, at 10:52 PM, Stefano Mazzocchi wrote:
>
> Glen,
>
> I don't think we are talking about very different things.
I know.
>
> I *completely* agree with you that the power of pipelines and SoC is
> exactly that: change one file and make all the others adjust. Damn,
> there wouldn't be a cocoon if that wasn't the case ;-)
>
> What I want is to create a 'bridge' for those who don't get it.
To some extent. I want something simpler then XSLT and is more markup
oriented (an XHTML template). I'd also like to not ask my designers to
invoke java methods.
>
> CSS is already a tremendous bridge that allows people to cleanup their
> pages and they understand the power of SoC, since changing a
> stylesheet allows them to change all the pages.
>
> Still, CSS is not enough because is not able to change the layout of
> things
It can change the layout of things with absolute positioning. Its just
very difficult to get things right. and it becomes a night mare to make
changes to.
> and, even worse, sometimes the style dictates the markup (example: if
> you want to use stuff like rounded boxes).
Need to talk to your designers then ;-)
>
> *but* what is possible is to have something like
>
> <div class="header">Header</div>
>
> be transformed into a massive, highly graphical, header.
>
> In short, it is possible to give *some* visual but style free
> placeholding material for the layout designers to work with, then
> transform these with some XSLT.
What we have is something slightly different, we have <header> tags.
These get transformed differently depending on context. Possibly with
different classes.
>
> What you need is not WYSIWYG,
I wish there was such a tool. :-)
> web designers care about that, but usability managers really don't.
> They care about colors and fonts and spaces and positioning and error
> messages and visibility of things (all things that CSS can do for
> them), so it's entirely possible to have placeholders for things they
> don't care about, they just want to care about the content, but also
> about the layout of the page.
Agreed. However, our place holders represent entities, not page
elements. Things such as products, images or headings. We use XSLT to
transform them into html. Right now I go so far as to insist that we do
not use html tag names for our entity names. i.e. you can't use <img>
you need to use <image> . I know its anal, but I really want to
emphasize the difference between content and layout. We are not always
successful but we are working on it.
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] do me a favor, don't call them taglibs
Posted by Stefano Mazzocchi <st...@apache.org>.
Glen Ezkovich wrote:
>
> On Dec 3, 2004, at 3:33 PM, Ralph Goers wrote:
>
>> Glen Ezkovich said:
>>
>>>
>>> On Dec 3, 2004, at 2:50 PM, Stefano Mazzocchi wrote:
>>>
>>>> All I ask from a template language:
>>>>
>>>> 1) something that HTML designers can edit with Dreamweaver
>>>
>>>
>>> Why? I really don't want HTML designers touching my templates. I want
>>> them to work withe the data received from my generator and transform
>>> that into something renderable by a browser.
>>
>>
>> Wow. I guess we really have a different point of view. I see
>> templates as
>> an alternative to XSLT to generate the HTML. Of course I would want an
>> HTML designer to be able to do that.
>
>
> I did too. Just wound up with the same old problem, mixed concerns. Each
> template had to be maintained as the site's visual style evolved. As
> much as we tried to use CSS, we still had to modify the HTML. Divs here,
> tables there, the ice was all around. :-)
> While I can see using a template to directly generate the HTML it makes
> each page layout a separate maintenance issue. That is, some changes to
> a sites design might require each template to be modified. Using XSLT,
> it might be possible to change just a single XSL template. Think of
> something as simple as changing the image used as a bullet in a bullet
> list, or placing adds between paragraphs instead of all in the left column.
>
> As usual, what you choose to do depends on what you anticipate the needs
> of your site to be. If I needed to nothing more then take a result set
> and display it in a table, I probably would just generate the table in
> the template. The more complex the page becomes the less likely I am to
> use HTML in the template.
>
> What I've tried to do is define common entities that are rendered the
> same across various layouts and to define general page layout components
> that can be reused. By entities I mean things like products, product
> lines, features, feature, article, paragraph, etc.. These are generally
> given an XML representation using JXTG and are in turn rendered by XSLT.
> By general page layout components I mean rows, columns, grids, bullet
> lists, images, etc.. These are defined in a style sheet. A product can
> be laid out the same wether it is on a page by it's self or part of a
> catalog page. The difference might only be in the styles applied and/or
> the layout component that contains it. HTML element wise, the two
> renderings are identical, but visually maybe very different. Sometimes
> we do have to have use modes to render entities differently, but I
> generally consider these cases a failure of imagination. What is nice
> about this, is that the same template that generates XML data for a
> product on one site can be used with no or slight modification on
> another. The XSL defined layout components can be reused as well. The
> only things that need changing are the CSSs and some of the XSL
> templates for the entities.
>
> The aim is to be able to have a data/content driven model of a website
> as well as a page driven model. I'm not quite where I want to be yet.
> But I'm working on it. I still need to flesh out the concept a bit more
> and I need more sites to experiment on. Shhhhhh... Don't tell my
> clients. ;-) (this a private secure list... right?)
Glen,
I don't think we are talking about very different things.
I *completely* agree with you that the power of pipelines and SoC is
exactly that: change one file and make all the others adjust. Damn,
there wouldn't be a cocoon if that wasn't the case ;-)
What I want is to create a 'bridge' for those who don't get it.
CSS is already a tremendous bridge that allows people to cleanup their
pages and they understand the power of SoC, since changing a stylesheet
allows them to change all the pages.
Still, CSS is not enough because is not able to change the layout of
things and, even worse, sometimes the style dictates the markup
(example: if you want to use stuff like rounded boxes).
*but* what is possible is to have something like
<div class="header">Header</div>
be transformed into a massive, highly graphical, header.
In short, it is possible to give *some* visual but style free
placeholding material for the layout designers to work with, then
transform these with some XSLT.
What you need is not WYSIWYG, web designers care about that, but
usability managers really don't. They care about colors and fonts and
spaces and positioning and error messages and visibility of things (all
things that CSS can do for them), so it's entirely possible to have
placeholders for things they don't care about, they just want to care
about the content, but also about the layout of the page.
--
Stefano.
Re: [RT] do me a favor, don't call them taglibs
Posted by Glen Ezkovich <gl...@hard-bop.com>.
On Dec 3, 2004, at 3:33 PM, Ralph Goers wrote:
> Glen Ezkovich said:
>>
>> On Dec 3, 2004, at 2:50 PM, Stefano Mazzocchi wrote:
>>
>>> All I ask from a template language:
>>>
>>> 1) something that HTML designers can edit with Dreamweaver
>>
>> Why? I really don't want HTML designers touching my templates. I want
>> them to work withe the data received from my generator and transform
>> that into something renderable by a browser.
>
> Wow. I guess we really have a different point of view. I see
> templates as
> an alternative to XSLT to generate the HTML. Of course I would want an
> HTML designer to be able to do that.
I did too. Just wound up with the same old problem, mixed concerns.
Each template had to be maintained as the site's visual style evolved.
As much as we tried to use CSS, we still had to modify the HTML. Divs
here, tables there, the ice was all around. :-)
While I can see using a template to directly generate the HTML it makes
each page layout a separate maintenance issue. That is, some changes to
a sites design might require each template to be modified. Using XSLT,
it might be possible to change just a single XSL template. Think of
something as simple as changing the image used as a bullet in a bullet
list, or placing adds between paragraphs instead of all in the left
column.
As usual, what you choose to do depends on what you anticipate the
needs of your site to be. If I needed to nothing more then take a
result set and display it in a table, I probably would just generate
the table in the template. The more complex the page becomes the less
likely I am to use HTML in the template.
What I've tried to do is define common entities that are rendered the
same across various layouts and to define general page layout
components that can be reused. By entities I mean things like
products, product lines, features, feature, article, paragraph, etc..
These are generally given an XML representation using JXTG and are in
turn rendered by XSLT. By general page layout components I mean rows,
columns, grids, bullet lists, images, etc.. These are defined in a
style sheet. A product can be laid out the same wether it is on a page
by it's self or part of a catalog page. The difference might only be in
the styles applied and/or the layout component that contains it. HTML
element wise, the two renderings are identical, but visually maybe very
different. Sometimes we do have to have use modes to render entities
differently, but I generally consider these cases a failure of
imagination. What is nice about this, is that the same template that
generates XML data for a product on one site can be used with no or
slight modification on another. The XSL defined layout components can
be reused as well. The only things that need changing are the CSSs and
some of the XSL templates for the entities.
The aim is to be able to have a data/content driven model of a website
as well as a page driven model. I'm not quite where I want to be yet.
But I'm working on it. I still need to flesh out the concept a bit more
and I need more sites to experiment on. Shhhhhh... Don't tell my
clients. ;-) (this a private secure list... right?)
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] do me a favor, don't call them taglibs
Posted by Ralph Goers <Ra...@dslextreme.com>.
Glen Ezkovich said:
>
> On Dec 3, 2004, at 2:50 PM, Stefano Mazzocchi wrote:
>
>> All I ask from a template language:
>>
>> 1) something that HTML designers can edit with Dreamweaver
>
> Why? I really don't want HTML designers touching my templates. I want
> them to work withe the data received from my generator and transform
> that into something renderable by a browser.
Wow. I guess we really have a different point of view. I see templates as
an alternative to XSLT to generate the HTML. Of course I would want an
HTML designer to be able to do that.
Ralph
Re: [RT] do me a favor, don't call them taglibs
Posted by Glen Ezkovich <gl...@hard-bop.com>.
On Dec 3, 2004, at 2:50 PM, Stefano Mazzocchi wrote:
> All I ask from a template language:
>
> 1) something that HTML designers can edit with Dreamweaver
Why? I really don't want HTML designers touching my templates. I want
them to work withe the data received from my generator and transform
that into something renderable by a browser.
> 2) something that doesn't use namespaced tags to identify dynamic
> scopes (clashes with #1)
Would be nice. But since I don't like 1, no problem here. ;-)
> 3) something that doesn't use the name taglib
The name does have evil connotations. Do you have a suggestion for a
new name?
>
> That's pretty much all you have to do to make me happy.
>
> --
> Stefano.
>
>
>
>
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)
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
[RT] Attribute Driven Templates (Was: [RT] do me a favor, don't call
them taglibs)
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
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] do me a favor, don't call them taglibs
Posted by Stefano Mazzocchi <st...@apache.org>.
Bertrand Delacretaz wrote:
> Le 4 déc. 04, à 16:56, Antonio Gallardo a écrit :
>
>> ...I think is better to extend what we have instead of defining a new
>> language. We need to consolidate things while I understand is good to
>> have
>> a new research areas. So in anycase the JXTG refactoring is a must...
>
>
> I'd say keeping JXTG alive is a must, and refactoring is probably needed
> to make this happen.
>
> OTOH what's been discussed in the last days regarding attribute-based
> Dreamweaver-friendly templating looks to me like a very welcome
> evolution, which can happen in parallel.
+1
--
Stefano.
Re: [RT] do me a favor, don't call them taglibs
Posted by Antonio Gallardo <ag...@agssa.net>.
On Sab, 4 de Diciembre de 2004, 10:03, Bertrand Delacretaz dijo:
> Le 4 déc. 04, à 16:56, Antonio Gallardo a écrit :
>> ...I think is better to extend what we have instead of defining a new
>> language. We need to consolidate things while I understand is good to
>> have
>> a new research areas. So in anycase the JXTG refactoring is a must...
>
> I'd say keeping JXTG alive is a must, and refactoring is probably
> needed to make this happen.
>
> OTOH what's been discussed in the last days regarding attribute-based
> Dreamweaver-friendly templating looks to me like a very welcome
> evolution, which can happen in parallel.
OK. Lets do that!
/me is hoping he will not break nothing in the job. ;-)
Best Regards,
Antonio Gallardo
Re: [RT] do me a favor, don't call them taglibs
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 4 déc. 04, à 16:56, Antonio Gallardo a écrit :
> ...I think is better to extend what we have instead of defining a new
> language. We need to consolidate things while I understand is good to
> have
> a new research areas. So in anycase the JXTG refactoring is a must...
I'd say keeping JXTG alive is a must, and refactoring is probably
needed to make this happen.
OTOH what's been discussed in the last days regarding attribute-based
Dreamweaver-friendly templating looks to me like a very welcome
evolution, which can happen in parallel.
-Bertrand
Re: [RT] do me a favor, don't call them taglibs
Posted by Jonas Ekstedt <ek...@ibg.uu.se>.
On Sat, 4 Dec 2004, Antonio Gallardo wrote:
snip...
> I agree. Anyway, we (in Cocoon) have a current user base using JXTG that
> we cannot forget. If is necesary, I can do that. Some months ago, I spend
> a week understanding how the JXTG works. While I don't consider myself an
> expert. I thing we can make the life easier to others by breaking it down.
> I saw some problems on the user list that I guess can be easily fixed in
> the current implementation. BTW, I also saw the current implementation has
> some broken parts that need to be fixed again.
The only part missing is finalizing the Tag interface. Specifically how
attributes values should be fed into the tag instance (at the time there
was disagreement regarding thread safety of tags so the Tag interface had
to wait).
There might also be some tweaks necessary to support macros.
>
> I think is better to extend what we have instead of defining a new
> language. We need to consolidate things while I understand is good to have
> a new research areas. So in anycase the JXTG refactoring is a must.
The template block is exactly that, an attempt at refactoring JXTG.
Cheers Jonas
Re: [RT] do me a favor, don't call them taglibs
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Antonio Gallardo wrote:
> On Sab, 4 de Diciembre de 2004, 6:58, Daniel Fagerstrom dijo:
>>Antonio Gallardo wrote:
>>That is the main idea with the template initiative. Then we happened to
>>use a word for describing the mechanism of breaking out the template tag
>>implementations to separate files, that suddenly made every one upset.
>>
>>One could break up JXTG by writing detailed test cases for JXTG and
>>refactor in controlled steps to something more managable. But it didn't
>>seem like anybody found that solution attractive.
>>
>>I'll sugest that we see what the templating discussion leads and base
>>further work on that.
>
> I agree. Anyway, we (in Cocoon) have a current user base using JXTG that
> we cannot forget.
Definitively not. As I said the template initiative is about
re-implementing JXTG in such a way that it is easier to understand and
maintain. And also easier to reuse stuff that is needed in other parts
of Cocoon.
> If is necesary, I can do that. Some months ago, I spend
> a week understanding how the JXTG works. While I don't consider myself an
> expert. I thing we can make the life easier to others by breaking it down.
When we discussed templateing stuff it didn't seem like anybody feeled
like refactoring JXTG, so we went for reimplementation of at least the
script and compiler stuff. Then it was at least my intension to reuse as
much code from JXTG as possible.
But if you feel like refactoring JXTG, we can certaninly work in
parallell. Especially if we work fro different "directions" and keep the
work sycnced so that we avoid doing the same thing twice.
If you would like to factor out the parts that build the context objects
for Jexl and JXPath respectively, it would be excelent. Especially if
you combine it with Carstens work in that area:
o.a.c.environment.TemplateObjectModelHelper in scratchpad. If not
anybody is against it I would sugest to move that component to core
Cocoon so that JXTG can be refactored without needing to have two
instances of it.
Handling both JXPath and Jexl expreesion through a common interface
would also be nice. Basing JXTG on an abstract class that handles
caching of the compiled script based on both the script source and
sources to included scripts would also be good.
Factoring out the tags is not worthwhile right now IMO. Each tag has
code in three different areas: In a special class for the tag, in the
compiler class, and in the execute method. Maybe you could try to gather
all code for each tag in the tag class. But I would sugest that we take
care of this part in the template stuff instead.
> I saw some problems on the user list that I guess can be easily fixed in
> the current implementation. BTW, I also saw the current implementation has
> some broken parts that need to be fixed again.
>
> I think is better to extend what we have instead of defining a new
> language. We need to consolidate things while I understand is good to have
> a new research areas. So in anycase the JXTG refactoring is a must.
>
> WDYT?
The template stuff is all about consilidating JXTG and creating a
framework where new research is possible.
/Daniel
Re: [RT] do me a favor, don't call them taglibs
Posted by Antonio Gallardo <ag...@agssa.net>.
On Sab, 4 de Diciembre de 2004, 6:58, Daniel Fagerstrom dijo:
> Antonio Gallardo wrote:
>> On Vie, 3 de Diciembre de 2004, 15:35, Tony Collen dijo:
>>
>>>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.
>>>>
>>>
>>>I believe I was responsible for originally "starting" the discussion
>>>about fixing JXTG 2, so I feel like I should probably respond.
>>>
>>>JXTG works just fine. I just didn't want to be freaked out looking at
>>>the source. At a minimum, having JXTG refactored, keeping the exact
>>>same functionality, and my mind would be put at ease.
>>
>>
>> I can try to break the original JXTG in more classes. I mean in
>> separated
>> files.
>>
>> WDYT?
>>
>> Best Regards,
>>
>> Antonio Gallardo.
>
> That is the main idea with the template initiative. Then we happened to
> use a word for describing the mechanism of breaking out the template tag
> implementations to separate files, that suddenly made every one upset.
>
> One could break up JXTG by writing detailed test cases for JXTG and
> refactor in controlled steps to something more managable. But it didn't
> seem like anybody found that solution attractive.
>
> I'll sugest that we see what the templating discussion leads and base
> further work on that.
I agree. Anyway, we (in Cocoon) have a current user base using JXTG that
we cannot forget. If is necesary, I can do that. Some months ago, I spend
a week understanding how the JXTG works. While I don't consider myself an
expert. I thing we can make the life easier to others by breaking it down.
I saw some problems on the user list that I guess can be easily fixed in
the current implementation. BTW, I also saw the current implementation has
some broken parts that need to be fixed again.
I think is better to extend what we have instead of defining a new
language. We need to consolidate things while I understand is good to have
a new research areas. So in anycase the JXTG refactoring is a must.
WDYT?
Best Regards,
Antonio Gallardo.
Re: [RT] do me a favor, don't call them taglibs
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Antonio Gallardo wrote:
> On Vie, 3 de Diciembre de 2004, 15:35, Tony Collen dijo:
>
>>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.
>>>
>>
>>I believe I was responsible for originally "starting" the discussion
>>about fixing JXTG 2, so I feel like I should probably respond.
>>
>>JXTG works just fine. I just didn't want to be freaked out looking at
>>the source. At a minimum, having JXTG refactored, keeping the exact
>>same functionality, and my mind would be put at ease.
>
>
> I can try to break the original JXTG in more classes. I mean in separated
> files.
>
> WDYT?
>
> Best Regards,
>
> Antonio Gallardo.
That is the main idea with the template initiative. Then we happened to
use a word for describing the mechanism of breaking out the template tag
implementations to separate files, that suddenly made every one upset.
One could break up JXTG by writing detailed test cases for JXTG and
refactor in controlled steps to something more managable. But it didn't
seem like anybody found that solution attractive.
I'll sugest that we see what the templating discussion leads and base
further work on that.
/Daniel
Re: [RT] do me a favor, don't call them taglibs
Posted by Antonio Gallardo <ag...@agssa.net>.
On Vie, 3 de Diciembre de 2004, 16:44, Upayavira dijo:
> That might help in the short term. But there's something special that
> happens in Cocoon - it has happened with flow, then CForms, but hasn't
> happened with JXTemplate. When everyone rounds on a technology, and
> thoroughly backs it. And that has still to happen in relation to
> templating. (or maybe it is already happenning, who knows).
Yep. I expect this would happen here too. Some months ago, some of us
closed JXTG bugs and added new features to it. ;-)
Best Regards,
Antonio Gallardo
Re: [RT] do me a favor, don't call them taglibs
Posted by Upayavira <uv...@upaya.co.uk>.
Antonio Gallardo wrote:
>On Vie, 3 de Diciembre de 2004, 15:35, Tony Collen dijo:
>
>
>>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.
>>>
>>>
>>>
>>I believe I was responsible for originally "starting" the discussion
>>about fixing JXTG 2, so I feel like I should probably respond.
>>
>>JXTG works just fine. I just didn't want to be freaked out looking at
>>the source. At a minimum, having JXTG refactored, keeping the exact
>>same functionality, and my mind would be put at ease.
>>
>>
>
>I can try to break the original JXTG in more classes. I mean in separated
>files.
>
>
That might help in the short term. But there's something special that
happens in Cocoon - it has happened with flow, then CForms, but hasn't
happened with JXTemplate. When everyone rounds on a technology, and
thoroughly backs it. And that has still to happen in relation to
templating. (or maybe it is already happenning, who knows).
Regards, Upayavira
Re: [RT] do me a favor, don't call them taglibs
Posted by Antonio Gallardo <ag...@agssa.net>.
On Vie, 3 de Diciembre de 2004, 15:35, Tony Collen dijo:
> 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.
>>
>
> I believe I was responsible for originally "starting" the discussion
> about fixing JXTG 2, so I feel like I should probably respond.
>
> JXTG works just fine. I just didn't want to be freaked out looking at
> the source. At a minimum, having JXTG refactored, keeping the exact
> same functionality, and my mind would be put at ease.
I can try to break the original JXTG in more classes. I mean in separated
files.
WDYT?
Best Regards,
Antonio Gallardo.
Re: [RT] do me a favor, don't call them taglibs
Posted by Tony Collen <co...@umn.edu>.
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.
>
I believe I was responsible for originally "starting" the discussion
about fixing JXTG 2, so I feel like I should probably respond.
JXTG works just fine. I just didn't want to be freaked out looking at
the source. At a minimum, having JXTG refactored, keeping the exact
same functionality, and my mind would be put at ease.
Tony