Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 44121 invoked from network); 4 Dec 2004 19:17:12 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 4 Dec 2004 19:17:12 -0000 Received: (qmail 90007 invoked by uid 500); 4 Dec 2004 19:17:09 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 89927 invoked by uid 500); 4 Dec 2004 19:17:09 -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 89902 invoked by uid 99); 4 Dec 2004 19:17:09 -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 lakermmtao09.cox.net (HELO lakermmtao09.cox.net) (68.230.240.30) by apache.org (qpsmtpd/0.28) with ESMTP; Sat, 04 Dec 2004 11:17:07 -0800 Received: from [192.168.1.100] (really [68.11.49.127]) by lakermmtao09.cox.net (InterMail vM.6.01.04.00 201-2131-117-20041022) with ESMTP id <20041204191705.MXPN7152.lakermmtao09.cox.net@[192.168.1.100]> for ; Sat, 4 Dec 2004 14:17:05 -0500 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <5a7e0ac9dea46ea2a6be50a.20041203133354.enycu.tbref@www.dslextreme.com> References: <41B0D196.5080707@apache.org> <7AE08032-456E-11D9-AA5C-000393B3DE96@hard-bop.com> <5a7e0ac9dea46ea2a6be50a.20041203133354.enycu.tbref@www.dslextreme.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <14EE9EA5-4629-11D9-AA5C-000393B3DE96@hard-bop.com> Content-Transfer-Encoding: 7bit From: Glen Ezkovich Subject: Re: [RT] do me a favor, don't call them taglibs Date: Sat, 4 Dec 2004 13:17:04 -0600 To: dev@cocoon.apache.org X-Mailer: Apple Mail (2.619) X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N On Dec 3, 2004, at 3:33 PM, Ralph Goers wrote: > Glen Ezkovich said: >> >> On Dec 3, 2004, at 2:50 PM, Stefano Mazzocchi wrote: >> >>> All I ask from a template language: >>> >>> 1) something that HTML designers can edit with Dreamweaver >> >> Why? I really don't want HTML designers touching my templates. I want >> them to work withe the data received from my generator and transform >> that into something renderable by a browser. > > Wow. I guess we really have a different point of view. I see > templates as > an alternative to XSLT to generate the HTML. Of course I would want an > HTML designer to be able to do that. I did too. Just wound up with the same old problem, mixed concerns. Each template had to be maintained as the site's visual style evolved. As much as we tried to use CSS, we still had to modify the HTML. Divs here, tables there, the ice was all around. :-) While I can see using a template to directly generate the HTML it makes each page layout a separate maintenance issue. That is, some changes to a sites design might require each template to be modified. Using XSLT, it might be possible to change just a single XSL template. Think of something as simple as changing the image used as a bullet in a bullet list, or placing adds between paragraphs instead of all in the left column. As usual, what you choose to do depends on what you anticipate the needs of your site to be. If I needed to nothing more then take a result set and display it in a table, I probably would just generate the table in the template. The more complex the page becomes the less likely I am to use HTML in the template. What I've tried to do is define common entities that are rendered the same across various layouts and to define general page layout components that can be reused. By entities I mean things like products, product lines, features, feature, article, paragraph, etc.. These are generally given an XML representation using JXTG and are in turn rendered by XSLT. By general page layout components I mean rows, columns, grids, bullet lists, images, etc.. These are defined in a style sheet. A product can be laid out the same wether it is on a page by it's self or part of a catalog page. The difference might only be in the styles applied and/or the layout component that contains it. HTML element wise, the two renderings are identical, but visually maybe very different. Sometimes we do have to have use modes to render entities differently, but I generally consider these cases a failure of imagination. What is nice about this, is that the same template that generates XML data for a product on one site can be used with no or slight modification on another. The XSL defined layout components can be reused as well. The only things that need changing are the CSSs and some of the XSL templates for the entities. The aim is to be able to have a data/content driven model of a website as well as a page driven model. I'm not quite where I want to be yet. But I'm working on it. I still need to flesh out the concept a bit more and I need more sites to experiment on. Shhhhhh... Don't tell my clients. ;-) (this a private secure list... right?) 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