5

When saving to a rich text field via Core Service my HTML is not as desired. During create tags like:

<a id="abc" name="abc"></a>

become:

<a id="abc" name="abc"/>

I have added to the XSLT to try and prevent this:

<template match="a[(@name) and (count(node()) = 0)]">
   <copy>
      <apply-templates select="@*"></apply-templates>
      <span class="hidden"></span>
   </copy>
</template>

but no joy!

It seems to apply the base XSLT when creating via Core Service. Then if I open the component and make any changes my updated XSLT appies and the HTML updates to:

<a id="abc" name="abc">
   <xhtml:span xmlns:xhtml="http://www.w3.org/1999/xhtml" class="hidden"></xhtml:span>
</a>
  • What is going on with your namespaces there? if the default namespace is for xsl, then why do you get xhtml:span ? – Dominic Cronin May 3 '13 at 20:11
4

I've just written a quick script that creates a component via the core service. FWIW, the powershell exposes ComponentData.Content as a string, and I just shoved in something like:

<Content xmlns="uuid:985d42e5-976f-46e1-9727-772cb961353f">
<NewField></NewField>
</Content>

This showed up exactly like that in the component.

I wouldn't expect the RTF XSLT to modify the content when written via the core service (or TOM.NET or any other API. The XSLT cleanup is a GUI operation, albeit these days implemented via a back-end service. If you create content via code, it's on you to send clean data. Obviously, when you open the component up in the GUI, the slightest modification will cause the XSLT to fire.

So to summarise: it doesn't look like the data goes via an XML document to get across the wire to the core service. (Mind you, I'm using nettcp = hope /that/ abstraction isn't leaking!) Usually when <x></x> gets transformed to <x/> it's because the document has been deserialised to the infoset representation. So does your implementation load this into a DOM?

Edit: Per your comment suggestion, I altered my input. I had to put the p in the xhtml namespace, and provide a closing

, but on opening via the gui, I found this in the source.

<Content xmlns="uuid:985d42e5-976f-46e1-9727-772cb961353f">
<NewField>
  <p xmlns="http://www.w3.org/1999/xhtml">this is a test <a name="abc" id="abc"></a></p>
</NewField>
</Content>

... so still, the conclusion remains that it may not be the core service that is collapsing your elements.

Further edit:

In the source tab of the RTF I get: <p>this is a test <a name="abc" id="abc"/></p>

  • Is NewField of type RTF? If so add <Content xmlns="uuid:985d42e5-976f-46e1-9727-772cb961353f"> <NewField><p xmlns="w3.org/1999/xhtml">this is a test <a name="abc" id="abc"></a></NewField> </Content> – Chris Morgan May 3 '13 at 20:39
  • If it behaves as per my implementation you will end up with <p xmlns="w3.org/1999/xhtml">this is a test <a name="abc" id="abc" /></p> at publish/preview time – Chris Morgan May 3 '13 at 20:54
  • I've updated, my answer. I note that you mention publish/preview time. What do you see when you open up the component in the GUI? Could it be a templating issue? – Dominic Cronin May 3 '13 at 21:04
  • Thanks for checking this out! Is this the "source" tab of the component? What do you see in the "source" tab of the rich text field? – Chris Morgan May 3 '13 at 21:05
  • I see that my component.Content before CoreService.Create has the closing anchor tag, and immediately after it does not have closing anchor. – Chris Morgan May 3 '13 at 21:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.