Preserving Whitespace When Storing Adobe TLF's XML On A Server
This is one of those blog entries I hope will help future Googlers. Probably not worth a read by my regular readers - although there is perhaps something to learn within.
Flash player 10 introduced a new Framework called Text Layout (TLF) which lets you edit and display Rich Text in Flex.
TLF came in really handy on a project I worked this year, which let students create and save posters with their own photos and text in.
The text part of the Flex-based poster-making application is a RichEditableText component which has a toolbar above it - allowing them to change font style, face and colour in the TextFlow element it contained.
Everything worked well until, being kids, they had a go at creating rainbow text -- where every subsequent word is a different colour, which broke it.
Here's a very simple example of how it broke the editor. Notice the rich text has one word in red. Now press the second button below it, which says "broken". The whitespace surrounding the word in red is stripped out.
The button exports the TLF-based XML from the editor and then re-imports it straight back in.
The code for the above Flex app is here.
The XML produced by the TextFlow's export method looks similar to this:
<p><span>Click here to start</span> <span color="red">editing</span> <span>your poster</span></p>
The spaces on either side of the red word are there, but, as we all know, XML "abhors whitespace" and so it gets stripped out.
To get round this we can tell Flex's XML class not to ignore whitespace. Like so:
var originalSettings:Object = XML.settings(); XML.ignoreProcessingInstructions = false; XML.ignoreWhitespace = false; XML.prettyPrinting=false; var t:String = null; try { t=TextFlowUtil.export(this.textFlow).toString(); } catch(e:Error){ } finally { XML.setSettings(originalSettings); }
The XML then looks something like this:
<p><span>Click here to start</span><span> </span><span color="red">editing</span><span> </span><span>your poster</span></p>
Notice the spaces have been added in to span elements of their own.
Round-Tripping With a Server
The above workaround is all very well but it's not as simple as adding a line or two of code.
Here are two other gotchas I stumbled upon which meant this bug took a lot, lot longer to resolve than I'd have hoped.
- If you're using SQL Server in the backend make sure the column isn't of XML data type. This will turn "<span> </span>" in to "<span />" and break it regardless of the above ActionScript workaround.
- If you use an HTTPService to fetch the XML for the TextFlow of saved posters from the database make sure it has a result format of "text" (not "E4X" or "XML") as this will do the string-to-XML conversion for you before you have chance to apply the workaround. Cast it to XML in the result event instead, after setting the new XML settings.
Hope this helps somebody in the future.
Didn't realize the poster app had gone live. Glad to hear that it did and that you worked out the issue.
Reply
Yeah, been in semi-official "beta" testing for a few months now. Just weeding out the annoyances like this one.
Thanks again for the referral Jorge.
I have permission to talk about the app in detail on here, so hope to show-case it as some point soon. Did you see it yet? I'm quite proud of the outcome.
Reply
Show the rest of this thread
It's important to apply the same changes to the XML settings when importing the data.
Thanks, this was exactly what i was looking for!
Reply