Lansa Editor still rewrites my code

A follow-up to the other post from last year, I have now experienced this in a new and disturbing way.

I realize that this code is not pretty but it was just a quick job that I would fix later. In this case, I added some javascript that would append an HTML element with an attribute. The javascript used double-pings (“) and the attribute would then use pings (‘):


Unfortunately, when checking in the changes the Lansa Editor changed the pings to double-pings, rendering my code buggy.

Lansa Editor rewriting my code

This happened in v.12.5 and continues to happen in v.14: When I write XSLT I may write something that is perfectly valid and correct (at least, most of the time) and which produces no errors.

But then, when I reload the command handler the next day, I am not getting the same code. The Lansa Editor has rewritten my code to something else that is perfectly valid and correct (and indented differently) but which the Lansa Editor now reports an error in.

Without a doubt this is an error that comes from the rewriting and now, everytime I save, compile or check-in, I see this:


It happens when I have used <![CDATA[ … ]]> and <xsl:text disable-output-escaping=”yes”> … </xsl:text>. The Lansa Editor removes the <![CDATA[ … ]]> and replaces the characters with the proper entities, but chokes on it itself.

A bug in the editor

It turns out that the error I got trying to access the XSLT source (not the missing shortcut, the crash) was due to a bug in the editor. I had a


with no <tbody>. Yes, I know.

But the editor checked the XSLT and appears to think it is fine. Then the renderer took over and crashed, due to the missing <tbody>.

Fortunately I found the XSLT in the temp cache so with the supplier’s help I could regenerate the XSLT (deleting all my work) and reinsert my code, now with the <tbody> tag.