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/06 08:54:44 UTC
Re: [Design] JXTG 2.0 (generator and transformer, same template syntax?)
Le 5 déc. 04, à 06:14, Stefano Mazzocchi a écrit :
> Bertrand Delacretaz wrote:
>> ...That's what I mean - having a transformer that can use the same
>> template syntax as used in the generator, so that the template
>> language can be used for both the generation and transformation
>> steps.
>
> My FS detector is out of scale!!
Hmmm...maybe it needs a battery change after working too hard in the
last few days ;-)
Let me clarify with a concrete story: we start with a few beans passed
to sendPage, including a Collection of Person objects.
Alice writes a template for the XYZGenerator (our new attribute-based
template language), which receives the beans and generates an XML
document based on this template (syntax details are irrelevant for this
discussion):
<page title="Persons">
<person-list tl:iter="p in personCollection">
<person>
<name>${p/name}</name>
<age>${p/age}</age>
</person>
</person-list>
</page>
At which point she gets an XML "data view" or "logical document" and
passes it downstream for publishing.
Then, Bob, who's in charge of the final presentation, writes another
template to convert this logical document to, say, "lightweight HTML",
for an embedded terminal (no CSS). This gets processed by the
XYZTransformer, which uses the same template and expression engines,
and the same syntax as the XYZGenerator (again, don't worry about
syntax details):
<html>
<head><title>${page/title}</title></head>
<body>
<table>
<tr tl:iter="p in page/person-list">
<td>${p/name}</td>
<td>${p/age}</td>
</tr>
</table>
</body>
</html>
The XYZTransformer receives the XML produced by the XYZGenerator, reads
the above template from disk (or from the output of another pipeline),
and generates the HTML.
-oo-
Advantages:
A1) There's only one implementation of the template and expression
evaluation mechanisms.
A2) Bob can ask Alice for help with the templates, she knows them in
and out as that's what she's using as well.
A3) Bob, coming from a ColdFusion/ASP/PHP background, quickly became
productive with the template language, which looks familiar. In a
pinch, he can ask the trainee to make minor changes in DreamWeaver, in
fact they saved a bunch by doing the prototype in this way.
A4) The XML logical document will "never" change once it's done, as it
contains all the data in presentation-independent format. Write it,
test it, forget about it. Alice doesn't want the critical parts of
their system to change too often.
A5) The XML logical document can be reused to publish the RSS feed, the
mobile WAP/WML version, the full-blown XHTML/CSS version, without
bothering Alice who's a busy and expensive person.
A6) Alice doesn't have to deal with the final customer who's always
asking for "just a small change in the page layout". She leaves this to
Bob for now, but they've considered training the customer to do this on
his own, the templates are simple and isolated enough that he couldn't
break anything anyway.
Disadvantages:
D1) The XYZTransformer is probably slower than a well-written XSLT
transform. But it's also much faster than the XSLT transform that Bob
tried to write. He's only been doing XSLT for four weeks and just plain
hates it.
D2) The XYZTransformer is a memory hog on large documents, as it loads
the document in memory so that the expression evaluator can process it
easily (AFAIK the current XSLT processors do the same in many cases,
however, so this might not really be a problem).
D3) Why so many steps? Generating XHTML directly could have saved some.
But it doesn't help for RSS or WAP/WML, and the generation is actually
much more complicated than what we see here, as configuration files and
site menu definitions need to be aggregated in the page, with different
variants depending on the final presentation target.
D4) Bob was initially confused about this generator/transformer thing,
why both? Alice told him not to worry, generators are not his business
anyway, he's only a Cocoon Transformer Template Designer (but a good
one after only four weeks here). He'll understand when he grows up ;-)
-oo-
So, what's wrong with this? Where's the FS?
I might be overlooking something but this could pave a much easier path
for people to jump into Cocoon and *stay*, not run away scared by XSLT.
XSLT is *the* stumbling block today, and IMHO we don't have a good
alternative to suggest. I don't mean to reinvent it, but as people are
working on improved templates anyway, this looks like a cheap but very
welcome addition.
-Bertrand, enjoying the debate...
Re: [Design] JXTG 2.0 (generator and transformer, same template syntax?)
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 6 déc. 04, à 10:10, Daniel Fagerstrom a écrit :
<big-snip cause="fully agree"/>
> ...BTW: I'm becoming more and more worried about the attribute
> template sytax that you used in your examples ;)
I hope the syntax in my examples is so bad that people just dismiss it
and focus on the rest of the story ;-)
-Bertrand
Re: [Design] JXTG 2.0 (generator and transformer, same template syntax?)
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Bertrand Delacretaz wrote:
...
> Advantages:
...
I agree with your motivation. I would also like to add that when we have
introduced a separate formating layer and enforced side effect free
templates, the conceptual difference between transforming XML input in a
transformer and reading from, e.g. a rowset in a template generator,
will be quite small. In both cases we have read only access to tree
structured data.
Of course can we use different languages in generation and
transformation if there are important conceptual differences, but I fail
to see them and need more motivation and examples to understand why
having the same language would be bad rather than an advantage. But I'm
one of thoose people who regulary use XSLT as generator so I might not
understand what is best for my own good anyway ;)
For those who has been concerned of that I'm (and others) are trying to
introduce to much flexibility in templates (I'm not only talking with
you Stefano ;) ), I would like to stress that I'm serious about
forbiding side effects in templates. And this is a quite severe
restriction in what you can do in templates. As far as I'm able to
influence it, JXTG2 will _not_ contain the jx:set instruction. We can
have an jx:let instruction for giving a local name for something, but no
assignment. Before anyone got upset, we will of course have a JXTG1 back
compability mode. But by taking away the side effects we can do some
fairly radical optimizations in the pipeleine processing. It also
enforces the "correct" SoC between view and control.
> Disadvantages:
> D1) The XYZTransformer is probably slower than a well-written XSLT
> transform. But it's also much faster than the XSLT transform that Bob
> tried to write. He's only been doing XSLT for four weeks and just
> plain hates it.
This is purely at the RT stage: But by writing our own transformer we
can actually use some pull driven lazy evaluating methods in the
transformer (this should trigger an alarm in Peter Hunsberger's mail
filter ;) ), that allow for really radical optimizations.So we could
actually end up with something that is much more efficient than
conventional XSLT implementations. But it requires side effect free
pipelines.
> D2) The XYZTransformer is a memory hog on large documents, as it loads
> the document in memory so that the expression evaluator can process it
> easily (AFAIK the current XSLT processors do the same in many cases,
> however, so this might not really be a problem).
AFAIK current XSLT processors buffers input in all cases. With our own
transformer we can do much better.
> D3) Why so many steps? Generating XHTML directly could have saved
> some. But it doesn't help for RSS or WAP/WML, and the generation is
> actually much more complicated than what we see here, as configuration
> files and site menu definitions need to be aggregated in the page,
> with different variants depending on the final presentation target.
IMHO, the number of steps should depend on the result from ones analysis
of what concern area that are involved in the problem area at hand,
rather on some predefined idea about that an pipeline _always_ should
consist of one generator, one transformer and one serializer.
<snip/>
> XSLT is *the* stumbling block today,
Yes, many people hate it.
--oo--
BTW: I'm becoming more and more worried about the attribute template
sytax that you used in your examples ;)
/Daniel
Re: [Design] JXTG 2.0 (generator and transformer, same template syntax?)
Posted by Stefano Mazzocchi <st...@apache.org>.
Roy G. Biv wrote:
> I'm almost afraid to bring this up since I'm coming from a point of view
> where I actually like XSLT. Yes, I'm one of *those* people. ;-)
>
> But when I saw this:
>
>> Bertrand Delacretaz wrote:
>>
>>> Then, Bob, who's in charge of the final presentation, writes another
>>> template to convert this logical document to, say, "lightweight
>>> HTML", for an embedded terminal (no CSS). This gets processed by the
>>> XYZTransformer, which uses the same template and expression engines,
>>> and the same syntax as the XYZGenerator (again, don't worry about
>>> syntax details):
>>>
>>> <html>
>>> <head><title>${page/title}</title></head>
>>> <body>
>>> <table>
>>> <tr tl:iter="p in page/person-list">
>>> <td>${p/name}</td>
>>> <td>${p/age}</td>
>>> </tr>
>>> </table>
>>> </body>
>>> </html>
>>
>>
>
> Aside from missing the "tl" namespace declaration, I was curious if
> people are keeping in mind that the equivalent XSLT stylesheet is:
>
> <html xsl:version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
> <head><title><xsl:value-of select="page/title"/></title></head>
> <body>
> <table>
> <xsl:for-each select="page/person-list">
> <tr>
> <td><xsl:value-of select="name"/></td>
> <td><xsl:value-of select="age"/></td>
> </tr>
> </xsl:for-each>
> </table>
> </body>
> </html>
>
> This is an XSLT 1.0 literal result element as stylesheet.
> (http://www.w3.org/TR/xslt#result-element-stylesheet)
>
> I wanted to point out that XSLT can be used in the same (procedural)
> model as is being proposed in the two-step template models. More
> elements and fewer dollar signs though. It also leaves the door open
> for more complex transformations if needed (using full XSLT) and allows
> the documentation load to be distributed by other projects. That and
> XSLT transformers have already been performance tuned.
>
> Don't get me wrong, I like the attribute syntax as much as the next guy.
>
> Just saying...
Yes, we are aware of this. It does feel askward, to be honest, to have
an XSLT generator, some groups really should buy my FS alarms ;-)
[Bertrand, I just built a new one, and it's way more sensible and
resistent too, and recharges itself when spots signs of FS... it will
never run out of batteries overhere ;-)]
--
Stefano.
Re: [Design] JXTG 2.0 (generator and transformer, same template syntax?)
Posted by "Roy G. Biv" <mi...@pcextremist.com>.
I'm almost afraid to bring this up since I'm coming from a point of view
where I actually like XSLT. Yes, I'm one of *those* people. ;-)
But when I saw this:
> Bertrand Delacretaz wrote:
>
>> Then, Bob, who's in charge of the final presentation, writes another
>> template to convert this logical document to, say, "lightweight
>> HTML", for an embedded terminal (no CSS). This gets processed by the
>> XYZTransformer, which uses the same template and expression engines,
>> and the same syntax as the XYZGenerator (again, don't worry about
>> syntax details):
>>
>> <html>
>> <head><title>${page/title}</title></head>
>> <body>
>> <table>
>> <tr tl:iter="p in page/person-list">
>> <td>${p/name}</td>
>> <td>${p/age}</td>
>> </tr>
>> </table>
>> </body>
>> </html>
>
Aside from missing the "tl" namespace declaration, I was curious if
people are keeping in mind that the equivalent XSLT stylesheet is:
<html xsl:version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<head><title><xsl:value-of select="page/title"/></title></head>
<body>
<table>
<xsl:for-each select="page/person-list">
<tr>
<td><xsl:value-of select="name"/></td>
<td><xsl:value-of select="age"/></td>
</tr>
</xsl:for-each>
</table>
</body>
</html>
This is an XSLT 1.0 literal result element as stylesheet.
(http://www.w3.org/TR/xslt#result-element-stylesheet)
I wanted to point out that XSLT can be used in the same (procedural)
model as is being proposed in the two-step template models. More
elements and fewer dollar signs though. It also leaves the door open
for more complex transformations if needed (using full XSLT) and allows
the documentation load to be distributed by other projects. That and
XSLT transformers have already been performance tuned.
Don't get me wrong, I like the attribute syntax as much as the next guy.
Just saying...
- Miles Elam
Re: [Design] JXTG 2.0 (generator and transformer, same template syntax?)
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 7 déc. 04, à 00:41, Stefano Mazzocchi a écrit :
> Bertrand Delacretaz wrote:
>
...
>> -oo-
>> Advantages:
>> A1) There's only one implementation of the template and expression
>> evaluation mechanisms.
>
> Ok
>
>> A2) Bob can ask Alice for help with the templates, she knows them in
>> and out as that's what she's using as well.
>
> Fair enough.
>
>> A3) Bob, coming from a ColdFusion/ASP/PHP background, quickly became
>> productive with the template language, which looks familiar. In a
>> pinch, he can ask the trainee to make minor changes in DreamWeaver,
>> in fact they saved a bunch by doing the prototype in this way.
>
> Again, fair enough.
>
>> A4) The XML logical document will "never" change once it's done, as
>> it contains all the data in presentation-independent format. Write
>> it, test it, forget about it. Alice doesn't want the critical parts
>> of their system to change too often.
>
> Yes, good strategy. It also allows this stage to be reused for another
> channel (say RSS feeds and the like).
>
>> A5) The XML logical document can be reused to publish the RSS feed,
>> the mobile WAP/WML version, the full-blown XHTML/CSS version, without
>> bothering Alice who's a busy and expensive person.
>
> Damn, should read all of it before replying ;-)
>
>> A6) Alice doesn't have to deal with the final customer who's always
>> asking for "just a small change in the page layout". She leaves this
>> to Bob for now, but they've considered training the customer to do
>> this on his own, the templates are simple and isolated enough that he
>> couldn't break anything anyway.
>
> Right.
>
> I have to say, as much as you arguments are convincing A4/A5/A6 are
> simply indicating why pipelines are useful, not why a common syntax
> between a generator and a transformer is ;-)
Ok, but A6 is also a strong argument for having a *simple to use*
template mechanism that can be used for presentation stuff.
> ...Your point (and interestingly enough Miles') is that having the
> same syntax for generation and transformation allows for A2 and A3...
Yes, and also - this is very important - a *single implementation* for
both of Alice's and Bob's concern. One set of tests, one set of docs,
big savings overall. You just said OK to A1 but for me it's "great -
big savings" ;-)
> ....My point is not if it's a good thing, my question is: can it be
> achievable without reinventing XSLT/STX and therefore without coming
> across with the same problems that it has and making it ackward to use
> for one side because we forced it to be the same on the other side?..
Very true. I believe it is doable *with some limitations*.
If the new template language covers 95% of the use cases, we still have
XSLT and custom (java) generators for the remaining 5%. Me, I *love*
XSLT for complex stuff that deserves using it, but it took me a while
to really grasp it.
The new template language just needs to be good enough to enable the
Alice and Bob scenario in common cases, no need to cover everything, as
there are alternatives for the really complex cases.
>> Disadvantages:
>> D1) The XYZTransformer is probably slower than a well-written XSLT
>> transform. But it's also much faster than the XSLT transform that Bob
>> tried to write. He's only been doing XSLT for four weeks and just
>> plain hates it.
>
> :-)
>
> Fair enough. But really, here your real point is that XSLT is painful
> and I can't agree more. But do you really think we can come up with
> something that doesn't end up looking just like STX?
I think so - if we take TAL [1] as an example (for the available
operations, I don't care about the syntax details at this point), I
don't see anything missing, knowing that the pipeline is meant to start
with Flowscript where you can prepare data if needed to make things
easier.
>> ...D4) Bob was initially confused about this generator/transformer
>> thing, why both? Alice told him not to worry, generators are not his
>> business anyway, he's only a Cocoon Transformer Template Designer
>> (but a good one after only four weeks here). He'll understand when he
>> grows up ;-)
>
> Sure, but the question is: once the syntax starts to get ugly for both
> because of changes we made to the language that make sense only on
> transformation and not on generation, would it still be the case?
>
> remember that the generation stage has a scripted population stage
> first, the transformation stage does not!...
Not sure what you mean by scripted population stage. In both cases we
need iterations, if statements and output/formatting expressions,
anything more?
Do you see anything missing in Daniel's proposal at
http://wiki.apache.org/cocoon/AttributeTemplates ? I see stuff that we
might not need (for loops maybe), but nothing missing IMHO.
>> ... -oo-
>> So, what's wrong with this? Where's the FS?
>
> The FS is in what I wrote above: it would be *nice* to have a *simple*
> language that was able to do both, but I've seen many people trying
> and failing because the details make it look ugly fast, and if you
> make it prettier for one stage you make it uglier for the other.
>
> But you are right on one thing: I should not criticize before having
> seen such a language ;-)
Agreed. Given the energy poured into this recently, it looks like we're
not far from an actual implementation. Then we can see how nice or ugly
it looks in the Alice/Bob scenario.
>
>> ...I might be overlooking something but this could pave a much easier
>> path for people to jump into Cocoon and *stay*, not run away scared
>> by XSLT.
>
> As I said previously, I very much agree that we need an easier (read:
> simpler and non turing-complete) xml transformation language,
> something that was more procedural than declarative...
Good, /me happy. I'd just add that it must not look like a language,
but like *page-based templates*. Makes a big difference for people
coming from "dynamic web publishing tools" country. We must get people
to write XML transformations without knowing it ;-)
> ...Whether or not this needs to use the exact same syntax of the
> template system is yet to be decided...
Right, but as we seem to agree that having the same syntax and more
importantly sharing components is a plus, we should keep this in the
back of our collective mind in the design discussions.
> BTW, this whole discussion reminds me of DVSL:
>
> [http://jakarta.apache.org/velocity/dvsl/users-guide.html]...
Hmmm...IIUC DVSL uses the same "event template" model as XSLT, which
confuses many people. Moving to a "page template" model makes the
transformation process much more natural for people, although it won't
cover all transformation cases. But XSLT is still there when we need
it.
>> ...XSLT is *the* stumbling block today, and IMHO we don't have a good
>> alternative to suggest. I don't mean to reinvent it, but as people
>> are working on improved templates anyway, this looks like a cheap but
>> very welcome addition.
>
> All right, I rest my case: I'll see what we can come up with, but I
> hope that you guys are able to cut the rope between the generator and
> the transformer if it gets ugly enough...
Good, something to keep in mind: same generator/transformer template
syntax would be good if it's not too costly in terms of implementation
and "language coolness".
-Bertrand
[1] http://www.zope.org/Wikis/DevSite/Projects/ZPT/TAL
[RT] MVC Contexts (Was Re: [Design] JXTG 2.0 (generator and transformer,
same template syntax?))
Posted by "Roy G. Biv" <mi...@pcextremist.com>.
This one is long folks. Sorry, can't be helped.
Sylvain Wallez wrote:
> Stefano Mazzocchi wrote:
>
>> Sure, but the question is: once the syntax starts to get ugly for
>> both because of changes we made to the language that make sense only
>> on transformation and not on generation, would it still be the case?
>>
>> remember that the generation stage has a scripted population stage
>> first, the transformation stage does not!
>
> I don't see this distinction: if you look at the global processing
> chain, there is always a population stage in front of the template
> engine:
>
> 1/ template as a generator
>
> +------------+ +-----------+
> + Flowscript |--(objects)-->| Template |----> ...
> + data | | generator |
> +------------+ +-----------+
> ^
> |
> Template file
>
> 2/ template as a transformer
>
> +-----------+ +-------------+
> | Generator |--(xml data)-->| Template |----> ...
> | | | transformer |
> +-----------+ +-------------+
> ^
> |
> Template file
>
> Where is the difference? The template lays out some data. In the case
> of the generator, it's controller-provided data, in the case of the
> transformer, it's pipeline-produced data. Note that is not limited to
> a generator, but can also be aggregation, prior transformation, etc,
> or even some preliminary processing of some controller-provided data.
>
> <snip/>
Is this indeed the case? The flow data is, strictly speaking in this
case, the model? The template *may or may not* follow the flow data
structure closely. In fact, the flow data is merely a hint or an
indicator. The template file has the final say on the data structure.
You can send the exact same flow data via sendPage* to two different
JXTG template pipelines and get functionally different XML structures
(depending on which objects are accessed and how).
MVC contexts. That's my new buzzword for the day.
When you pull an RSS feed from another site for inclusion in your own
site, what is that RSS feed to you? A model right? But to the remote
site, the RSS is a view (to a remote database for example), not a
model. It's the final form for others to use. But it's still RSS data
isn't it? How can it be both a model and a view? Because it's used in
a different context. The web browser is the same thing. To Cocoon,
HTML is absolutely the view. But to a web browser, it's the model. The
HTML renderer+CSS is the view, and the client-side Javascript is clearly
the controller. Isn't this all true and MVC is actually dependant upon
the scope of the problem at hand.
In a high-level view of Cocoon, the model is the object model (Hibernate
et al.), the view is the pipeline, and the controller is Flow. But what
is a generator in a pipeline? The model? But the model from Cocoon
came from Flow? But the pipeline is under no obligation to use that
data from Flow. It can use a subset of that data, iterate a data
structure multiple times or ignore the data altogether. In addition, it
has access to data that Flow didn't give it (Actions).
So while it is the view for Cocoon at large, it is in fact it's own MVC
context that grabs data as needed just as a client-side Javascript can
grab updated information from the server without refreshing the main
page (GMail). Who decides if that data is to be used? The pipeline
logic as controller. (Ack!) The generator determines which template to
use. In the case of JXTG, it loads the template file *and* injects
data. The difference between displaying a template file raw or with
data is the choice of pipeline components in the sitemap, not Flow.
Flow can only produce it's "view" of the working data set and request a
particular pipeline that presumably would put that data structure to
good use. The pipeline is the controller here.
A browser makes separate requests for the HTML, Javascript files and CSS
stylesheets to produce the final view for your pleasure. You don't see
the MVC in a browser, you see the result of the MVC, the view. Wasn't
this the entire point of the last ten years of the W3C? To specify HTML
as a model, Javascript as a controller and CSS as a view? In a
different MVC context of course. ;-)
So in a pipeline MVC context you have a model, the inital XML (static or
a template) that determines the initial structure of the data events
(generating SAX events where there previously were none), the controller
with modular logic (pipeline-specified transformers and actions), and
the serializer as view (what the outside world sees).
Cocoon had MVC before the advent of Flow. It simply had a single
complete MVC context. Flow gave rise to a new concept I've heard on
this list repeatedly, MVC+. But are we really defining M, V, C and some
new, unnamed letter/symbol? I think rather a new MVC context has been
born -- or rather that the high level view of Cocoon has finally
achieved true MVC -- and it's highly unusual because it occurs within
the same application server context rather than in separate
processes/machines as was the case with extenal RSS feeds and web browsers.
When you specify the following pipeline matcher
<map:match pattern="*.html">
<map:generate type="file" src="{1}.xml"/>
<map:transform type="xslt" src="xml2html"/>
<map:serialize type="xhtml"/>
</map:match>
What's the controller? I believe it's the pipeline assembly. The
actions and the transformers. The view? The serializer. The model?
Why, the XML document of course. But can't XSLT stylesheets put in all
sorts of new data either through includes or just by putting the data
hard-coded in the primary stylesheet? The above pipeline doesn't cover
the case where a stylesheet simply produces other non-presentational XML
as part of processing -- injecting new data into the model. Doesn't
I18nTransformer commonly get locale information from an input module and
grab data from external catalogs to augment what's already there? And
actions? Generating new data and injecting it into the pipeline at
arbitrary points.
The generator defines the data model, right. The template file is the
initial data structure model though. Sure, it's "waiting" for data
injection, but isn't a template with i18n attributes doing the same?
Once again, if the pipeline is changed in the sitemap to a static
pipeline as listed above, doesn't the call to sendPage* still work?
Hell, if anything, the template generator is it's own MVC context. The
Flow objects as model, the template as controller and the output as view.
But the sitemap doesn't reflect this.
<map:generate type="jx" src="mytemplate.jx"/>
In every other context, "src" refers to the model. Now that it's being
called by Flow, it's the controller. Well... If you use JXTG, it's the
controller. Otherwise, it's still specifying the model -- the input source.
So what were the advantages of template transformers again?
<map:match pattern="*.html">
<map:generate type="file" src="{1}.xml"/>
<map:transform type="macro-expansion"/>
<map:transform type="template"/>
<map:transform type="lenses"/>
<map:transform type="xslt" src="doc2html"/>
<map:serialize type="xhtml"/>
</map:match>
And what is lost? Well, complexity for one. The template transformer
has to worry about data -- values and iteration -- and nothing else.
The macro expansion, taglib, Eugene engine can be a Tag java inteface
with a lookup catalog, a set of stylesheets, or whatever is technically
superior without having to muck with the template component code. Not
just making them more modular and easily "pluggable". Pulling them out
altogether and letting the site administrator sort it out through the
sitemap. Letting the site administrator determine how data goes through
the pipeline and gets processed was the management intention behind the
sitemap, wasn't it?
Sticking with the "template processor must be a generator" mindset I
think misses the fact that it has already lost the strictly clean MVC
war. While I think what I've suggested would be better, it's actually
immaterial. I'm simply saying that we shouldn't necessarily be locking
ourselves into past decisions because I'm not entirely convinced they
were the right ones or based on logical necessity. This is true because
of the use of the "src" attribute, the fact that MVC is in fact
compartmentalized and Flow's data injection role in the pipeline
architecture.
- Miles "More Fuel For the Fire" Elam
Re: [Design] JXTG 2.0 (generator and transformer, same template syntax?)
Posted by Sylvain Wallez <sy...@apache.org>.
Stefano Mazzocchi wrote:
> Bertrand Delacretaz wrote:
<snip/>
>> D4) Bob was initially confused about this generator/transformer
>> thing, why both? Alice told him not to worry, generators are not his
>> business anyway, he's only a Cocoon Transformer Template Designer
>> (but a good one after only four weeks here). He'll understand when he
>> grows up ;-)
>
>
> Sure, but the question is: once the syntax starts to get ugly for both
> because of changes we made to the language that make sense only on
> transformation and not on generation, would it still be the case?
>
> remember that the generation stage has a scripted population stage
> first, the transformation stage does not!
I don't see this distinction: if you look at the global processing
chain, there is always a population stage in front of the template engine:
1/ template as a generator
+------------+ +-----------+
+ Flowscript |--(objects)-->| Template |----> ...
+ data | | generator |
+------------+ +-----------+
^
|
Template file
2/ template as a transformer
+-----------+ +-------------+
| Generator |--(xml data)-->| Template |----> ...
| | | transformer |
+-----------+ +-------------+
^
|
Template file
Where is the difference? The template lays out some data. In the case of
the generator, it's controller-provided data, in the case of the
transformer, it's pipeline-produced data. Note that is not limited to a
generator, but can also be aggregation, prior transformation, etc, or
even some preliminary processing of some controller-provided data.
<snip/>
> BTW, this whole discussion reminds me of DVSL:
>
> [http://jakarta.apache.org/velocity/dvsl/users-guide.html]
There is a huge difference with DVSL: just like XSLT, DVSL is a
rule-driven declarative language. This is what scares most people in
XSLT (although from my trainer's experience, it's not that hard to
learn). The template language we're talking about is purely procedural.
>> -Bertrand, enjoying the debate...
>
Me too, even if it's hard to follow :-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [Design] JXTG 2.0 (generator and transformer, same template syntax?)
Posted by Stefano Mazzocchi <st...@apache.org>.
Bertrand Delacretaz wrote:
> Le 5 déc. 04, à 06:14, Stefano Mazzocchi a écrit :
>
>> Bertrand Delacretaz wrote:
>>
>>> ...That's what I mean - having a transformer that can use the same
>>> template syntax as used in the generator, so that the template
>>> language can be used for both the generation and transformation steps.
>>
>>
>> My FS detector is out of scale!!
>
> Hmmm...maybe it needs a battery change after working too hard in the
> last few days ;-)
Better yet: I'll buy a new one since the old one, as you pointed out,
exploded ;-)
[mental image of stefano, smoked head and gray face, all covered in dust]
> Let me clarify with a concrete story: we start with a few beans passed
> to sendPage, including a Collection of Person objects.
All right, here we go...
> Alice writes a template for the XYZGenerator (our new attribute-based
> template language), which receives the beans and generates an XML
> document based on this template (syntax details are irrelevant for this
> discussion):
>
> <page title="Persons">
> <person-list tl:iter="p in personCollection">
> <person>
> <name>${p/name}</name>
> <age>${p/age}</age>
> </person>
> </person-list>
> </page>
>
> At which point she gets an XML "data view" or "logical document" and
> passes it downstream for publishing.
Great.
> Then, Bob, who's in charge of the final presentation, writes another
> template to convert this logical document to, say, "lightweight HTML",
> for an embedded terminal (no CSS). This gets processed by the
> XYZTransformer, which uses the same template and expression engines, and
> the same syntax as the XYZGenerator (again, don't worry about syntax
> details):
>
> <html>
> <head><title>${page/title}</title></head>
> <body>
> <table>
> <tr tl:iter="p in page/person-list">
> <td>${p/name}</td>
> <td>${p/age}</td>
> </tr>
> </table>
> </body>
> </html>
hmmmm
> The XYZTransformer receives the XML produced by the XYZGenerator, reads
> the above template from disk (or from the output of another pipeline),
> and generates the HTML.
Right.
> -oo-
>
> Advantages:
> A1) There's only one implementation of the template and expression
> evaluation mechanisms.
Ok
> A2) Bob can ask Alice for help with the templates, she knows them in and
> out as that's what she's using as well.
Fair enough.
> A3) Bob, coming from a ColdFusion/ASP/PHP background, quickly became
> productive with the template language, which looks familiar. In a pinch,
> he can ask the trainee to make minor changes in DreamWeaver, in fact
> they saved a bunch by doing the prototype in this way.
Again, fair enough.
> A4) The XML logical document will "never" change once it's done, as it
> contains all the data in presentation-independent format. Write it, test
> it, forget about it. Alice doesn't want the critical parts of their
> system to change too often.
Yes, good strategy. It also allows this stage to be reused for another
channel (say RSS feeds and the like).
> A5) The XML logical document can be reused to publish the RSS feed, the
> mobile WAP/WML version, the full-blown XHTML/CSS version, without
> bothering Alice who's a busy and expensive person.
Damn, should read all of it before replying ;-)
> A6) Alice doesn't have to deal with the final customer who's always
> asking for "just a small change in the page layout". She leaves this to
> Bob for now, but they've considered training the customer to do this on
> his own, the templates are simple and isolated enough that he couldn't
> break anything anyway.
Right.
I have to say, as much as you arguments are convincing A4/A5/A6 are
simply indicating why pipelines are useful, not why a common syntax
between a generator and a transformer is ;-)
Don't try to throw smoke at my eyes, it doesn't work on these things.
Your point (and interestingly enough Miles') is that having the same
syntax for generation and transformation allows for A2 and A3.
Now, let me discuss about that since this is the exact same argument
that I had with Scott Boag when he was saying that we didn't need XSP
because XSLT was capable of doing the exact same (it just neede
extensions... just another name for taglibs <grin>).
First, I do think that A1 (therefore A2 and A3) is a loudable goal. No
questions about it.
My point is not if it's a good thing, my question is: can it be
achievable without reinventing XSLT/STX and therefore without coming
across with the same problems that it has and making it ackward to use
for one side because we forced it to be the same on the other side?
> Disadvantages:
> D1) The XYZTransformer is probably slower than a well-written XSLT
> transform. But it's also much faster than the XSLT transform that Bob
> tried to write. He's only been doing XSLT for four weeks and just plain
> hates it.
:-)
Fair enough. But really, here your real point is that XSLT is painful
and I can't agree more. But do you really think we can come up with
something that doesn't end up looking just like STX?
> D2) The XYZTransformer is a memory hog on large documents, as it loads
> the document in memory so that the expression evaluator can process it
> easily (AFAIK the current XSLT processors do the same in many cases,
> however, so this might not really be a problem).
Right. Xalan can do streaming mode (and STX should make it easier, in
theory) but both are theoretical.
> D3) Why so many steps? Generating XHTML directly could have saved some.
> But it doesn't help for RSS or WAP/WML, and the generation is actually
> much more complicated than what we see here, as configuration files and
> site menu definitions need to be aggregated in the page, with different
> variants depending on the final presentation target.
No, we don't need to debate that. I personally like to use XHTML even
for the first stage and do a bunch of copyovers in the stylesheets down
the road, but that's just me (I'm lazy)
> D4) Bob was initially confused about this generator/transformer thing,
> why both? Alice told him not to worry, generators are not his business
> anyway, he's only a Cocoon Transformer Template Designer (but a good one
> after only four weeks here). He'll understand when he grows up ;-)
Sure, but the question is: once the syntax starts to get ugly for both
because of changes we made to the language that make sense only on
transformation and not on generation, would it still be the case?
remember that the generation stage has a scripted population stage
first, the transformation stage does not!
> -oo-
>
> So, what's wrong with this? Where's the FS?
The FS is in what I wrote above: it would be *nice* to have a *simple*
language that was able to do both, but I've seen many people trying and
failing because the details make it look ugly fast, and if you make it
prettier for one stage you make it uglier for the other.
But you are right on one thing: I should not criticize before having
seen such a language ;-)
> I might be overlooking something but this could pave a much easier path
> for people to jump into Cocoon and *stay*, not run away scared by XSLT.
As I said previously, I very much agree that we need an easier (read:
simpler and non turing-complete) xml transformation language, something
that was more procedural than declarative.
Whether or not this needs to use the exact same syntax of the template
system is yet to be decided.
BTW, this whole discussion reminds me of DVSL:
[http://jakarta.apache.org/velocity/dvsl/users-guide.html]
> XSLT is *the* stumbling block today, and IMHO we don't have a good
> alternative to suggest. I don't mean to reinvent it, but as people are
> working on improved templates anyway, this looks like a cheap but very
> welcome addition.
All right, I rest my case: I'll see what we can come up with, but I hope
that you guys are able to cut the rope between the generator and the
transformer if it gets ugly enough.
> -Bertrand, enjoying the debate...
Happy that's the case ;-)
--
Stefano.