incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Smith <>
Subject RE: Does Falcon need to take CDATA sections into account when parsing <fx:string/>?
Date Mon, 29 Oct 2012 19:47:45 GMT
It's more complicated than I thought.

I tried it in FB 4.6 (i.e., with the old compiler). If you have a one space inside the <String>
tag without a CDATA section around it, then the value is null. But with CDATA around the space,
the value is a string with one space character.

In my opinion, this behavior of the old compiler is inconsistent and should be considered
a bug. So we have to decide how bug-compatible we want Falcon to be with the old compiler.
It may be difficult to even achieve bug-compatibility in cases like this.

Could we live with Falcon compiling it as a string with one space, regardless of whether there
is CDATA or not?

- Gordon

-----Original Message-----
From: Gordon Smith 
Sent: Monday, October 29, 2012 10:17 AM
Subject: RE: Does Falcon need to take CDATA sections into account when parsing <fx:string/>?

This is a bug.

The tests in MXMLBooleanNode are more complete that for other primitive tags. I added a test
to MXMLBooleanNode that shows CDATA works inside of <Boolean>. Each of the primitive
tags needs this kind of test.

- Gordon

-----Original Message-----
From: Roland Zwaga []
Sent: Sunday, October 28, 2012 10:12 AM
Subject: Does Falcon need to take CDATA sections into account when parsing <fx:string/>?

Hi there,

I've been taking my few first uncertain steps into grokking the Falcon sources. I was looking
at the MXMLStringNode tests and wanted to see if the parser takes into account CDATA sections
in them.
So I added a test that set up an <fx:string/> node like this:

String code = "<fx:String><![CDATA[ ]]></fx:String>"; //The CDATA section
here contains a single space IMXMLStringNode node = getMXMLStringNode(code); assertThat("getValue",
node.getValue(), is(" "));

Now, this test fails, because the node.getValue() returns null. IMHO, this is incorrect behaviour,
since CDATA sections should be parsed literally without any assumptions or postprocessing.

Does everyone agree on this? Thoughts please ;)


Roland Zwaga
Senior Consultant | Stack & Heap BVBA

+32 (0)486 16 12 62 | | 

View raw message