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
To: flex-dev@incubator.apache.org
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 [mailto:rol...@stackandheap.com]
Sent: Sunday, October 28, 2012 10:12 AM
To: flex-dev@incubator.apache.org
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 ;)

--
regards,
Roland

--
Roland Zwaga
Senior Consultant | Stack & Heap BVBA

+32 (0)486 16 12 62 | rol...@stackandheap.com | 
+http://www.stackandheap.com

http://zwaga.blogspot.com
http://www.springactionscript.org
http://www.as3commons.org

Reply via email to