Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 69428 invoked from network); 4 Dec 2004 16:11:52 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 4 Dec 2004 16:11:52 -0000 Received: (qmail 34162 invoked by uid 500); 4 Dec 2004 16:11:48 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 34098 invoked by uid 500); 4 Dec 2004 16:11:47 -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 34083 invoked by uid 99); 4 Dec 2004 16:11:47 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: local policy) Received: from essemtepe.nada.kth.se (HELO smtp.nada.kth.se) (130.237.222.115) by apache.org (qpsmtpd/0.28) with ESMTP; Sat, 04 Dec 2004 08:11:46 -0800 X-Authentication-Info: The sender was authenticated as danielf using PLAIN at smtp.nada.kth.se Received: from [83.226.250.188] (localhost [127.0.0.1]) (authenticated bits=0) by smtp.nada.kth.se (8.12.10/8.12.11) with ESMTP id iB4GBXlu006505; Sat, 4 Dec 2004 17:11:33 +0100 (MET) Message-ID: <41B1E19D.2070708@nada.kth.se> Date: Sat, 04 Dec 2004 17:11:09 +0100 From: Daniel Fagerstrom User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: [RT] do me a favor, don't call them taglibs (TAL-like two-step templating?) References: <41B0D196.5080707@apache.org> <41B0DC2D.203@bitflux.ch> <41B1B823.20409@nada.kth.se> In-Reply-To: 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 4 d�c. 04, � 14:14, Daniel Fagerstrom a �crit : >> Bertrand Delacretaz wrote: >> >>> ...b) "presentation templates" downstream to convert the XML to HTML >>> or other presentation markup (currently covered by XSLT, far from ideal) > > >>> ...For b), being dreamweaver-compatible would be a big plus, allowing >>> less technical people to create templates themselves.... >> >> >> b) would be nice but it is quite complicated to implement in an >> efficient way. One can of course stream the transformer input to a DOM >> tree that is made available in the context object and then let a JXTG >> like script work on that. But the question is if we would be happy wih >> the performance... > > > It's hard to say without trying it, but IIUC we can essentially get this > (i.e. reuse the data-to-XML templating mechanism for downstream > transformations) for free, if taken into acount in the design. Just a > simple stream-to-DOM implementation would allow people to experiment. Yes, we would get that for free AFAIU. The design discussed this far should handle that without any problems. We need a convention for where to find the input DOM. Either implicitly like xslt or some special variable "$input". > And it might make a big difference, from the users point of view, by > making it possible to use a single tool for the whole presentation > pipeline, and making presentation templates way easier than raw XSLT, > which is a major stumbling block for many people. > > We might want to make it work first, to see how much people like it. If > they like it, I'm sure someone will find a way to make it fast, if needed. You're right no need to optimize until we know if it is needed. AFAICS the only reasonable way of accessing the XML input is things like XPath that in general need access to the complete XML-tree. And in that case we can reuse XSLT processor technology if needed. Going for something like STX-style access would be far to complecated for the intended audience. /Daniel