Re: [RT] do me a favor, don't call them taglibs
On Dec 4, 2004, at 10:52 PM, Stefano Mazzocchi wrote: Glen, I don't think we are talking about very different things. I know. I *completely* agree with you that the power of pipelines and SoC is exactly that: change one file and make all the others adjust. Damn, there wouldn't be a cocoon if that wasn't the case ;-) What I want is to create a 'bridge' for those who don't get it. To some extent. I want something simpler then XSLT and is more markup oriented (an XHTML template). I'd also like to not ask my designers to invoke java methods. CSS is already a tremendous bridge that allows people to cleanup their pages and they understand the power of SoC, since changing a stylesheet allows them to change all the pages. Still, CSS is not enough because is not able to change the layout of things It can change the layout of things with absolute positioning. Its just very difficult to get things right. and it becomes a night mare to make changes to. and, even worse, sometimes the style dictates the markup (example: if you want to use stuff like rounded boxes). Need to talk to your designers then ;-) *but* what is possible is to have something like div class=headerHeader/div be transformed into a massive, highly graphical, header. In short, it is possible to give *some* visual but style free placeholding material for the layout designers to work with, then transform these with some XSLT. What we have is something slightly different, we have header tags. These get transformed differently depending on context. Possibly with different classes. What you need is not WYSIWYG, I wish there was such a tool. :-) web designers care about that, but usability managers really don't. They care about colors and fonts and spaces and positioning and error messages and visibility of things (all things that CSS can do for them), so it's entirely possible to have placeholders for things they don't care about, they just want to care about the content, but also about the layout of the page. Agreed. However, our place holders represent entities, not page elements. Things such as products, images or headings. We use XSLT to transform them into html. Right now I go so far as to insist that we do not use html tag names for our entity names. i.e. you can't use img you need to use image . I know its anal, but I really want to emphasize the difference between content and layout. We are not always successful but we are working on it. 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
Re: [RT] do me a favor, don't call them taglibs
Stefano Mazzocchi wrote: snip/ Still, CSS is not enough because is not able to change the layout of things and, even worse, sometimes the style dictates the markup (example: if you want to use stuff like rounded boxes). OT For rounded corners at tabs you can use :before and :after pseudo selectors http://www.w3.org/TR/REC-CSS2/selector.html#before-and-after, unfortionally it only works in modern browsers and not in the popular broken one that our custommers tend to have :/ Then if you feel that your CSS style sheets are by far to easy to understand, there are a couple of interesting CSS tricks for getting rounded corners even in IE: http://www.alistapart.com/articles/slidingdoors/, http://www.alistapart.com/articles/slidingdoors2/, http://www.alistapart.com/articles/customcorners/ They are so subtle that the XSLT solution probably is better idea. /OT /Daniel
Re: [RT] do me a favor, don't call them taglibs
Daniel Fagerstrom wrote: Stefano Mazzocchi wrote: snip/ Still, CSS is not enough because is not able to change the layout of things and, even worse, sometimes the style dictates the markup (example: if you want to use stuff like rounded boxes). OT For rounded corners at tabs you can use :before and :after pseudo selectors http://www.w3.org/TR/REC-CSS2/selector.html#before-and-after, unfortionally it only works in modern browsers and not in the popular broken one that our custommers tend to have :/ http://dean.edwards.name/IE7/ - Miles Elam
Re: [RT] do me a favor, don't call them taglibs
Roy G. Biv wrote: Daniel Fagerstrom wrote: Stefano Mazzocchi wrote: snip/ Still, CSS is not enough because is not able to change the layout of things and, even worse, sometimes the style dictates the markup (example: if you want to use stuff like rounded boxes). OT For rounded corners at tabs you can use :before and :after pseudo selectors http://www.w3.org/TR/REC-CSS2/selector.html#before-and-after, unfortionally it only works in modern browsers and not in the popular broken one that our custommers tend to have :/ http://dean.edwards.name/IE7/ Nice, I have to test that. Might be able to remove some of my uglier CSS hacks for showing thing in IE :) /Daniel
Re: [RT] do me a favor, don't call them taglibs
Daniel Fagerstrom wrote: Stefano Mazzocchi wrote: snip/ Still, CSS is not enough because is not able to change the layout of things and, even worse, sometimes the style dictates the markup (example: if you want to use stuff like rounded boxes). OT For rounded corners at tabs you can use :before and :after pseudo selectors http://www.w3.org/TR/REC-CSS2/selector.html#before-and-after, unfortionally it only works in modern browsers and not in the popular broken one that our custommers tend to have :/ Then if you feel that your CSS style sheets are by far to easy to understand, there are a couple of interesting CSS tricks for getting rounded corners even in IE: http://www.alistapart.com/articles/slidingdoors/, http://www.alistapart.com/articles/slidingdoors2/, http://www.alistapart.com/articles/customcorners/ They are so subtle that the XSLT solution probably is better idea. /OT I do that. The problem is that you have *4* corners, not 2 ;-) that's why it forces you to use two elements, so that you can have the top corner be the :before of the first and the bottom corner to be the :before of the second. That's my favorite example of why CSS is not powerful enough for what people need. -- Stefano.
Re: [RT] do me a favor, don't call them taglibs (TAL-like two-step templating?)
Le 3 déc. 04, à 22:35, Christian Stocker a écrit : On 3.12.2004 21:50 Uhr, Stefano Mazzocchi wrote: All I ask from a template language: 1) something that HTML designers can edit with Dreamweaver 2) something that doesn't use namespaced tags to identify dynamic scopes (clashes with #1) 3) something that doesn't use the name taglib That's pretty much all you have to do to make me happy. Maybe Zope's TAL idea is something for you. http://www.zope.org/Wikis/DevSite/Projects/ZPT/TAL They are very fond of the fact that it's Dreamweaver-Compatible I think we need a) data templates (for a lack of a better word), to generate XML out of data (what JXTG does now), and b) presentation templates downstream to convert the XML to HTML or other presentation markup (currently covered by XSLT, far from ideal) - oo - For a), JXTG does a good job currently, but having a single mechanism for both would make a big difference in the number of things that people have to learn to be productive with Cocoon. For b), being dreamweaver-compatible would be a big plus, allowing less technical people to create templates themselves. Using Dreamweaver or not, that's not the point: DW-compatibility also means that the templating system is simple enough for such people to grasp. - oo - To me, TAL's design looks simple for simple things, yet powerful and extensible. Looks like an example to follow, maybe even like a spec to adopt instead of reinventing it.. ...I once started implementing that in my own framework (a php based cocoon ripoff ;) ah good. sometimes people ask what popoon is, now we know how to describe it ;-) ;-) -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: [RT] do me a favor, don't call them taglibs
Antonio Gallardo wrote: On Vie, 3 de Diciembre de 2004, 15:35, Tony Collen dijo: Stefano Mazzocchi wrote: All I ask from a template language: 1) something that HTML designers can edit with Dreamweaver 2) something that doesn't use namespaced tags to identify dynamic scopes (clashes with #1) 3) something that doesn't use the name taglib That's pretty much all you have to do to make me happy. I believe I was responsible for originally starting the discussion about fixing JXTG 2, so I feel like I should probably respond. JXTG works just fine. I just didn't want to be freaked out looking at the source. At a minimum, having JXTG refactored, keeping the exact same functionality, and my mind would be put at ease. I can try to break the original JXTG in more classes. I mean in separated files. WDYT? Best Regards, Antonio Gallardo. That is the main idea with the template initiative. Then we happened to use a word for describing the mechanism of breaking out the template tag implementations to separate files, that suddenly made every one upset. One could break up JXTG by writing detailed test cases for JXTG and refactor in controlled steps to something more managable. But it didn't seem like anybody found that solution attractive. I'll sugest that we see what the templating discussion leads and base further work on that. /Daniel
Re: [RT] do me a favor, don't call them taglibs (TAL-like two-step templating?)
Bertrand Delacretaz wrote: snip/ I think we need a) data templates (for a lack of a better word), to generate XML out of data (what JXTG does now), and b) presentation templates downstream to convert the XML to HTML or other presentation markup (currently covered by XSLT, far from ideal) - oo - For a), JXTG does a good job currently, but having a single mechanism for both would make a big difference in the number of things that people have to learn to be productive with Cocoon. For b), being dreamweaver-compatible would be a big plus, allowing less technical people to create templates themselves. Using Dreamweaver or not, that's not the point: DW-compatibility also means that the templating system is simple enough for such people to grasp. 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. Otherwise we would need to build a more light weight tree representation of XML and write adapters to it so that it work with an XPath processor, Jaxen e.g. Or maybe there are light weight XML tree implementations that we could reuse. - oo - To me, TAL's design looks simple for simple things, yet powerful and extensible. Looks like an example to follow, maybe even like a spec to adopt instead of reinventing it.. Didn't like the Phyton syntax, but we can certainly find some good ideas from it. /Daniel
Re: [RT] do me a favor, don't call them taglibs (TAL-like two-step templating?)
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. 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. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: [RT] do me a favor, don't call them taglibs
On Sab, 4 de Diciembre de 2004, 6:58, Daniel Fagerstrom dijo: Antonio Gallardo wrote: On Vie, 3 de Diciembre de 2004, 15:35, Tony Collen dijo: Stefano Mazzocchi wrote: All I ask from a template language: 1) something that HTML designers can edit with Dreamweaver 2) something that doesn't use namespaced tags to identify dynamic scopes (clashes with #1) 3) something that doesn't use the name taglib That's pretty much all you have to do to make me happy. I believe I was responsible for originally starting the discussion about fixing JXTG 2, so I feel like I should probably respond. JXTG works just fine. I just didn't want to be freaked out looking at the source. At a minimum, having JXTG refactored, keeping the exact same functionality, and my mind would be put at ease. I can try to break the original JXTG in more classes. I mean in separated files. WDYT? Best Regards, Antonio Gallardo. That is the main idea with the template initiative. Then we happened to use a word for describing the mechanism of breaking out the template tag implementations to separate files, that suddenly made every one upset. One could break up JXTG by writing detailed test cases for JXTG and refactor in controlled steps to something more managable. But it didn't seem like anybody found that solution attractive. I'll sugest that we see what the templating discussion leads and base further work on that. I agree. Anyway, we (in Cocoon) have a current user base using JXTG that we cannot forget. If is necesary, I can do that. Some months ago, I spend a week understanding how the JXTG works. While I don't consider myself an expert. I thing we can make the life easier to others by breaking it down. I saw some problems on the user list that I guess can be easily fixed in the current implementation. BTW, I also saw the current implementation has some broken parts that need to be fixed again. I think is better to extend what we have instead of defining a new language. We need to consolidate things while I understand is good to have a new research areas. So in anycase the JXTG refactoring is a must. WDYT? Best Regards, Antonio Gallardo.
Re: [RT] do me a favor, don't call them taglibs
Le 4 déc. 04, à 16:56, Antonio Gallardo a écrit : ...I think is better to extend what we have instead of defining a new language. We need to consolidate things while I understand is good to have a new research areas. So in anycase the JXTG refactoring is a must... I'd say keeping JXTG alive is a must, and refactoring is probably needed to make this happen. OTOH what's been discussed in the last days regarding attribute-based Dreamweaver-friendly templating looks to me like a very welcome evolution, which can happen in parallel. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: [RT] do me a favor, don't call them taglibs
On Sab, 4 de Diciembre de 2004, 10:03, Bertrand Delacretaz dijo: Le 4 déc. 04, à 16:56, Antonio Gallardo a écrit : ...I think is better to extend what we have instead of defining a new language. We need to consolidate things while I understand is good to have a new research areas. So in anycase the JXTG refactoring is a must... I'd say keeping JXTG alive is a must, and refactoring is probably needed to make this happen. OTOH what's been discussed in the last days regarding attribute-based Dreamweaver-friendly templating looks to me like a very welcome evolution, which can happen in parallel. OK. Lets do that! /me is hoping he will not break nothing in the job. ;-) Best Regards, Antonio Gallardo
Re: [RT] do me a favor, don't call them taglibs (TAL-like two-step templating?)
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
Re: [RT] do me a favor, don't call them taglibs
On Sat, 4 Dec 2004, Antonio Gallardo wrote: snip... I agree. Anyway, we (in Cocoon) have a current user base using JXTG that we cannot forget. If is necesary, I can do that. Some months ago, I spend a week understanding how the JXTG works. While I don't consider myself an expert. I thing we can make the life easier to others by breaking it down. I saw some problems on the user list that I guess can be easily fixed in the current implementation. BTW, I also saw the current implementation has some broken parts that need to be fixed again. The only part missing is finalizing the Tag interface. Specifically how attributes values should be fed into the tag instance (at the time there was disagreement regarding thread safety of tags so the Tag interface had to wait). There might also be some tweaks necessary to support macros. I think is better to extend what we have instead of defining a new language. We need to consolidate things while I understand is good to have a new research areas. So in anycase the JXTG refactoring is a must. The template block is exactly that, an attempt at refactoring JXTG. Cheers Jonas
Re: [RT] do me a favor, don't call them taglibs (Please describe DreamWeaver)
On Sat, Dec 04, 2004 at 09:37:10AM +0100, Bertrand Delacretaz wrote: For b), being dreamweaver-compatible would be a big plus, allowing less technical people to create templates themselves. Using Dreamweaver or not, that's not the point: DW-compatibility also means that the templating system is simple enough for such people to grasp. Perhaps I am not the only person on this list that has never used DreamWeaver...would anybody care to list or describe the how's and why's of its benefits and limitations? For context, all I have managed to glean so far from this discussion is a vague idea that visual people like it, that it does not work well with namespaced tags, and that it does seem to work ok with custom attributes. Not having ever used it, I do not know why visual designers like it, why it does not like namespaced tags, etc. Could somebody knowledgeable on the topic expand on the description? --Tim Larson
Re: [RT] do me a favor, don't call them taglibs (TAL-like two-step templating?)
Le 4 déc. 04, à 18:56, Stefano Mazzocchi a écrit : Bertrand Delacretaz wrote: ...I think we need a) data templates (for a lack of a better word), to generate XML out of data (what JXTG does now), and b) presentation templates downstream to convert the XML to HTML or other presentation markup (currently covered by XSLT, far from ideal) I very much disagree with this. The notion of separating a data template from a presentation template is arbitrary and nothing really generally useful from a SoC point of view. I didn't mean two different *template mechanisms*, rather that we need templates at two (or several) points in a pipeline, not only at the beginning of the pipeline as the G in JXTG implies. Thinking about it, what I was talking about is two *use cases* for the templating system, with very different point of views and users skills. ...What we need is a template language. Period. Something that converts data *structures* into SAX events. Whether you use it for data or presentation or whatever else, it's up to you... Fully agreed. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: [RT] do me a favor, don't call them taglibs
Bertrand Delacretaz wrote: Le 4 déc. 04, à 16:56, Antonio Gallardo a écrit : ...I think is better to extend what we have instead of defining a new language. We need to consolidate things while I understand is good to have a new research areas. So in anycase the JXTG refactoring is a must... I'd say keeping JXTG alive is a must, and refactoring is probably needed to make this happen. OTOH what's been discussed in the last days regarding attribute-based Dreamweaver-friendly templating looks to me like a very welcome evolution, which can happen in parallel. +1 -- Stefano.
Re: [RT] do me a favor, don't call them taglibs (Please describe DreamWeaver)
On Sunday 05 December 2004 02:00, Tim Larson wrote: Perhaps I am not the only person on this list that has never used DreamWeaver... DreamWeaver is loved by many page designers as it manages the various resources and on-page placements well (seen from the eye of the designer). The concept is basically like this; Let the page designer use whatever tool he want, to create a rough mock-up of the page with just placeholders for the dynamic data. Give those to the web developer, and he inserts the hidden attributes required to make the dynamic part work. Then the page designer can continue to refine the design in his favourite tool, for instance DreamWeaver, while the programming effort continues in parallel. I don't think DreamWeaver is any better or any worse than other tools regarding unknown elements. AFAIU, you can have special tags in the HTML and DW will preserve them, but they will show up as ugly icons, disrupting the overall look. span and div elements is containing the mock-data within them, which will display as expected, and just be 'dynamic' in the live case. We occasionally use Tapestry for this type of work flow and it works pretty well. For one thing, it is just about impossible to get the artist to learn XSLT, HTML and CSS... let people do what they are good at. Cheers Niclas -- +--//---+ / http://www.dpml.net / / http://niclas.hedhman.org / +--//---+
Re: [RT] do me a favor, don't call them taglibs (Please describe DreamWeaver)
Tim Larson wrote: On Sat, Dec 04, 2004 at 09:37:10AM +0100, Bertrand Delacretaz wrote: For b), being dreamweaver-compatible would be a big plus, allowing less technical people to create templates themselves. Using Dreamweaver or not, that's not the point: DW-compatibility also means that the templating system is simple enough for such people to grasp. Perhaps I am not the only person on this list that has never used DreamWeaver... I've tried it once and I found my text editors to be way more productive. And power web designers use text editors too (or DW source mode), but that's a minority. would anybody care to list or describe the how's and why's of its benefits and limitations? For context, all I have managed to glean so far from this discussion is a vague idea that visual people like it, What's critical in the discussion is that XSLT is not the right tool for content presentation. There are many exceptions but XSLT is a programming language with a markup syntax, it looks friendly at first and its template declarativity is easy to understand for HTML designers because of CSS selectors, but it's extremely verbose and, most of all, it's not supported by visual HTML tools (or, it if is, in a very poor way). What I want is to be able to have HTML people design the template of the page in the simplest possible way for them. that it does not work well with namespaced tags One of the problems with any WYSIWYG editors is how to select things that don't have a visual representation. Because if you add a visual representation to them, it's not WYSIWIG anymore, if you keep them hidden, it's easy to screw them (either write inline or to remove them) without noticing. and that it does seem to work ok with custom attributes. attributes don't have a visual representation themselves, but they are always glued to the markup, so they move with them. DW is smart enough to allow namespaced attributes and work on the elements without disturbing those attributes. Basically, they are like attached labels that you move on with your code. The designers love this, because all they have to understand to start working on this is don't touch the attributes which name starts with xxx: Let on, they will understand, by try/fail, what these attribute means and pretty soon they master the whole template language, allowing the programmers to work away from their templates. Not having ever used it, I do not know why visual designers like it, why it does not like namespaced tags, etc. Could somebody knowledgeable on the topic expand on the description? DW is as smart with namespaced elements as it is with namespaced attributes, the problem is that the workflow of a web designer is a continous try/fail of new things and moving things around. In the process of cut/paste/delete, if done on the WYSIWYG canvas, it's almost impossible to guarantee that those invisible namespaced elements will remain there after you have moved them around. Attributes carry their own problems (as Daniel explained very well in the other email) but way safer. -- Stefano.
Re: [RT] do me a favor, don't call them taglibs
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. Shh... 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
Re: [RT] do me a favor, don't call them taglibs (TAL-like two-step templating?)
Daniel Fagerstrom wrote: 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. Why is STX considered more complex than XSLT? Sure it doesn't have arbitrary source tree access, but the syntax is very similar to XSLT by design. Instead of xsl:template, you have stx:template. I still think that STX would act as an effective macro expansion mechanism instead of having macros in Java/SAX. - Miles Elam
Re: [RT] do me a favor, don't call them taglibs (TAL-like two-step templating?)
Stefano Mazzocchi wrote: What we need is a template language. Period. Something that converts data *structures* into SAX events. Whether you use it for data or presentation or whatever else, it's up to you. Once again, it looks like I should have just read all the comments before replying again. *sigh* For what it's worth, concept resonation has occurred. (aka I agree completely) - Miles Elam
Re: [RT] do me a favor, don't call them taglibs (TAL-like two-step templating?)
Roy G. Biv wrote: Daniel Fagerstrom wrote: snip/ 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. Why is STX considered more complex than XSLT? I mean for writing a simple to use template language that works like XSLT: XML-XML driven by a stylesheet. If the template writer want to render data in another order than that of the input document, the streaming, non-buffering nature of STX will bite them. They need to write rules that are trigered by the correct input events and buffer the data. This requires some thinking even for experienced programmers. In XSLT you have random access to the whole tree and don't need to care about temporal order of things. Much easier. Sure it doesn't have arbitrary source tree access, but the syntax is very similar to XSLT by design. Instead of xsl:template, you have stx:template. I have written a number of STX style sheets for a number of different application, where avoiding buffering was important for performance. I would say that syntax is its only similarity with XSLT. Or do you have different experience. I still think that STX would act as an effective macro expansion mechanism instead of having macros in Java/SAX. As said in another letter: macro expansion is written in the template language it self. /Daniel
Re: [RT] do me a favor, don't call them taglibs
Glen Ezkovich wrote: 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. Shh... Don't tell my clients. ;-) (this a private secure list... right?) Glen, I don't think we are talking about very different things. I *completely* agree with you that the power of pipelines and SoC is exactly that: change one file and make all the others adjust. Damn, there wouldn't be a cocoon if that wasn't the case ;-) What I want is to create a 'bridge' for those who don't get it. CSS is already a tremendous bridge that allows people to cleanup their pages and they understand the power of SoC, since changing a stylesheet allows them to change all the pages. Still, CSS is not enough because is not able to change the layout of things and, even worse, sometimes the style dictates the markup (example: if you want to use stuff like rounded boxes). *but* what is possible is to have something like div class=headerHeader/div be transformed into a massive, highly graphical, header. In short, it is possible to give *some* visual but style free placeholding material for the layout designers to work with, then transform these with some XSLT. What you need is not WYSIWYG, web designers care about that, but usability managers really don't. They care about colors and fonts and spaces and positioning and error messages and visibility of things (all things that CSS can do for them), so it's entirely possible to have placeholders for things they don't care about, they just want to care about the content, but also about the layout of the page. -- Stefano.
Re: [RT] do me a favor, don't call them taglibs
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. 2) something that doesn't use namespaced tags to identify dynamic scopes (clashes with #1) Would be nice. But since I don't like 1, no problem here. ;-) 3) something that doesn't use the name taglib The name does have evil connotations. Do you have a suggestion for a new name? That's pretty much all you have to do to make me happy. -- Stefano. 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
Re: [RT] do me a favor, don't call them taglibs
What's the closest equivalent to what you have in mind :) -- dims On Fri, 03 Dec 2004 15:50:30 -0500, Stefano Mazzocchi [EMAIL PROTECTED] wrote: All I ask from a template language: 1) something that HTML designers can edit with Dreamweaver 2) something that doesn't use namespaced tags to identify dynamic scopes (clashes with #1) 3) something that doesn't use the name taglib That's pretty much all you have to do to make me happy. -- Stefano. -- Davanum Srinivas - http://webservices.apache.org/~dims/
Re: [RT] do me a favor, don't call them taglibs
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. Ralph
Re: [RT] do me a favor, don't call them taglibs
Stefano Mazzocchi wrote: All I ask from a template language: 1) something that HTML designers can edit with Dreamweaver 2) something that doesn't use namespaced tags to identify dynamic scopes (clashes with #1) 3) something that doesn't use the name taglib That's pretty much all you have to do to make me happy. I believe I was responsible for originally starting the discussion about fixing JXTG 2, so I feel like I should probably respond. JXTG works just fine. I just didn't want to be freaked out looking at the source. At a minimum, having JXTG refactored, keeping the exact same functionality, and my mind would be put at ease. Tony
Re: [RT] do me a favor, don't call them taglibs
On 3.12.2004 21:50 Uhr, Stefano Mazzocchi wrote: All I ask from a template language: 1) something that HTML designers can edit with Dreamweaver 2) something that doesn't use namespaced tags to identify dynamic scopes (clashes with #1) 3) something that doesn't use the name taglib That's pretty much all you have to do to make me happy. Maybe Zope's TAL idea is something for you. http://www.zope.org/Wikis/DevSite/Projects/ZPT/TAL They are very fond of the fact that it's Dreamweaver-Compatible I once started implementing that in my own framework (a php based cocoon ripoff ;) ), but with using XSLT for transforming the TAL to another XSLT, which then transformed the actual content. I never really finished it (meaning implementing most of the specs), but it was basically working. Take it as a proof of concept ;) The XSLT can be found here: http://svn.bitflux.ch/repos/public/popoon/trunk/components/transformers/xsltal/tal2xslt.xsl (the bxf:tales function is framework specific and would have to be adjusted a little bit for general use, IIRC) chregu -- christian stocker | Bitflux GmbH | schoeneggstrasse 5 | ch-8004 zurich phone +41 1 240 56 70 | mobile +41 76 561 88 60 | fax +41 1 240 56 71 http://www.bitflux.ch | [EMAIL PROTECTED] | gnupg-keyid 0x5CE1DECB
Re: [RT] do me a favor, don't call them taglibs
On Vie, 3 de Diciembre de 2004, 15:35, Tony Collen dijo: Stefano Mazzocchi wrote: All I ask from a template language: 1) something that HTML designers can edit with Dreamweaver 2) something that doesn't use namespaced tags to identify dynamic scopes (clashes with #1) 3) something that doesn't use the name taglib That's pretty much all you have to do to make me happy. I believe I was responsible for originally starting the discussion about fixing JXTG 2, so I feel like I should probably respond. JXTG works just fine. I just didn't want to be freaked out looking at the source. At a minimum, having JXTG refactored, keeping the exact same functionality, and my mind would be put at ease. I can try to break the original JXTG in more classes. I mean in separated files. WDYT? Best Regards, Antonio Gallardo.
Re: [RT] do me a favor, don't call them taglibs
Antonio Gallardo wrote: On Vie, 3 de Diciembre de 2004, 15:35, Tony Collen dijo: Stefano Mazzocchi wrote: All I ask from a template language: 1) something that HTML designers can edit with Dreamweaver 2) something that doesn't use namespaced tags to identify dynamic scopes (clashes with #1) 3) something that doesn't use the name taglib That's pretty much all you have to do to make me happy. I believe I was responsible for originally starting the discussion about fixing JXTG 2, so I feel like I should probably respond. JXTG works just fine. I just didn't want to be freaked out looking at the source. At a minimum, having JXTG refactored, keeping the exact same functionality, and my mind would be put at ease. I can try to break the original JXTG in more classes. I mean in separated files. That might help in the short term. But there's something special that happens in Cocoon - it has happened with flow, then CForms, but hasn't happened with JXTemplate. When everyone rounds on a technology, and thoroughly backs it. And that has still to happen in relation to templating. (or maybe it is already happenning, who knows). Regards, Upayavira
Re: [RT] do me a favor, don't call them taglibs
On Vie, 3 de Diciembre de 2004, 16:44, Upayavira dijo: That might help in the short term. But there's something special that happens in Cocoon - it has happened with flow, then CForms, but hasn't happened with JXTemplate. When everyone rounds on a technology, and thoroughly backs it. And that has still to happen in relation to templating. (or maybe it is already happenning, who knows). Yep. I expect this would happen here too. Some months ago, some of us closed JXTG bugs and added new features to it. ;-) Best Regards, Antonio Gallardo
