Discussion: Encouraging use of HTML in text fields

Tuesday 31 August 2004 6:31:20 am

I've seen several posts of late that encourage people to use text fields instead of the XML text fields to allow the editor to directly input HTML, either by hand, or with a WYSIWYG Web interface. While I understand the desire to do this, as it provides more flexibility and provides a quick fix to some questions, I am concerned that these answers are detrimental over the long run. By using HTML directly in a text field, some of the strength of eZ publish, or for that matter, any CMS is lost, as future redesigns will thus require changing or manipulating the content to change or remove these tags. As tags are deprecated, or designers/developers learn more about CSS, it will become painfully obvious that they can't fix things in templates. For large sites, with thousands of articles, cleaning things up will prove quite daunting.

eZ systems is improving the XML Text Field to provide the needed flexibility and working on a new Online Editor, plus, there is, and has been the ability to create custom tags, so I am curious as to why knowledgeable people recommend using the text field for this? What am I missing here?

I too briefly used a combination of a text field and third party text editor on a personal documentation site, before I saw the long term effects. It was nice to use whatever I wanted, but not at the loss of time and frustration down the line. At least for me.

So, I am posting this for a discussion as I think it is important that people think about the matter and post their thoughts. I hope you will.

Alex
[ bald_technologist on the IRC channel (irc.freenode.net): #eZpublish ]

<i>When in doubt, clear the cache.</i>

Tuesday 31 August 2004 8:03:20 am

I must admit im a little confused about the benefits an xml text field gives to me as the user and the developer. If im performing system integration then the xml becomes more useful but as a user and developer the xml is firmly locked away. The only part i do see and interact with is within the admin and there i find lots of restrictions.

With the coming relaxation of restrictions in 3.5 plus the new online editor its difficult to speak more about this since those changes may solve most problems. I hope they do.

Separating design from content doesnt require an xml text field in my opinion. If i write:

<div>Hello there</div>

i can write simple css to style this any way i want.

Although you can also use the same css to style output from an xml text field it is more difficult to do so because the class parameter in a xml text field is not the same as the css class. More settings need to be changed to link one 'class' to another 'class'. Arguably more powerful, yes, but it is more complex.

I think this dicussion really centres on import/export and the transformations you can do to the xml. If it isnt in this form then you cant perform these transformations to get the data to/from your other system easily. eZ includes a few tools to help here, such as packaging. Paul Borgermans released an xslt operator a long time ago for this. But to be quite honest there really are not that many tools to make full use of this format.

paul

Tuesday 31 August 2004 9:11:35 am

I think one fact is being mangled here. Alex, when you speak about not using html i gather you are speaking about not using html that does not conform to the latest (or apporved) xhtml spec? At the moment eZ xml tags are transformed to html for presentation. I notice that the present tag templates have a mixture of xhtml and html, though this is constantly evolving from what i can see.

However, the eZ template rendering of their xml spec is only one possible presentation. To go back to my point about the lack of tools to use the xml, maybe what we really need is a better way to integrate xslt. Paul B has started on this but maybe it should go further. Perhaps in parts this could replace templates for rendering of the xml. If we are to decouple the content from presentation we need to do something about the templates the xml relies upon for presentation.

paul

Tuesday 31 August 2004 9:50:31 am

Hi Paul,

I can't follow you on this:

<i>If we are to decouple the content from presentation we need to do something about the templates the xml relies upon for presentation.</i>

For me the separation between content and presentation is perfectly accomplished with the current template system, including the templates for xml tags, isn't it?

From an academic viewpoint, it is right to suppose when you have XML, there should be XSL too. Therefore the xslt template operator was introduced by us (programming credits to Tom Couwberghs, not me, I was only asking for it :-) ).

But there is more than xml content too: quite a few datatypes are not xml at all. To bring them in the realm of xml, these should be transformed to xml first before feeding them to an xsl transformation. And that means another processing layer too.

Also, in my experience, there are only very few developers skilled in XSL writing. The current template syntax is easier imho. And one other thing you will never have with a xsl schema is the access to the features of ezpublish, which makes the current template system far more richer than xsl transforms, even for datatypes!!

About the xml used in the ezxml datatype: well ... it is a bit poor for us. Ideally, I would love to see docbook(lite) support (we need support for mathematical, vector graphics and chemical markup). And then it is useful to do the transforms to whatever with xsl. But I see problems there as well: it is very difficult to incorporate "outside" content. The object tag we have now for example becomes almost impossible without more xsl hooks inside the core of ez publish.

I have voiced xml more in another context however: the way of editing content alla bitflux, xopus, and others that are emerging. This allows a browser to become much more an editing tool than those tiny scroll boxes with the OE. It is OK for small pieces of content, but not beyond say 50 lines of text. In this case it would be mandatory to have the content objects (or part thereof) transformed into pure xml.

Maybe the upcoming OSCOM conference (where the ez crew will participate) may change the evolution of ez publish in this direction I hope.

my 0.02 ¤

-paul

eZ Publish, eZ Find, Solr expert consulting and training
http://twitter.com/paulborgermans

Tuesday 31 August 2004 10:42:09 am

Paul F. - Good points, you are right that the thread has been on topic - my apologies for that. I didn't quite see that the topic was larger than I first thought. :) Your points make perfect sense, and as you well know, I am all for advocating the proper use of XHTML/CSS! Ultimately, we all want the content to be as clean as possible without sacrificing end-user functionality and usability, nor future capabilities.

The main reason I brought this up, is the fact that I found myself about to respond to someone, telling them to switch to a text field because it was easier. Once I caught myself, I realized that would be a mistake, and noticed that a couple of other posts were doing the same thing. As I mentioned above, I took your proof of concept and implemented it on a documentation site of my own, quite specifically because it provided me the flexibility I needed. So, instead of spending my time advocating the proper changes, I was trying to side-step the issue.

I too would like to get additional feedback from eZ systems on this topic and the specific points both of you Paul's mentioned.

Alex
[ bald_technologist on the IRC channel (irc.freenode.net): #eZpublish ]

<i>When in doubt, clear the cache.</i>