Unexpected Passthru HTML Behaviour From Agent
Yesterday somebody broke (what is it with people!?) the demo by typing </ > in to a text field for a document in the view. This broke the XML. Not for the obvious reasons though. Read on for what happened.
The agent that outputs the "view" to the Flex app starts with this line:
Print "Content-Type: text/xml"
Now then. If I start an agent with that line I then expect to be in complete control. Anything I print out from the agent after that line is sent to the browser as is.
So, if I have the following line of LotusScript:
Print |<description><![CDATA[<test>]]></description>|
I expect the browser to receive the following XML:
<description><![CDATA[<test>]]></description>
The CDATA section means you can output what you like inside it without worrying about it breaking the HTML. Imagine my surprise (that's the polite way of putting it) to find browser actually received the following:
<description><![CDATA<test>]]></description>
That's what broke the demo. The Domino server broke my code!
The missing square bracket made the XML malformed and invalid. The bracket was missing because the Domino server assume that an open square bracket following directly by an open angle bracket means you want to enable passthru HTML mode. Whatever your thoughts on passthru the fact is it shouldn't kick in when printing from an agent. Surely?
Now, I'm about to press publish from Windows Live Writer and am half expected the whole post to break as the body of the created blog will itself contain the magic passthru-enabling combination of open brackets.
Domino, oh Domino...
Skip to the 
You can subscribe to an individual
If I may?
http://www.youtube.com/watch?v=91s8xaywBaI
:D
Urgh! Man, that's horrible.
On a side note. I'm not a big fan of using CDATA. I've seen too many apps break when some smart arse shoves the closing double square, single angle into the output and everything goes pop. It's much easier to just escape and unescape the xml as needed.
Obviously there are places where if can guarantee that what the input doesn't itself contain a CDATA block you will save time processing that, but often that's not the case.
Cue anecdote of Websphere 5 webservices that decide when a payload is bigger than X then switch from escaping to wrapping in CDATA. Watch as your code breaks when add one extra char in your input. Then beat your head against a desk when you figure this out and then have to escape and unescape your own content so websphere doesn't bork it all up.
Deep breaths. Breathe... Relax ;)
You must add a space between [ and < ...
That "solves" the problem Philippe, but it's not really a fix as it introduces other issues.
Jake:
Can you double check the output from domino?
From the posting, it looks like domino removed the "start passthru" ( open square, less than ) replacing it with (less than) but it did not properly handle the "end passthru" (greater than, close square)
In other words <test> should only have one square bracket after it, not two.
What "other issues" are introduced when you use blank
between [ and < ?
<![CDATA[ <test> ]]> should be OK.
If you don't ever need the square bracket passthru html feature on your server, you can disable it completely with notes.ini
DominoDisablePassthruHTML=1
Ha! Funny bug. Perhaps that's why everytime I've ever seen "<![CDATA[" it always had a linebreak after it!
Hi Mark. My mistake. I've reproduced it and can see there was indeed only one ] after the closing >
The problems with using a space are more to do with presentation and application logic than any server-side problems.
In this case, with the Flex "view" you get an extra padding to the left of the column. Then when you edit the row and submit the value as a field value you end up with a leading space saved to the actual document. It's all just very messy.
Jake
When faced by the same problem in the past I have solved it by checking the first character of the data and if it is "<" then insert an extra "[" first.
I had a similar problem when using CDATA in an embedded view. I found that adding an extra pair of square brackets solved the problem, as Domino would remove the innermost pair, leaving just the extra ones. For example:
<![CDATA[[<test>]]]>
Jake, thanks for double checking. At least there is only one problem and not two :( If you can't disable passthru
completely, then as @Dave and @Mattias point out, adding the extra [ ] is probably the best bet.
(The domino WriteTextData() function -- where all your output is collected -- needs a small but steady diet of square brackets to keep it going :)
As a bit of historical trivia, the stripping of square bracket in what should otherwise be "raw" characters was actually added to provide backward compatibility. Someone had square bracket passthru inside a filed also marked with paragraph style "HTML" and complained that they were seeing the brackets when they didn't on the previous release (This back from 4.x days). So any fix to this issue going forward would have to be tied to an ini.
This workaround worked for us (we used Java, you can translate with Lotusscript):
String result = "<description><![CDATA[<test>]]></description>"
result = result.replaceAll("\\[<", "[[<");
result = result.replaceAll(">\\]", ">]]");
PrintWriter pw = getAgentOutput();
pw.println (result);