cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bertrand Delacretaz <>
Subject Re: [Design] JXTG 2.0 (generator and transformer, same template syntax?)
Date Tue, 07 Dec 2004 08:31:30 GMT
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 

>> ...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 ? 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:
> []...

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 

>> ...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".



View raw message