${page/title}

Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 47848 invoked from network); 6 Dec 2004 23:41:53 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 6 Dec 2004 23:41:53 -0000 Received: (qmail 58865 invoked by uid 500); 6 Dec 2004 23:41:52 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 58486 invoked by uid 500); 6 Dec 2004 23:41:50 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: dev@cocoon.apache.org Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 58471 invoked by uid 99); 6 Dec 2004 23:41:50 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (hermes.apache.org: local policy) Received: from Unknown (HELO pulse.betaversion.org) (62.140.213.123) by apache.org (qpsmtpd/0.28) with SMTP; Mon, 06 Dec 2004 15:41:49 -0800 Received: (qmail 7746 invoked from network); 6 Dec 2004 23:41:46 -0000 Received: from unknown (HELO ?127.0.0.1?) (stefano@127.0.0.1) by pulse.betaversion.org with SMTP; 6 Dec 2004 23:41:46 -0000 Message-ID: <41B4EE3C.7000205@apache.org> Date: Mon, 06 Dec 2004 18:41:48 -0500 From: Stefano Mazzocchi Organization: Apache Software Foundation User-Agent: Mozilla Thunderbird 0.9 (Macintosh/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: [Design] JXTG 2.0 (generator and transformer, same template syntax?) References: <41A4E5EF.9050703@nada.kth.se> <41AEFE7E.60909@nada.kth.se> <41AF5863.4080701@apache.org> <41AF80F1.2020405@nada.kth.se> <41AF8D55.2000105@apache.org> <1102042107.3438.49.camel@localhost.localdomain> <41B03937.6010401@mobilebox.pl> <41B0A468.9060205@apache.org> <5070ab37a3f09a5fe8a.20041203113303.enycu.tbref@www.dslextreme.com> <9BE66414-456B-11D9-AA5C-000393B3DE96@hard-bop.com> <2ED4E1A4-45D8-11D9-A95B-000A95AF004E@apache.org> <885F2694-462F-11D9-AA5C-000393B3DE96@mac.com> <0A33208D-4636-11D9-A95B-000A95AF004E@apache.org> <41B29927.7080706@apache.org> <1809B910-475C-11D9-A95B-000A95AF004E@apache.org> In-Reply-To: <1809B910-475C-11D9-A95B-000A95AF004E@apache.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N 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): > > > > > ${p/name} > ${p/age} > > > > > 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): > > > ${page/title} > > > > > > >

${p/name}

${p/age}

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