You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Bertrand Delacretaz <bd...@apache.org> on 2004/12/04 09:37:10 UTC
Re: [RT] do me a favor, don't call them taglibs (TAL-like two-step templating?)
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 (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