Hi Nick,
that's possible, but you will have to implement a custom binding class
for that. The default binding class is
nl.hippo.cocoon.forms.binding.HTMLAreaBinding
You can use that class as a reference. If I understand correctly, you
have to load the CData element from the source file, and assign the
string value to the context node in the doLoad() method, and in the
doSave() method you have to create a CData element and serialize the
input DOM element to a string, and assign that to the CData element.
One potential drawback is that, if you write the html in a CDATA block,
that text indexing in the repository might go wrong: the html tags are
also indexed (something you won't want), or maybe the entire CDATA block
is not indexed.. I'm not sure about this thought, Ard can you shed some
light on this ?
regards,
Dennis
Nick Stolwijk wrote:
Would it be possible to store the values in this elements as CDATA
instead of HTML/XML?
<content>
<section>
<tekst> <![CDATA[
<html>
<body>
<p>This is a test <em> item.</em></p>
</body>
</html>
]]></tekst>
<subtitle>subtitle</subtitle>
</section>
</content>
And maybe even leave of the html and body tags as those are not
necessary for the output.
With regards,
Nick Stolwijk
Dennis Dam wrote:
The problem with xs:any is that it allows every possible element ,
not just html elements. This is also not correct. AFAIK, there is no
way of defining a complete XML schema for the html output of the
htmlfield in the CMS' editor.
Although, I agree xs:any is "more" correct than modelling it as
xs:string, because it represents a complex structure.
Nick Stolwijk wrote:
Wouldn't it be
<xs:element name="tekst">
<xs:complexType>
<xs:sequence>
<xs:any minOccurs="0"/>
</xs:sequence>
</xs:complexType>
</xs:element>
to validate the current XML output?
But now I should serialize all the contents inside the
tekst/html/body element for each section? Ok, I will do that.
Thanks,
Nick Stolwijk
Dennis Dam wrote:
Hi Nick,
This is by design. The "new item" you mentioned is an htmlfield.
The output of the html field is html, of which the XML structure is
partly determined by the Xinha editor plugin and partly by a filter
component ("htmlcleaner"). The reason this element was modelled as
a string is for two reasons: 1) it's almost impossible to make a
XML schema for the possible output of the htmlfield and 2)
internally the element "text" is handled as a string element. The
output of the Xinha editor is actually a string. The string is
converted to xml by a binding class in the CMS. Before the binding
of the string to XML, the htmlcleaner filters out unwanted html
elements / attributes.
Hope this clears things up a little bit,
regards,
Dennis
Nick Stolwijk wrote:
In the commons xsd (extensions/types/common/schemas/common.xsd)
for types I have the following field:
<xs:element name="tekst" type="xs:string"/>
Which is used inside a section inside the content of a news item.
If I create a new item with the cms it produces the following XML:
<content>
<section>
<tekst>
<html>
<body>
<p>This is a test <em> item.</em></p>
</body>
</html>
</tekst>
<subtitle>subtitle</subtitle>
</section>
</content>
Now the content of the tekst element is not only string but a
complexType.
Is this by design or am I doing something wrong?
With regards,
Nick Stolwijk
********************************************
Hippocms-dev: Hippo CMS development public mailinglist
********************************************
Hippocms-dev: Hippo CMS development public mailinglist
********************************************
Hippocms-dev: Hippo CMS development public mailinglist
--
Hippo
Oosteinde 11
1017WT Amsterdam
The Netherlands
Tel +31 (0)20 5224466
-------------------------------------------------------------
[EMAIL PROTECTED] / http://www.hippo.nl
--------------------------------------------------------------
********************************************
Hippocms-dev: Hippo CMS development public mailinglist
