You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Roland Zwaga <ro...@stackandheap.com> on 2012/10/28 18:11:48 UTC
Does Falcon need to take CDATA sections into account when parsing ?
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 | roland@stackandheap.com | http://www.stackandheap.com
http://zwaga.blogspot.com
http://www.springactionscript.org
http://www.as3commons.org
RE: Does Falcon need to take CDATA sections into account when
parsing ?
Posted by Gordon Smith <go...@adobe.com>.
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:roland@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 | roland@stackandheap.com |
+http://www.stackandheap.com
http://zwaga.blogspot.com
http://www.springactionscript.org
http://www.as3commons.org
Re: Does Falcon need to take CDATA sections into account when parsing ?
Posted by Roland Zwaga <ro...@stackandheap.com>.
good point ;)
On 30 October 2012 21:13, Gordon Smith <go...@adobe.com> wrote:
> The switch should eventually be a new language namespace specifying a new,
> improved version of MXML such as xmlns:fx="http://ns.adobe.com/mxml/2013"
> for MXML 2013.
>
> - Gordon
>
> -----Original Message-----
> From: Roland Zwaga [mailto:roland@stackandheap.com]
> Sent: Tuesday, October 30, 2012 3:19 AM
> To: flex-dev@incubator.apache.org
> Subject: Re: Does Falcon need to take CDATA sections into account when
> parsing <fx:string/>?
>
> Yea, I guess in this case back-ward compatibility beats purely correct
> behaviour. The very best option would probably be a -compatibility switch,
> but that might complicate things more?
> If this is the only case where we run into a scenario like this, that
> might be overkill. But perhaps if we stumble upon more cases we could
> consider such a switch?
>
> Roland
>
>
> > 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?
> >
>
--
regards,
Roland
--
Roland Zwaga
Senior Consultant | Stack & Heap BVBA
+32 (0)486 16 12 62 | roland@stackandheap.com | http://www.stackandheap.com
http://zwaga.blogspot.com
http://www.springactionscript.org
http://www.as3commons.org
RE: Does Falcon need to take CDATA sections into account when
parsing ?
Posted by Gordon Smith <go...@adobe.com>.
The switch should eventually be a new language namespace specifying a new, improved version of MXML such as xmlns:fx="http://ns.adobe.com/mxml/2013" for MXML 2013.
- Gordon
-----Original Message-----
From: Roland Zwaga [mailto:roland@stackandheap.com]
Sent: Tuesday, October 30, 2012 3:19 AM
To: flex-dev@incubator.apache.org
Subject: Re: Does Falcon need to take CDATA sections into account when parsing <fx:string/>?
Yea, I guess in this case back-ward compatibility beats purely correct behaviour. The very best option would probably be a -compatibility switch, but that might complicate things more?
If this is the only case where we run into a scenario like this, that might be overkill. But perhaps if we stumble upon more cases we could consider such a switch?
Roland
> 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?
>
Re: Does Falcon need to take CDATA sections into account when parsing ?
Posted by Roland Zwaga <ro...@stackandheap.com>.
Yea, I guess in this case back-ward compatibility beats purely correct
behaviour. The very best option would probably be a -compatibility switch,
but that might complicate things more?
If this is the only case where we run into a scenario like this, that might
be overkill. But perhaps if we stumble upon more cases we could consider
such a switch?
Roland
> 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?
>
Re: Does Falcon need to take CDATA sections into account when parsing ?
Posted by Om <bi...@gmail.com>.
On Mon, Oct 29, 2012 at 12:47 PM, Gordon Smith <go...@adobe.com> wrote:
> 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.
>
This is an obvious case, but I think we should fix bugs/inconsistencies
whenever we get a chance.
>
> Could we live with Falcon compiling it as a string with one space,
> regardless of whether there is CDATA or not?
>
Yes, that would the best approach.
Thanks,
Om
> - 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:roland@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 | roland@stackandheap.com |
> +http://www.stackandheap.com
>
> http://zwaga.blogspot.com
> http://www.springactionscript.org
> http://www.as3commons.org
>
RE: Does Falcon need to take CDATA sections into account when
parsing ?
Posted by Gordon Smith <go...@adobe.com>.
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:roland@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 | roland@stackandheap.com |
+http://www.stackandheap.com
http://zwaga.blogspot.com
http://www.springactionscript.org
http://www.as3commons.org