You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Ralph Goers <Ra...@dslextreme.com> on 2004/12/03 20:33:03 UTC
Re: [Design] JXTG 2.0 (Just my opinion)
Stefano Mazzocchi said:
>
> <-- stuff removed -->
>
> ${myDate as month}
>
> <-- stuff removed -->
> --
> Stefano.
Not that I disagree with you, but why don't you consider your example to
be a taglib? Perhaps I'm just reading more generality into the
discussions than is really there, but I haven't seen anyone state that
"taglibs" must be of the form <namespace:op namespace:attr="token">, etc.
Frankly, the part that has worried me the most is the discussion of SQL
and templates in the same email. From my perspective SQL queries are
part, of or simply are, the model. Templates, on the other hand are
generally part of the view. Although they may be used in an intermediate
step to reformat the data in the model, this is just a smaller version of
MVC where the view is the reformatted data.
In other words, templates that do anything other than accessing already
available data and rendering "formatted" data should a) not be possible,
or b) be discouraged. Notice "already available data". That means you
shouldn't have tag libraries or whatever that do the SQL query, invoke
business methods or whatever. That should all be done via business methods
invoked by actions or flow (i.e. the controller).
Ralph
Ralph
Re: [Design] JXTG 2.0 (Just my opinion)
Posted by Glen Ezkovich <ge...@mac.com>.
On Dec 4, 2004, at 2:49 PM, Bertrand Delacretaz wrote:
> Le 4 déc. 04, à 21:03, Glen Ezkovich a écrit :
>
>>
>> On Dec 4, 2004, at 3:37 AM, Bertrand Delacretaz wrote:
>>> ...Currently we have JXTG for the first step, and mostly XSLT for
>>> the second. Having something that could cover both steps and be
>>> usable by either programmers working on the first step or designers
>>> working on the second would be a Really Good Thing.
>>
>> I'm not really sure what you mean by having something that could
>> cover both steps. JXTG covers both steps in the sense that many
>> people are using it to inject their data into their html. Now, to
>> have a template transformer, that is something with which I would
>> really like to play. I'm not very found of XSL. A simpler alternative
>> could be a Really, Really Good Thing.
>
> 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.
Thats what I assumed based on previous post. Just making sure. :-)
>
> -Bertrand
>
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: [Design] JXTG 2.0 (Just my opinion)
Posted by Ralph Goers <Ra...@dslextreme.com>.
Roy G. Biv wrote:
> However useless the action may be, calling sendPage* on a pipeline
> without JXTG still produces (generates) output doesn't it? I'm not
> trying to be difficult, even though it may seem so.
To be honest, I wouldn't know. I haven't coded flowscript, and my
coworkers who have use Velocity, not JXTG. They find it difficult to
generate XML since the template has to be well formed XML. We do use
JXTG in other circumstances, but not with flow.
>
> If you can have a pipeline that ignores the object model passed from
> Flow, how can that object model be automatically considered an
> intrinsic part of generation?
Because once you invoked sendPage you switched from accessing the model
to generating the view.
> The Flow object model is available to components further down the
> pipeline too isn't it?
So what? I don't mean to be argumentative, but I think you are looking
at this way to granularly. We have some complicated pipelines, but when
you look at them the MVC pattern is still there, both in the overall
structure and in individual pipelines.
>
>>> With XSLT/STX, the stylesheet is the manipulative/transformative
>>> vector. With a flow template transformer, it's the flow object
>>> model. With the i18n transformer, it's the l10n catalog(s).
>>
>>
>>
>> I don't understand this. With these examples the
>> "manipulative/ransformative vector" is the template, not the object
>> model. That is what is being operated upon. All of the above are
>> transformers and the all operate the same way; they are fed SAX
>> events and output SAX events based upon the XSLT Stylesheet, the
>> template, or the I18n elements.
>
>
> Okay, aside from my obfuscated terminology, how is that true of the
> I18Transformer? It takes SAX events (just like a template transformer
> would if the template file were read in from the FileGenerator), but
> it's catalog data, while stored on the filesystem in XML files, is not
> read in as a SAX stream; it's an injected data model. The fact that
> the catalog files are stored as XML is an implentation detail, not
> part of the SAX processing pipeline.
I would argue that in transformers the model is always the incoming SAX
events. The fact that catalog data is accessed by the I18nTransformer
doesn't make it part of the model any more than saying the html embedded
in an XSLT stylesheet is part of the model.
>
> If you were to load a .jx template in the FileGenerator, it's still
> data. It's still a starting point whether or not there's a Flow bean
> awaiting iteration. Does JXTG start processing by handling the Flow
> objects or by reading and parsing the template file.
All generators generate SAX events from a model. They have to do that
based upon instructions. I use Betwixt to convert beans into XML. That
doesn't make Betwixt's processing rules part of the model. The JX
template is nothing more than the rules the generator is to use to
generate SAX events from the model. The starting point is the model,
not the template. Also, when loading the template in a generator it is
the model at that point. However, it could then be passed through
transforms and must be serialized before being used by JXTG. In other
words, the template is the model in the pipeline where it is passed to
JXTG, but it has been fully rendered (usually identically) when it is
used by JXTG.
While this discussion is important in the overall scheme of things, I
don't think it helps at all with determing what the syntax for the
template processor should look like or how it should operate. Except, I
guess, in pointing out that the major flaw in XSP (and JSP) is that they
are simply too powerful in that they encourage too much mixing of
concerns. Frankly, I have worries about Flow for the same reason.
Ralph
Re: [Design] JXTG 2.0 (Just my opinion)
Posted by "Roy G. Biv" <mi...@pcextremist.com>.
Ralph Goers wrote:
> Why would it begin with loading the template? The process begins with
> the controller accessing the model and then making a determination of
> what to do next. It might need to go back to the model to obtain
> another piiece of information to display an alternate screen before
> displaying the one it collected the inital data for, for example.
>
> The template should only be accessed when the data is ready to be
> manipulated, not before.
However useless the action may be, calling sendPage* on a pipeline
without JXTG still produces (generates) output doesn't it? I'm not
trying to be difficult, even though it may seem so.
If you can have a pipeline that ignores the object model passed from
Flow, how can that object model be automatically considered an intrinsic
part of generation? The Flow object model is available to components
further down the pipeline too isn't it?
>> With XSLT/STX, the stylesheet is the manipulative/transformative
>> vector. With a flow template transformer, it's the flow object
>> model. With the i18n transformer, it's the l10n catalog(s).
>
>
> I don't understand this. With these examples the
> "manipulative/ransformative vector" is the template, not the object
> model. That is what is being operated upon. All of the above are
> transformers and the all operate the same way; they are fed SAX events
> and output SAX events based upon the XSLT Stylesheet, the template, or
> the I18n elements.
Okay, aside from my obfuscated terminology, how is that true of the
I18Transformer? It takes SAX events (just like a template transformer
would if the template file were read in from the FileGenerator), but
it's catalog data, while stored on the filesystem in XML files, is not
read in as a SAX stream; it's an injected data model. The fact that the
catalog files are stored as XML is an implentation detail, not part of
the SAX processing pipeline.
If you were to load a .jx template in the FileGenerator, it's still
data. It's still a starting point whether or not there's a Flow bean
awaiting iteration. Does JXTG start processing by handling the Flow
objects or by reading and parsing the template file.
Data injection is secondary. Important, but secondary.
- Miles Elam
Re: [Design] JXTG 2.0 (Just my opinion)
Posted by Ralph Goers <Ra...@dslextreme.com>.
Roy G. Biv wrote:
> Stefano Mazzocchi wrote:
>
>> No, I disagree: there is a place for generation and there is a place
>> for transformation. They are different things and both have a reason
>> to exist.
>
>
> I see where the statement comes from, but doesn't processing begin by
> loading the template file? Data injection from flow is step 2.
> Loading the template file seems like the generation step to me, not
> the data injection.
Why would it begin with loading the template? The process begins with
the controller accessing the model and then making a determination of
what to do next. It might need to go back to the model to obtain another
piiece of information to display an alternate screen before displaying
the one it collected the inital data for, for example.
The template should only be accessed when the data is ready to be
manipulated, not before.
>
> With XSLT/STX, the stylesheet is the manipulative/transformative
> vector. With a flow template transformer, it's the flow object
> model. With the i18n transformer, it's the l10n catalog(s).
I don't understand this. With these examples the
"manipulative/ransformative vector" is the template, not the object
model. That is what is being operated upon. All of the above are
transformers and the all operate the same way; they are fed SAX events
and output SAX events based upon the XSLT Stylesheet, the template, or
the I18n elements.
>
> Your dividing line seems somewhat arbitrary. What am I missing?
I don't think it is arbitrary at all.
Ralph
Re: [Design] JXTG 2.0 (Just my opinion)
Posted by "Roy G. Biv" <mi...@pcextremist.com>.
Stefano Mazzocchi wrote:
> No, I disagree: there is a place for generation and there is a place
> for transformation. They are different things and both have a reason
> to exist.
I see where the statement comes from, but doesn't processing begin by
loading the template file? Data injection from flow is step 2. Loading
the template file seems like the generation step to me, not the data
injection.
With XSLT/STX, the stylesheet is the manipulative/transformative
vector. With a flow template transformer, it's the flow object model.
With the i18n transformer, it's the l10n catalog(s).
Your dividing line seems somewhat arbitrary. What am I missing?
- Miles Elam
Re: [Design] JXTG 2.0 (Just my opinion)
Posted by Stefano Mazzocchi <st...@apache.org>.
Roy G. Biv wrote:
> 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.
>
>
> Aren't you really talking about just a transformer then? The current
> role of generator would be handled by a FileGenerator loading the
> template for processing by the transformer. The processing model would
> be kept with the SourceValidity object -- possiblity for reuse whenever
> the previous parts of the pipeline are cacheable.
>
> Then the generator simply becomes a virtual one:
>
> <map:generator name="template">
> <map:absolutize param="templatename"/>
> <map:generate type="file" src="{templatename}.xml"/>
> <map:transform type="template"/>
> </map:generator>
>
> A two for one! Only one codebase to maintain. Nothing to keep in sync.
No, I disagree: there is a place for generation and there is a place for
transformation. They are different things and both have a reason to exist.
--
Stefano.
Re: [Design] JXTG 2.0 (Just my opinion)
Posted by "Roy G. Biv" <mi...@pcextremist.com>.
Bertrand Delacretaz wrote:
> I see the idea, but I think the same thing can be done quite easily in
> code by reusing the same processing code in the generator and
> transformer.
To what advantage?
- Miles Elam
Re: [Design] JXTG 2.0 (Just my opinion)
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 4 déc. 04, à 22:11, Roy G. Biv a écrit :
> ....Aren't you really talking about just a transformer then?...
> ...Then the generator simply becomes a virtual one:
>
> <map:generator name="template">
> <map:absolutize param="templatename"/>
> <map:generate type="file" src="{templatename}.xml"/>
> <map:transform type="template"/>
> </map:generator>
>
> A two for one! Only one codebase to maintain. Nothing to keep in
> sync.
I see the idea, but I think the same thing can be done quite easily in
code by reusing the same processing code in the generator and
transformer.
-Bertrand
Re: [Design] JXTG 2.0 (Just my opinion)
Posted by "Roy G. Biv" <mi...@pcextremist.com>.
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.
Aren't you really talking about just a transformer then? The current
role of generator would be handled by a FileGenerator loading the
template for processing by the transformer. The processing model would
be kept with the SourceValidity object -- possiblity for reuse whenever
the previous parts of the pipeline are cacheable.
Then the generator simply becomes a virtual one:
<map:generator name="template">
<map:absolutize param="templatename"/>
<map:generate type="file" src="{templatename}.xml"/>
<map:transform type="template"/>
</map:generator>
A two for one! Only one codebase to maintain. Nothing to keep in sync.
- Miles Elam
Re: [Design] JXTG 2.0 (Just my opinion)
Posted by Sylvain Wallez <sy...@apache.org>.
Stefano Mazzocchi wrote:
> Bertrand Delacretaz wrote:
>
>> Le 4 déc. 04, à 21:03, Glen Ezkovich a écrit :
>>
>>>
>>> On Dec 4, 2004, at 3:37 AM, Bertrand Delacretaz wrote:
>>>
>>>> ...Currently we have JXTG for the first step, and mostly XSLT for
>>>> the second. Having something that could cover both steps and be
>>>> usable by either programmers working on the first step or designers
>>>> working on the second would be a Really Good Thing.
>>>
>>>
>>>
>>> I'm not really sure what you mean by having something that could
>>> cover both steps. JXTG covers both steps in the sense that many
>>> people are using it to inject their data into their html. Now, to
>>> have a template transformer, that is something with which I would
>>> really like to play. I'm not very found of XSL. A simpler
>>> alternative could be a Really, Really Good Thing.
>>
>>
>>
>> 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!!
Ring, ring, ring :-)
> This is *exactly* what the XSLT WG did and failed miserably. XSLT can
> be used for both generation and tranformation. But it looks right for
> one (besides the stupid XML-ish syntax) and totally ackward for the
> other. XQuery is the same thing, only reversed: it can be used as a
> template language, and as a transformation language. If feels better
> for the first one (only ackward because, as usual, the XSLT WG starts
> with one name and ends up defining something else) and totally wrong
> for the second.
>
> Look at my eyes and repeat with me: I DO NOT WANT TO REPEAT THE
> MISTAKES THAT THE XSTL WG DOES OVER AND OVER YEAR AFTER YEAR.
>
> Generation and transformation are two different things, done often by
> different people and for different goals and with different constaints.
>
> Having one language for both will do only harm, because it will make
> it harder for people to decide when to use generation and when to use
> transformation.
Although I agree that using XSLT as a generator feels awkward, the
context of Cocoon is different. XSLT as a transfomer uses an input
document, and XSLT as a generator has no input which makes it look
strange (although it can load data with the infamous document() function).
Now what is the "input document" equivalent in Cocoon? It depends:
- it can be the view data passed to cocoon.sendPage()
- it can also be the output of the generator.
So in the first case, the template is a generator, and in the second
case, the template is a transformer. And in all cases, the template
actually does *transform* a set of data.
So having a template language used either as a generator or a
transformer doesn't seem so awkward to me, as contrarily to W3C specs,
it is always a transformation of some data given by some previous layer
in the processing chain (either the controller or the generator).
Note however that JXTemplateTransformer seems really weird to me as its
input data *is* the template.
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 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.
Re: [Design] JXTG 2.0 (generator and transformer, same template syntax?)
Posted by Bertrand Delacretaz <bd...@apache.org>.
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 (Just my opinion)
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
(please ignore my previous message, hit send too soon ;-)
Le 6 déc. 04, à 07:27, Bertrand Delacretaz a écrit :
...
Re: [Design] JXTG 2.0 (Just my opinion)
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le 5 déc. 04, à 06:14, Stefano Mazzocchi a écrit :
> Bertrand Delacretaz wrote:
>> Le 4 déc. 04, à 21:03, Glen Ezkovich a écrit :
>>>
>>> On Dec 4, 2004, at 3:37 AM, Bertrand Delacretaz wrote:
>>>
>>>> ...Currently we have JXTG for the first step, and mostly XSLT for
>>>> the second. Having something that could cover both steps and be
>>>> usable by either programmers working on the first step or designers
>>>> working on the second would be a Really Good Thing.
>>>
>>>
>>> I'm not really sure what you mean by having something that could
>>> cover both steps. JXTG covers both steps in the sense that many
>>> people are using it to inject their data into their html. Now, to
>>> have a template transformer, that is something with which I would
>>> really like to play. I'm not very found of XSL. A simpler
>>> alternative could be a Really, Really Good Thing.
>> 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!!
>
> This is *exactly* what the XSLT WG did and failed miserably. XSLT can
> be used for both generation and tranformation. But it looks right for
> one (besides the stupid XML-ish syntax) and totally ackward for the
> other. XQuery is the same thing, only reversed: it can be used as a
> template language, and as a transformation language. If feels better
> for the first one (only ackward because, as usual, the XSLT WG starts
> with one name and ends up defining something else) and totally wrong
> for the second.
>
> Look at my eyes and repeat with me: I DO NOT WANT TO REPEAT THE
> MISTAKES THAT THE XSTL WG DOES OVER AND OVER YEAR AFTER YEAR.
>
> Generation and transformation are two different things, done often by
> different people and for different goals and with different
> constaints.
>
> Having one language for both will do only harm, because it will make
> it harder for people to decide when to use generation and when to use
> transformation.
>
> --
> Stefano.
>
>
--
Bertrand Delacretaz
independent consultant, Lausanne, Switzerland
http://www.codeconsult.ch
Re: [Design] JXTG 2.0 (Just my opinion)
Posted by Glen Ezkovich <ge...@mac.com>.
On Dec 4, 2004, at 11:14 PM, Stefano Mazzocchi wrote:
> Bertrand Delacretaz wrote:
>> Le 4 déc. 04, à 21:03, Glen Ezkovich a écrit :
>>>
>>> On Dec 4, 2004, at 3:37 AM, Bertrand Delacretaz wrote:
>>>
>>>> ...Currently we have JXTG for the first step, and mostly XSLT for
>>>> the second. Having something that could cover both steps and be
>>>> usable by either programmers working on the first step or designers
>>>> working on the second would be a Really Good Thing.
>>>
>>>
>>> I'm not really sure what you mean by having something that could
>>> cover both steps. JXTG covers both steps in the sense that many
>>> people are using it to inject their data into their html. Now, to
>>> have a template transformer, that is something with which I would
>>> really like to play. I'm not very found of XSL. A simpler
>>> alternative could be a Really, Really Good Thing.
>> 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!!
>
> This is *exactly* what the XSLT WG did and failed miserably. XSLT can
> be used for both generation and tranformation. But it looks right for
> one (besides the stupid XML-ish syntax) and totally ackward for the
> other. XQuery is the same thing, only reversed: it can be used as a
> template language, and as a transformation language. If feels better
> for the first one (only ackward because, as usual, the XSLT WG starts
> with one name and ends up defining something else) and totally wrong
> for the second.
>
> Look at my eyes and repeat with me: I DO NOT WANT TO REPEAT THE
> MISTAKES THAT THE XSTL WG DOES OVER AND OVER YEAR AFTER YEAR.
>
> Generation and transformation are two different things, done often by
> different people and for different goals and with different
> constaints.
>
> Having one language for both will do only harm, because it will make
> it harder for people to decide when to use generation and when to use
> transformation.
But in both cases here we are talking about templates. I like a two
pass approach. Inject the data into an XML template, then take that
data and inject it into an XHTML template. I prefer this approach
precisely because different people do each each job. Developers handle
generation and designers handle what would be the transformation but in
this case it would/could be pure injection. I don't see a template
transformer as a replacement for XSLT, just as an alternative. It
hopefully will be much simpler.
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: [Design] JXTG 2.0 (Just my opinion)
Posted by Stefano Mazzocchi <st...@apache.org>.
Bertrand Delacretaz wrote:
> Le 4 déc. 04, à 21:03, Glen Ezkovich a écrit :
>
>>
>> On Dec 4, 2004, at 3:37 AM, Bertrand Delacretaz wrote:
>>
>>> ...Currently we have JXTG for the first step, and mostly XSLT for the
>>> second. Having something that could cover both steps and be usable by
>>> either programmers working on the first step or designers working on
>>> the second would be a Really Good Thing.
>>
>>
>> I'm not really sure what you mean by having something that could cover
>> both steps. JXTG covers both steps in the sense that many people are
>> using it to inject their data into their html. Now, to have a
>> template transformer, that is something with which I would really like
>> to play. I'm not very found of XSL. A simpler alternative could be a
>> Really, Really Good Thing.
>
>
> 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!!
This is *exactly* what the XSLT WG did and failed miserably. XSLT can be
used for both generation and tranformation. But it looks right for one
(besides the stupid XML-ish syntax) and totally ackward for the other.
XQuery is the same thing, only reversed: it can be used as a template
language, and as a transformation language. If feels better for the
first one (only ackward because, as usual, the XSLT WG starts with one
name and ends up defining something else) and totally wrong for the second.
Look at my eyes and repeat with me: I DO NOT WANT TO REPEAT THE MISTAKES
THAT THE XSTL WG DOES OVER AND OVER YEAR AFTER YEAR.
Generation and transformation are two different things, done often by
different people and for different goals and with different constaints.
Having one language for both will do only harm, because it will make it
harder for people to decide when to use generation and when to use
transformation.
--
Stefano.
Re: [Design] JXTG 2.0 (Just my opinion)
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 4 déc. 04, à 21:03, Glen Ezkovich a écrit :
>
> On Dec 4, 2004, at 3:37 AM, Bertrand Delacretaz wrote:
>> ...Currently we have JXTG for the first step, and mostly XSLT for the
>> second. Having something that could cover both steps and be usable by
>> either programmers working on the first step or designers working on
>> the second would be a Really Good Thing.
>
> I'm not really sure what you mean by having something that could cover
> both steps. JXTG covers both steps in the sense that many people are
> using it to inject their data into their html. Now, to have a
> template transformer, that is something with which I would really like
> to play. I'm not very found of XSL. A simpler alternative could be a
> Really, Really Good Thing.
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.
-Bertrand
Re: [Design] JXTG 2.0 (Just my opinion)
Posted by Glen Ezkovich <gl...@hard-bop.com>.
On Dec 4, 2004, at 11:06 PM, Stefano Mazzocchi wrote:
> Glen Ezkovich wrote:
>> On Dec 4, 2004, at 3:37 AM, Bertrand Delacretaz wrote:
>>>
>>> Currently we have JXTG for the first step, and mostly XSLT for the
>>> second. Having something that could cover both steps and be usable
>>> by either programmers working on the first step or designers working
>>> on the second would be a Really Good Thing.
>> I'm not really sure what you mean by having something that could
>> cover both steps. JXTG covers both steps in the sense that many
>> people are using it to inject their data into their html. Now, to
>> have a template transformer, that is something with which I would
>> really like to play. I'm not very found of XSL. A simpler alternative
>> could be a Really, Really Good Thing.
>
> we are *NOT* trying to redesign XSLT, nor we are trying to solve the
> problem of creating a more friendly and scriptable SAX transformer
> then the XSLT/STX family.
>
> That is a very interesting problem, but a huge one nevertheless.
I didn't assume that you were.
>
> Let's start with the generator stage first: we'll attack the
> transformer stage after we are done with this one :-)
Agreed. I just think that a refactoring of JXTG will make it easier to
implement a transformer.
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: [Design] JXTG 2.0 (Just my opinion)
Posted by Stefano Mazzocchi <st...@apache.org>.
Glen Ezkovich wrote:
>
> On Dec 4, 2004, at 3:37 AM, Bertrand Delacretaz wrote:
>
>> Le 3 déc. 04, à 21:40, Glen Ezkovich a écrit :
>>
>>> ...I'm not sure I agree that templates as being part of the view. I
>>> look at them more as providing XML structure to the data....
>>
>>
>> We need both actually - if you work with the "two-step view" pattern
>> (which is very natural with Cocoon), you need a first set of templates
>> to generate XML out of your data, and a second set to transform the
>> XML into the final presentation format.
>>
>> Currently we have JXTG for the first step, and mostly XSLT for the
>> second. Having something that could cover both steps and be usable by
>> either programmers working on the first step or designers working on
>> the second would be a Really Good Thing.
>
>
> I'm not really sure what you mean by having something that could cover
> both steps. JXTG covers both steps in the sense that many people are
> using it to inject their data into their html. Now, to have a template
> transformer, that is something with which I would really like to play.
> I'm not very found of XSL. A simpler alternative could be a Really,
> Really Good Thing.
we are *NOT* trying to redesign XSLT, nor we are trying to solve the
problem of creating a more friendly and scriptable SAX transformer then
the XSLT/STX family.
That is a very interesting problem, but a huge one nevertheless.
Let's start with the generator stage first: we'll attack the transformer
stage after we are done with this one :-)
--
Stefano.
Re: [Design] JXTG 2.0 (Just my opinion)
Posted by Glen Ezkovich <ge...@mac.com>.
On Dec 4, 2004, at 3:37 AM, Bertrand Delacretaz wrote:
> Le 3 déc. 04, à 21:40, Glen Ezkovich a écrit :
>> ...I'm not sure I agree that templates as being part of the view. I
>> look at them more as providing XML structure to the data....
>
> We need both actually - if you work with the "two-step view" pattern
> (which is very natural with Cocoon), you need a first set of templates
> to generate XML out of your data, and a second set to transform the
> XML into the final presentation format.
>
> Currently we have JXTG for the first step, and mostly XSLT for the
> second. Having something that could cover both steps and be usable by
> either programmers working on the first step or designers working on
> the second would be a Really Good Thing.
I'm not really sure what you mean by having something that could cover
both steps. JXTG covers both steps in the sense that many people are
using it to inject their data into their html. Now, to have a template
transformer, that is something with which I would really like to play.
I'm not very found of XSL. A simpler alternative could be a Really,
Really Good Thing.
>
> -Bertrand
>
> [1] http://www.martinfowler.com/eaaCatalog/twoStepView.html
One of my favorites books. ;-)
http://www.martinfowler.com/books.html#eaa
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: The danger of overseparating concerns (was Re: [Design] JXTG 2.0 (Just my opinion))
Posted by Glen Ezkovich <gl...@hard-bop.com>.
On Dec 4, 2004, at 12:24 PM, Sylvain Wallez wrote:
>
> Note however, that the approach you suggest where the generator
> produces only XML data is valid in publishing-oriented applications
> where there's no controller, as the generator has to perform the data
> acquisition (until we have lightweight controllers that don't require
> 2 separate sitemap executions as flowscript does).
This where we are currently having problems. When a site is more of an
application then just a publication. Mainly our problems are with
forms, we would like to use CForms but are finding it difficult to
integrate with the rest of our architecture (and its a lot of XML). I'm
sure we will find a way ... eventually. But the point you make is well
taken and becoming painfully obvious.
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: The danger of overseparating concerns (was Re: [Design] JXTG
2.0(Just my opinion))
Posted by Antonio Gallardo <ag...@agssa.net>.
On Sab, 4 de Diciembre de 2004, 12:24, Sylvain Wallez dijo:
> Note however, that the approach you suggest where the generator produces
> only XML data is valid in publishing-oriented applications where there's
> no controller, as the generator has to perform the data acquisition
> (until we have lightweight controllers that don't require 2 separate
> sitemap executions as flowscript does).
More and more I am convinced that the pain is more related to a reporting
(publishing?) tool than to a new language.
Best Regards,
Antonio Gallardo
Re: The danger of overseparating concerns (was Re: [Design] JXTG 2.0 (Just my opinion))
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 4 déc. 04, à 19:24, Sylvain Wallez a écrit :
<snip interesting experiences/>
> ...Of course, this is related to our organisation where template
> writers have more a developer background.
Right. And the problem now is that there is no simple way for people to
move from "designer-friendly" environments to Cocoon-based publishing
in small steps. They have to do a big jump, where many probably fall on
their face ;-)
> ...The conclusion of this is that we must be careful of not
> overseparating concerns, as it may actually require more work without
> real architectural benefit...
Agreed. OTOH your view is very html-centric IIUC. In situations where
multi-channel output (web, mobile, print for example) is required, a
two-step view brings many benefits. But you're right that in such case
the first step is rarely pure XML, it's often biased towards the most
common/preferred output format.
-Bertrand
The danger of overseparating concerns (was Re: [Design] JXTG 2.0
(Just my opinion))
Posted by Sylvain Wallez <sy...@apache.org>.
Bertrand Delacretaz wrote:
> Le 3 déc. 04, à 21:40, Glen Ezkovich a écrit :
>
>> ...I'm not sure I agree that templates as being part of the view. I
>> look at them more as providing XML structure to the data....
>
>
> We need both actually - if you work with the "two-step view" pattern
> (which is very natural with Cocoon), you need a first set of templates
> to generate XML out of your data, and a second set to transform the
> XML into the final presentation format.
>
> Currently we have JXTG for the first step, and mostly XSLT for the
> second. Having something that could cover both steps and be usable by
> either programmers working on the first step or designers working on
> the second would be a Really Good Thing.
>
> -Bertrand
>
> [1] http://www.martinfowler.com/eaaCatalog/twoStepView.html
The two-step-view pattern is good when it doesn't degenerate into
three-step-view pattern, in which case it becomes highly
counter-productive. Let me tell you a story from my own experience in my
company when writing web applications (with lot of forms - publishing is
a different use case).
We (Anyware) have used a similar approach to TAL years ago, starting
with Cocoon1 (yes, _years_ ago!). The XSP was doing/calling the
controller (remember, we could redirect in XSP at that time) and
producing an XML representation of the data. Next was a XSL
transformation producing the HTML. That XSL was the result of the
"compilation" of a DW-compatible HTML page with either some additional
tags or some attributes like in TAL. We had a DW plugin to edit the
additional tags (see [1] for some rough explanation of it).
We had a good separation of concerns, DW-friendlyness. That seemed good
as long as our applications weren't complex. It has to be noted though
that the produced XSL was a simplfied stylesheet [2], i.e. with no
pattern-driven rules.
But there was a problem: each XSL, even if generated from annotated
HTML, contained a lot of graphic stuff, and the graphical layout of the
application was duplicated in all these HTML pages. Adding some data to
a page required some web designer skills to edit the HTML template, and
modifying the overall look of the application required to modify each
and every page. Painful.
Enter Cocoon 2.0, with its sitemaps and actions. We refactored our
framework so that the controller was an action, and the XSP was
therefore only producing data. Now our two-step view had degenerated
into a three-step view, as the controller was preparing some data
(objects) for the view, and the first step of the view was merly just
converting that data to XML. Adding some data to a page required to
modify 3 files: the action, the XSP and the XSL that formats the XML
data. Painful again.
With Cocoon 2.1 came flowscript and CForms, and we started using a
totally different scheme that I find highly productive. At the beginning
of a project, a prototype GUI is built to ensure that all requirements
have been taken into account and that we agree on the overall usability
(this happened previously also). Then, the work can happen in parallel:
- a web designer builds a set of static pages containing all graphical
structures that are needed for the application,
- the application developpers write the logic and page templates (JXTG)
containing only _structural_ HTML or other page description language.
The web designer's work is then XSL-ified to a full-blown
template-driven stylesheet, reacting either to elements (e.g.
<fieldset>) or class attributes, and is no more a simplified stylesheet
like we had in our previous approach. The XSL is now really for styling
and not for templating. Furthemore, we only have one XSL for all forms
(or one per screen type) instead of one per form (even if generated).
This approach is very productive as the webdesigner and application
writers work in parallel, and there is abolutely no overlap between
their respective work. Furthermore, the web design work is highly
reduced. Of course, this is related to our organisation where template
writers have more a developer background.
The conclusion of this is that we must be careful of not overseparating
concerns, as it may actually require more work without real
architectural benefit.
Note however, that the approach you suggest where the generator produces
only XML data is valid in publishing-oriented applications where there's
no controller, as the generator has to perform the data acquisition
(until we have lightweight controllers that don't require 2 separate
sitemap executions as flowscript does).
Sylvain
[1] http://marc.theaimsgroup.com/?t=99244278700003&r=1&w=2
[2] http://www.w3.org/TR/xslt#result-element-stylesheet
--
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 (Just my opinion)
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 3 déc. 04, à 21:40, Glen Ezkovich a écrit :
> ...I'm not sure I agree that templates as being part of the view. I
> look at them more as providing XML structure to the data....
We need both actually - if you work with the "two-step view" pattern
(which is very natural with Cocoon), you need a first set of templates
to generate XML out of your data, and a second set to transform the XML
into the final presentation format.
Currently we have JXTG for the first step, and mostly XSLT for the
second. Having something that could cover both steps and be usable by
either programmers working on the first step or designers working on
the second would be a Really Good Thing.
-Bertrand
[1] http://www.martinfowler.com/eaaCatalog/twoStepView.html
Re: [Design] JXTG 2.0 (Just my opinion)
Posted by Glen Ezkovich <gl...@hard-bop.com>.
On Dec 3, 2004, at 1:33 PM, Ralph Goers wrote:
> Stefano Mazzocchi said:
>>
>> <-- stuff removed -->
>>
>> ${myDate as month}
>>
>> <-- stuff removed -->
>> --
>> Stefano.
>
> Not that I disagree with you, but why don't you consider your example
> to
> be a taglib? Perhaps I'm just reading more generality into the
> discussions than is really there, but I haven't seen anyone state that
> "taglibs" must be of the form <namespace:op namespace:attr="token">,
> etc.
>
> Frankly, the part that has worried me the most is the discussion of SQL
> and templates in the same email. From my perspective SQL queries are
> part, of or simply are, the model. Templates, on the other hand are
> generally part of the view. Although they may be used in an
> intermediate
> step to reformat the data in the model, this is just a smaller version
> of
> MVC where the view is the reformatted data.
I'm not sure I agree that templates as being part of the view. I look
at them more as providing XML structure to the data.
>
> In other words, templates that do anything other than accessing already
> available data and rendering "formatted" data should a) not be
> possible,
> or b) be discouraged.
Most definitely agreeded.
> Notice "already available data". That means you
> shouldn't have tag libraries or whatever that do the SQL query, invoke
> business methods or whatever. That should all be done via business
> methods
> invoked by actions or flow (i.e. the controller).
Usually, I can see an SQLTemplateGenerator that uses no flow. It
connects and queries the database, i.e. generates the data, and then
injects into a template.
Here is a reasonable replacement for XSP and ESQL. Hopefully there will
be no view. (But you know there will be. :-( )
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