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
smime.p7s
Description: S/MIME cryptographic signature
