Forums / Suggestions / default <paragraph> in an ezxmltext datatype

default <paragraph> in an ezxmltext datatype

Author Message

Ronnie Garcia

Friday 27 February 2004 5:06:48 am

By default, the content of an ezxmltext datatype is embeded into a <paragraph> node at creation time by eZSimplifiedXMLInput::validateInput() (in kernel/classes/datatypes/ezxmltext/handlers/input/ezsimplifiedxmlinput.php).
This behaviour makes the XML field to be displayed in a <p></p> html block at final output.
I would like to discuss about this behaviour here.

Since an XML field can be.. anything, in some cases a user will want to setup one for, say, just one single word. Then a final output in a <p></p> block would maybe not be appropriate. This my case and i've seen several issues in the forums about this also.

IMHO, it would make more sense for the ezxmltext datatype to be abstract of any *default* presentation attributes. One will then want to *explicitly* embed text in <paragraph></paragraph> if he actually *wants* the output to be a paragraph and be displayed as such.

What do you guys think about this ?

Rgds,
Ronnie.

Iris Hoekstra - Roscam Abbing

Saturday 28 February 2004 11:00:10 am

I fully agree.

The website I'm building looks very silly with all those paragraph tags. I read somewhere that this is a subject of constant debate, but I can only think of the cons, would be interested in hearing the pros...

bisk

Sunday 29 February 2004 3:30:48 am

If you don't want a p tag, override the paragraph template or create a custom tag or use a different field.

As most of the times text in a xml field is probably mend to be a paragraph, I think it's quite logic that ez publish wraps it in a p tag by default. Also for keeping a good semantic structure of a html page.

And if your page looks silly with all these p tags, just create less paragraphs or use css to adjust the look of paragraphs to your likings.

-------------------------------
http://www.kookfijn.nl & http://www.magento.be

Alex Jones

Monday 01 March 2004 8:45:36 am

I agree with Bisk. The XML Text Field is meant to hold blocks of text and for the vast majority of sites this text should be wrapped in paragraph tags. eZ publish has been created with the flexibility to allow developers to override any data type in those instances when they should behave in a way different than the norm. In this case, the XML Text Field can easily be overridden where needed to not wrap the text in paragraph tags. If a developer is using an XML Text Field for something other than blocks of text, it might be time to review the data types to see if there is one better suited to the task at hand. For example, a Text Line could be a much better choice for content consisting of a single word. If current data types do not fit a unique situation, then the developer has the option of creating their own by creating a unique data type. If that unique data type fits a general need, then it can be posted to the Contributions section of the site for all to share, and possibly for future inclusion in the core set.

I think it is perfectly reasonable, and for that matter, logical to work with the implication that the content in an XML Text Field will be a block of a text, while providing the flexibility of changing it via overrides or CSS when and where needed.

Alex

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

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

Patrick Woods

Friday 05 March 2004 9:40:43 pm

There should be a parameter that could be set to turn automatic <p> tag creation on or off. It could be part of the attribute_view_gui call. That way if I want to put my intro inside an <h2> field I can. Or if I want my folder description to serve as a page description i can place it in a header with the <p> tags around it since its unnecessary to have <p> inside another block element.

At the very least I'd like to be able to pass parameters to it like you can with image tags. i cannot figure out how to get a variable from ezxmltext.tpl to paragraph.tpl does anyone know how to do that? I can't pass variables along with and {$attribute.content.output.output_text}. If I could just set a class to the <P> it would be perfect. Yes I could enclose it in a Div and use css to access that particular <p> but that's useless non-semantic markup just to apply a class to a selector.

--
www.hakjoon.com

Paul Forsyth

Saturday 06 March 2004 1:50:20 am

I don't see why you cannot just override the p.tpl file with your own.

For example, replace:

design/standard/templates/content/datatype/view/ezxmltags/paragraph.tpl

<p>
{$content}
</p>

with

design/user/override/templates/content/datatype/view/ezxmltags/paragraph.tpl

<p class="paragraph">
{$content}
</p>

Why would need a switch in an ini file to do this?

Paul

Patrick Woods

Saturday 06 March 2004 5:22:31 pm

That will cause all my paragraphs to have a class of "paragraph". What I would like to do is send a variable down to paragraph.tpl like I can with ezimage.tpl.

So you could do

{attribute_view_gui attribute=$node.description css_class="my_class"}

And then in my new paragraph.tpl I could do

{defaut css_class=false()}

<p{section show=$css_class}class="{$css_class|wash}">{/section}

or even better allow for the display or not of <p> tags on a case by case basis

{attribute_view_gui attribute=$node.content linebreak="false"}

And then in p.tpl

[default linebreak=true()}
{section show=$linebreak}
         <p>
     {/section}
{$content}
{section show=$linebreak}
         </p>
     {/section}

If someone can tell me how to get a variable to P.tpl that will account for all my needs. I can get it to ezxmltext.tpl but I can't figure out how to get it from there to P.tpl since $attribute.output_text is not called with an view_gui call. this should not be done on an ini level it should be done on a call by call level. I can do this with ezimage.tpl but pragraph.tpl is two templates deep and I can't figure out how to pass variables to it.

I mean Movable Type has this kind of functionality and it has about 1/8 of the capabilities ez-publish has.

--
www.hakjoon.com