Tuesday 31 August 2004 8:47:09 am
<b>Ole:</b> I agree, we cannot, and should not try to force the users into using one specific method if it doesn't fit their need. I'm just concerned that we are sliding into recommending the easy route without showing the downside of it. I am just as guilty as anyone else on this site of doing just that. <b>Paul:</b> I totally agree with the fact that your example separates content from style. Though, to be honest, I don't think a div tag should be mixed in with your content. If you have something that requires a separate container, then I would go so far as to say that it should be stored separately. This may seem a bit extreme, but it is the only way to truly separate style from content, and ensure long term usability. I hope you don't mind, but I am going to shift to using unordered lists as an example, as I believe they should naturally fit within the content. From my perspective, the true value of the XML Text field is in allowing us as developers to transform the content down the road. By placing a <i><ul></i> block, or any other (X)HTML specific tag in your code, that tag will have to be defined via XSL, or another transformation language, or removed altogether. Using custom tags, a change can be made in the template files to affect how all instances of that tag are displayed. Another example that crops up from time to time is the <i><font</i> tag. If someone really needs a font tag, I think they are better off creating a custom tag for their editors that will spit out <i><font ...></i>. In time, when they can finally move away from using the font tag, they may choose to replace it with a span, or eliminate the font tag from the custom tag template altogether. I agree that the use of template classes versus CSS classes does complicate matters far more than it should, and I would like to see it revised. You are right, this discussion does focus on importing and exporting, though I would also add re-use and redesign as well. In my opinion, content should be stored in a manner that is independent of it's output markup language. Placing HTML within the content breaks that. Actually, it is much the same as using in-line CSS styles everywhere, instead of using classes and IDs. You can go the easy route and apply span tags throughout your templates, but in the long run, you are far better off applying classes and IDs judiciously to elements to allow for full flexibility when changes need to be made. Using the custom XML tags provides the means to style the content appropriately for a variety of mediums. I haven't used the PDF export system at all, but I am curious as to how it handles having HTML within the content. Is it rendered, or is it output as plain text? What if a user decides they want to use eZ publish as a back-end server for a Flash app? Sorry if I am rambling on a bit here. This is turning into a great conversation, and I appreciate the differing perspective. :)
Alex
[ bald_technologist on the IRC channel (irc.freenode.net): #eZpublish ]
<i>When in doubt, clear the cache.</i>
|