I figured it out and committed a fix.
> On Aug 28, 2017, at 12:07 PM, Harbs wrote:
>
> Given the following XML in Flash:
> var xml:XML = ;
> xml.bar.foo.baz = "baz";
>
> You get an XML structure like so:
>
>
>
>
>baz
>
>
>
>
>
> In JS, this compiles to the fol
Hi,
> I assume you tested this with regular Flex and not the Falcon compiler? I
> just want to verify a couple of your findings.
Be aware there are existing unresolved bugs in the Flex SDK in this area i.e.
[1]
Thanks,
Justin
1. https://issues.apache.org/jira/browse/FLEX-33644
> On Jul 18, 2017, at 6:13 PM, Alex Harui wrote:
>
> I assume you tested this with regular Flex and not the Falcon compiler?
Yes.
> I just want to verify a couple of your findings.
>
> 1) Does passing empty string really produce an XML object with no children
> or is there a child textNode wi
I assume you tested this with regular Flex and not the Falcon compiler? I
just want to verify a couple of your findings.
1) Does passing empty string really produce an XML object with no children
or is there a child textNode with ""?
2) If you pass in an XMLList with one element, doesn't
var
Actually, it’s not really necessary to allow null and undefined to get an empty
XML object. The constructor can default to en empty string. So an empty string
could get an XML object while null and undefined could throw an error.
That might make more sense because it would likely catch more erro
I discovered that the documentation on the top level functions is wrong.
According to the docs[1] the only valid expressions for XML and XMLList are:
XML, XMLList, Boolean, Number and String. Anything else is supposed to throw an
error.
What actually happens is that null and undefined are simpl
Hi,
> We might keep around a Language class for things "every" app will need
> (is/as, maybe some coercions). But trace, sortOn, Vector should be PAYG.
Currently the SDK itself uses trace (including in a few core classes [1]) so
unless they are removed it's likely you end up with the code for t
We might keep around a Language class for things "every" app will need
(is/as, maybe some coercions). But trace, sortOn, Vector should be PAYG.
-Alex
On 7/17/17, 10:20 PM, "Harbs" wrote:
>Another reason to not add to Language is that it would make Language
>depend on XML.
>
>I’ll try to write
Another reason to not add to Language is that it would make Language depend on
XML.
I’ll try to write these functions today.
I don’t mind breaking up utility classes, but the Language class will need
changes to the compiler. It looks like it’s more than just replacing
org.apache.flex.utils.Lan
IMO, toXML() is more PAYG. We really shouldn't keep adding to Language.
I'm going to figure out why your standalone functions like callLater,
assert, etc, aren't handled correctly then we should seriously think about
finding a volunteer to break up these utility classes into utility
functions sin
I believe you are right in Flash. Same for XMLList().
I’d be happy to write the functions. Should we do a top level toXML() or
Language.XML() and Language.XMLList()?
The latter seems to fit the pattern for the rest of the language features.
> On Jul 18, 2017, at 12:24 AM, Alex Harui wrote:
>
Pretty sure in AS for Flash, you can write (without "new"):
var herbs:XML = XML(someXMLListWithOneElement);
And it will "do the right thing".
I guess we will have to create Language.XML or add a static toXML() on XML
and have the compiler catch the top-level function call and redirect it to
th
I just tried to see if it might work, but I get an error. Obviously that’s a
no-no...
[java]
/Users/harbs/Documents/ApacheFlex/flex-asjs/frameworks/projects/XML/src/main/flex/XML.as(317):
col: 13 A return value is not allowed in a constructor.
[java]
[java]
I don’t think so. Write one where? How? We already have a top level XML
constructor.
Wouldn’t the compiler output:
XML(myXML)
as:
org.apache.flex.utils.Language.as(myXML,XML)?
I’m pretty sure the only way to instantiate an XML object is to use new.
Well, I just tried XML(myXMLList) and it does
I thought we (you) already wrote one. If not, we won't we need one?
-Alex
On 7/17/17, 12:01 PM, "Harbs" wrote:
>Thanks for the pointer.
>
>I changed the emitter to output indexed access. It seems to work. :-)
>(committed)
>
>I’m not sure what you mean about the top level XML function. How does
Thanks for the pointer.
I changed the emitter to output indexed access. It seems to work. :-)
(committed)
I’m not sure what you mean about the top level XML function. How does that work
in Javascript?
> On Jul 17, 2017, at 7:47 PM, Alex Harui wrote:
>
> You can try #2 by changing ForEachEmit
You can try #2 by changing ForEachEmitter.java.
For the general problem, we should probably just use the XML() top-level
function to "coerce" XMLList to XML.
My 2 cents,
-Alex
On 7/17/17, 9:23 AM, "Harbs" wrote:
>That is a fourth option.
>
>In terms of overhead, option #2 is probably cheapest
That is a fourth option.
In terms of overhead, option #2 is probably cheapest and option #4 is probably
most expensive.
What’s the difference in terms of difficulty of changing the compiler?
I agree with the general problem. It could be that we should to a function to
XMLList toXML() (or somet
IMO, this points out a generic problem where in ActionScript:
var harbs:XML = SomeXMLListWithOneElement;
would auto-coerce the XMLList to XML by grabbing the one element. So we
have to deal with that some day. But there is probably a quick fix in the
generated code for "for each" where we jus
On 4/20/17, 9:06 AM, "Alex Harui" wrote:
>My bad. I see it now. It was buried in the other output. I'll take a
>look.
I pushed changes to flex-typedefs to fix the Error.toString() issue.
-Alex
On 4/20/17, 4:01 AM, "Harbs" wrote:
>
>> On Apr 20, 2017, at 6:20 AM, Harbs wrote:
>>
>>> I just pushed a change to handle the @prop cases.
>>
>@prop cases are working. Thanks.
>
>> Thanks. I’ll give it a spin.
>>
>>> I'm not seeing the errors with the Error class,
>
>I’m still getting this
> On Apr 20, 2017, at 6:20 AM, Harbs wrote:
>
>> I just pushed a change to handle the @prop cases.
>
@prop cases are working. Thanks.
> Thanks. I’ll give it a spin.
>
>> I'm not seeing the errors with the Error class,
I’m still getting this.
I just pushed a change to the tlf branch where I
> On Apr 20, 2017, at 2:24 AM, Alex Harui wrote:
>
> I just pushed a change to handle the @prop cases.
Thanks. I’ll give it a spin.
> I'm not seeing the errors with the Error class, and I am seeing other
> potential issues where XML.appendChild might have the parameter typed as
> XML.
What is
I just pushed a change to handle the @prop cases.
I'm not seeing the errors with the Error class, and I am seeing other
potential issues where XML.appendChild might have the parameter typed as
XML.
HTH,
-Alex
On 4/19/17, 12:00 AM, "Harbs" wrote:
>Huh.
>
>It seems like it was not committed.
>
>
Huh.
It seems like it was not committed.
I just committed it.
Sorry about that.
> On Apr 19, 2017, at 2:58 AM, Harbs wrote:
>
> Yes there should it’s located in:
> org.apache.flex.textLayout.factory.FactoryBackgroundManager and it extends
> BackgroundManager.
>
>> On Apr 19, 2017, at 2:56 A
Yes there should it’s located in:
org.apache.flex.textLayout.factory.FactoryBackgroundManager and it extends
BackgroundManager.
> On Apr 19, 2017, at 2:56 AM, Alex Harui wrote:
>
> I cannot find a FactoryBackgroundManager.as. Should there be one?
> FactoryComposer is looking for it.
>
> -Alex
I cannot find a FactoryBackgroundManager.as. Should there be one?
FactoryComposer is looking for it.
-Alex
On 4/18/17, 11:50 PM, "Harbs" wrote:
>I’m not sure why you’d be getting that error.
>
>I’m done for the day.
>
>> On Apr 19, 2017, at 2:48 AM, Alex Harui wrote:
>>
>> I got an error loo
I’m not sure why you’d be getting that error.
I’m done for the day.
> On Apr 19, 2017, at 2:48 AM, Alex Harui wrote:
>
> I got an error looking for FactoryBackgroundManager. Am I doing something
> wrong?
>
> -Alex
>
> On 4/18/17, 10:57 PM, "Harbs" wrote:
>
>> I have committed my changes to
I got an error looking for FactoryBackgroundManager. Am I doing something
wrong?
-Alex
On 4/18/17, 10:57 PM, "Harbs" wrote:
>I have committed my changes to the tlf branch. Theoretically, you should
>get the same errors when trying to compile TLF.
>
>> On Apr 19, 2017, at 1:54 AM, Harbs wrote:
I have committed my changes to the tlf branch. Theoretically, you should get
the same errors when trying to compile TLF.
> On Apr 19, 2017, at 1:54 AM, Harbs wrote:
>
> JS compile.
>
> I added the following to the library-paths:
>../../../../../libs/XMLJS.swc
>
> -compiler.str
JS compile.
I added the following to the library-paths:
../../../../../libs/XMLJS.swc
-compiler.strict-xml is set to true.
I tried changing it to false and it did not help.
> On Apr 19, 2017, at 1:48 AM, Alex Harui wrote:
>
> Is this the SWF or JS compile? Where do the defini
Is this the SWF or JS compile? Where do the definitions for XML and Error
come from? JS.swc, playerglobal?
Did you try -compiler.strict-xml true and false?
Thanks,
-Alex
On 4/18/17, 10:29 PM, "Harbs" wrote:
>TLF was missing EditManager. I added that, but it required XML as well,
>so I added
No. You never get null for XML (unless it’s an XML typed variable which was
never set).
On Aug 8, 2016, at 12:45 AM, Alex Harui wrote:
>
>
> On 8/7/16, 2:04 PM, "Harbs" wrote:
>
>> Yes. That would be better (only 1.5KB), but only in this case. Assigning
>> a null value to a string should no
A directive is fine.
On Aug 8, 2016, at 8:35 AM, Alex Harui wrote:
>
>
> On 8/7/16, 2:04 PM, "Harbs" wrote:
>
>> Yes. That would be better (only 1.5KB), but only in this case. Assigning
>> a null value to a string should not covert it into an empty string.
>>
>> I was suggesting to have an
On 8/7/16, 2:04 PM, "Harbs" wrote:
>Yes. That would be better (only 1.5KB), but only in this case. Assigning
>a null value to a string should not covert it into an empty string.
>
>I was suggesting to have an option to not do any conversions.
>
>Right now my code works without any string conver
On 8/7/16, 2:04 PM, "Harbs" wrote:
>Yes. That would be better (only 1.5KB), but only in this case. Assigning
>a null value to a string should not covert it into an empty string.
For XML, do you ever get null?
-Alex
Yes. That would be better (only 1.5KB), but only in this case. Assigning a null
value to a string should not covert it into an empty string.
I was suggesting to have an option to not do any conversions.
Right now my code works without any string conversion at all. This is because
of the “string
On 8/7/16, 12:09 PM, "Harbs" wrote:
>Sure.
>
>Here’s a couple of examples:
>
>f.leading = xml.Properties.Leading;
>f.tracking = xml.@Tracking;
>
>I have 492 some assignments like this scattered across my code. Adding
>toString() to every one of these would add 5412 bytes to the final
>minified
On 8/7/16, 9:42 AM, "Harbs" wrote:
>Not faster. Smaller.
>
>I’m sure there’s no much difference speed-wise.
Why are you so sure? Function call overhead is significant in AS. Why
isn't it so in JS?
-Alex
Sure.
Here’s a couple of examples:
f.leading = xml.Properties.Leading;
f.tracking = xml.@Tracking;
I have 492 some assignments like this scattered across my code. Adding
toString() to every one of these would add 5412 bytes to the final minified
code. That’s not including non-XML assignments t
Not faster. Smaller.
I’m sure there’s no much difference speed-wise.
Once we add type safety to default values, it’ll be a bigger difference in
terms of code size.
On Aug 7, 2016, at 5:47 PM, Alex Harui wrote:
>
>
> On 8/7/16, 2:19 AM, "Harbs" wrote:
>
>> BTW, I think another change to La
On 8/7/16, 1:55 AM, "Harbs" wrote:
>To sum up:
>
>There are a number of issues involved here.
>
>What started with a concern about implicit type conversions on XML turned
>into a much broader issue.
>
>In ActionScript, when you assign any object type to typed variable of a
>primitive type (or re
On 8/7/16, 2:19 AM, "Harbs" wrote:
>BTW, I think another change to Language is a good idea:
>
>Currently default function parameters are compiled like this:
>
>public static function getBottomValue(value:Object, values:Object,
>reference:Number = NaN):Number
>{
>return getSideValue(value, v
> One thing that might not be clear:
>
> Coercion should only happen on *assignment*. Coercion on comparisons should
> not happen because the conversions happen implicitly in the JS engine if
> required.
>
> On Aug 7, 2016, at 7:39 AM, Harbs wrote:
>
>> This dis
e.as(qNameOrUri,
>>>>>>> Namespace).prefix;
>>>>>>> if (localNameVal)
>>>>>>> this._localName = localNameVal.toString().toString();
>>>>>>> } else if (localNameVal) {
>>>>>>> thi
On 8/6/16, 9:39 PM, "Harbs" wrote:
>This discussion fell off the dev list...
>
>Begin forwarded message:
>
>> From: Harbs
>> Subject: Re: FlexJS XML string assignment
>> Date: August 6, 2016 at 11:50:29 PM GMT+3
>> To: Alex Harui
>>
&
On 8/5/16, 8:05 AM, "Harbs" wrote:
>I just checked and Number(obj) is equivalent to Number(obj.valueOf())
>
>Like so:
>var a = {valueOf : function(){return "5"},toString:function(){return "6”}}
>
>Number(a) //5
>Number(a.valueOf()) //5
>Number(a.toString()) //6
>
>So valueOf() needs to return a
I just checked and Number(obj) is equivalent to Number(obj.valueOf())
Like so:
var a = {valueOf : function(){return "5"},toString:function(){return "6”}}
Number(a) //5
Number(a.valueOf()) //5
Number(a.toString()) //6
So valueOf() needs to return a value that Number will properly accept.
Harbs
On second thought, this is probably wrong.
Number(xml) is probably enough as Number should call toString() and deal with
all number types correctly.
On Aug 5, 2016, at 5:42 PM, Harbs wrote:
> If it knows it’s being assigned to a Number, I think it should call
> valueOf(), or possibly(Number(x
For cases where the compiler knows that XML is being assigned to a string, it
should add toString().
If it knows it’s being assigned to a Number, I think it should call valueOf(),
or possibly(Number(xml.valueOf())
There will likely be cases where the compiler will not know the types that the
X
I have not spent time thinking about this, but the compiler generally
knows the destination type. The compiler is going to have to learn when
to inject coercion code where AS would do an implicit conversion that JS
won't.
So fundamentally: what does XML valueOf do in AS? The XML JS
implementatio
I implemented this locally and the idea works pretty well for the most part.
We still need to do toString() when possible because of edge cases.
For example: stringFromXmlList1 == stringFromXmlList2 fails because the
Javascript engine does not try to convert them (correctly) to primitive values.
I’m thinking that I should implement valueOf() for XML like this:
var str:String = this.toString();
var asInt:int = parseInt(str);
if(asInt.toString() == str)
return asInt;
var asFloat:Number = parseFloat(str);
if(asFloat.toString() == str)
return asFloat;
return str;
Thi
Another error:
var resultXML:XML = XML(resString);
becomes:
var /** @type {XML} */ resultXML = org.apache.flex.utils.Language.as(resString,
XML, true);
When in fact it should become:
var /** @type {XML} */ resultXML = new XML(resString);
Do you want me to create a JIRA for this?
On Aug 4, 201
On 8/4/16, 7:22 AM, "Harbs" wrote:
>I’m not sure how to deal with this case:
>
>
>private var name:String;
>
>this.name = someXML.@Name;
>
>The above compiles to
>
>this.name = someXML.attribute('Name’);
>
>In Javascript this.name becomes an XMLList, but in Flash, the XMLList is
>implicitly con
I thought I fixed this. Is it not working?
Sent from my LG G3, an AT&T 4G LTE smartphone
-- Original message--
From: Harbs
Date: Sat, May 14, 2016 11:53 PM
To: dev@flex.apache.org;
Subject:Re: [FlexJS][XML]appending XMLLists
Alex,
Can you look at this?
On May 12, 2016, at 2:56 PM, Harb
Alex,
Can you look at this?
On May 12, 2016, at 2:56 PM, Harbs wrote:
> I committed my changes, but I need you to look at it.
>
> I commented out the test to get it to compile, but besides that, there’s
> definitely a problem:
>
> 198: ERROR - Parse error. invalid assignment target
> [j
Results should be in
compiler-jx/target/junit-results/TEST-org.apache.flex.compiler.internal.cod
egen.js.flexjs.TestFlexJSGlobalClasses.xml
-Alex
On 5/12/16, 3:40 AM, "Harbs" wrote:
>Well I tried this, but something is wrong.
>
>I changed the tests to reflect my changes and I’m getting an error
I committed my changes, but I need you to look at it.
I commented out the test to get it to compile, but besides that, there’s
definitely a problem:
198: ERROR - Parse error. invalid assignment target
[java] this.xml2.child('a') = this.xml2.child('a').plus(new XML( ''));
The original co
Well I tried this, but something is wrong.
I changed the tests to reflect my changes and I’m getting an error in the tests
(in TestFlexJSGlobalClasses). How can I see the results of the test to see
what’s wrong?
On May 10, 2016, at 6:09 PM, Alex Harui wrote:
>
>
> On 5/10/16, 8:03 AM, "Harb
On 5/10/16, 8:03 AM, "Harbs" wrote:
>foo = foo.plus(bar);
OK, well in theory the compiler generated "foo" and is about to add
".concat(" so you would get "foo.concat(" then "bar" would get emitted.
Try replacing ".concat" with:
" = "
getWalker().walk(node.getLeftOperandNode()); // should re
foo = foo.plus(bar);
On May 10, 2016, at 5:58 PM, Alex Harui wrote:
> IOW, what is the full JS you want generated for foo += bar?
On 5/10/16, 2:40 AM, "Harbs" wrote:
>I’m not sure I totally understand the pattern:
>
> else if (node.getNodeID() == ASTNodeID.Op_AddAssignID)
> {
> getWalker().walk(xmlNode);
> write(".concat(");
>
I’m not sure I totally understand the pattern:
else if (node.getNodeID() == ASTNodeID.Op_AddAssignID)
{
getWalker().walk(xmlNode);
write(".concat(");
getWalker().walk
On May 9, 2016, at 8:21 PM, Alex Harui wrote:
>
>
> On 5/9/16, 9:44 AM, "Harbs" wrote:
>>> OK, after more reading, I think section 7.1.2 confirms your assumption.
>>> But based on the algorithm and that knowledge, do you see any issues
>>> with
>>> the Flash implementation? Yes, it is puzzli
On 5/9/16, 9:44 AM, "Harbs" wrote:
>>OK, after more reading, I think section 7.1.2 confirms your assumption.
>> But based on the algorithm and that knowledge, do you see any issues
>>with
>> the Flash implementation? Yes, it is puzzling that targetObject gets
>> assigned before the elements are
On May 9, 2016, at 6:14 PM, Alex Harui wrote:
>
>
> On 5/9/16, 12:00 AM, "Harbs" wrote:
>
>>
>> On May 9, 2016, at 8:10 AM, Alex Harui wrote:
>>
>>>
>>>
>>> On 5/8/16, 1:18 AM, "Harbs" wrote:
>>>
I’m still having trouble with the spec, though. The spec has the
following in [
On 5/9/16, 12:00 AM, "Harbs" wrote:
>
>On May 9, 2016, at 8:10 AM, Alex Harui wrote:
>
>>
>>
>> On 5/8/16, 1:18 AM, "Harbs" wrote:
>>
>>> I’m still having trouble with the spec, though. The spec has the
>>> following in [[Append]]:
>>>
>>> 3. If Type(V) is XMLList,
>>> a. Let x.[[TargetOb
On May 9, 2016, at 8:10 AM, Alex Harui wrote:
>
>
> On 5/8/16, 1:18 AM, "Harbs" wrote:
>
>> I’m still having trouble with the spec, though. The spec has the
>> following in [[Append]]:
>>
>> 3. If Type(V) is XMLList,
>> a. Let x.[[TargetObject]] = V.[[TargetObject]]
>> b. Let x.[[TargetProp
On 5/8/16, 1:18 AM, "Harbs" wrote:
>I’m still having trouble with the spec, though. The spec has the
>following in [[Append]]:
>
>3. If Type(V) is XMLList,
> a. Let x.[[TargetObject]] = V.[[TargetObject]]
> b. Let x.[[TargetProperty]] = V.[[TargetProperty]]
> c. Let n = V.[[Length]]
> d. If
OK. You are right about this.
When I do this:
list1 += list4 + xml2.z;// leaving out xml2.z prevents the next line from
adding to the original xml
list1[list1.length()] = ;
I get:
http://ns.adobe.com/mxml/2009";>
hi
yeah!
So, anything added to the XMLList after
On 5/7/16, 11:36 AM, "Harbs" wrote:
>Right. I read that. This was what I was referring to in my last email.
>
>However, the Addition Operator is supposed to call [[Append]] and
>[[Append]] is supposed to assign the right side target object and target
>property to the left side object. So why do
Right. I read that. This was what I was referring to in my last email.
However, the Addition Operator is supposed to call [[Append]] and [[Append]] is
supposed to assign the right side target object and target property to the left
side object. So why doesn’t the original XML get effected?
On Ma
I think I found the answer. I was thinking that
list1 += list4, which is equivalent to
list1 = list1 + list4
would just use the [[Append]] operation. But that isn't true. Further
down in the spec (in 11.4) it actually addresses Addition operator. And
in there it says:
But, according to how I’m reading the spec, the following should work, but it
doesn’t:
list4 = new XMLList();
list4[0] = ;
list4[1] = ;
list4[2] = ;
list1 += list4 + xml2.z;
On May 6, 2016, at 11:29 AM, Harbs wrote:
> I got rid of just about everything and it still was not working.
>
> I fin
I got rid of just about everything and it still was not working.
I finally replaced list1 += list4 with xml2.a += list4 and that works.
So the following does not work:
list1 = xml2.a;
list1 += list4;
But the following does:
xml2.a += list4
I’m guessing that the reason the second case works is
Hmm.
Did you try commenting out lines of code in your first example until it
looks like this employees example? Maybe one of the lines cause a bug. I
wasn't sure what list1[0][0][0] would be, for example.
Or comment out the node. I just noticed that the append may have
picked up the name() fr
No. That’s not it.
For example, this:
var e =
Joe20
Sue30
;
// append employees 3 and 4 to the end of the employee list
var newE:XMLList = new XMLList();
newE[0] = Fred;
newE[1] = Carol;
e.employee += newE;
trace(e);
outputs:
Joe
20
Sue
30
Fred
On 5/5/16, 11:38 PM, "Harbs" wrote:
>FWIW, I also tried
>list1 += < id=“1”/>;
>instead of
>list1 += list4
>but that did not work either.
>
>I re-read the spec and it does look like you are reading it right, but it
>does not make sense to me and I don’t know how that jives with the
>behavior in
FWIW, I also tried
list1 += < id=“1”/>;
instead of
list1 += list4
but that did not work either.
I re-read the spec and it does look like you are reading it right, but it does
not make sense to me and I don’t know how that jives with the behavior in other
cases. For example (from the spec):
> Si
Baffling, isn't it? Reading the spec is equally baffling, but I think I
see for XMLList Append, that the targetObject of the appended XMLList
becomes the targetObject of the destination XMLList! That seems really
surprising to me and why they would do that doesn't jump to mind, but I
think that's
I’ve tried quite a number of angles on this, and I am just as clueless as when
I started.
Nothing I do seems to get the a elements added in Flash.
I’m really stumped on this. I’m going to leave the JS output as it is until
someone can explain to me why it’s wrong…
On May 5, 2016, at 10:49 AM,
Hi Lizhi,
This looks like good use cases.
Do you think you can extract some simple sample code for testing?
On Apr 13, 2016, at 10:16 AM, lizhi wrote:
> https://github.com/matrix3d/FlashShader/blob/master/example/src/gl3d/parser/dae/ColladaDecoder.as
>
> https://github.com/matrix3d/FlashShade
https://github.com/matrix3d/FlashShader/blob/master/example/src/gl3d/parser/dae/ColladaDecoder.as
https://github.com/matrix3d/FlashShader/blob/master/example/src/assets/astroBoy_walk_Max.dae
--
View this message in context:
http://apache-flex-development.247.n4.nabble.com/FlexJS-XML-first-
FYI, this now works:
rects.(@id==3).@height = "100px”;
Thanks Alex for fixing this!
On Apr 13, 2016, at 12:24 AM, Harbs wrote:
> Today, the following is working too:
>
> var svg:XML =
>
>
>
>
>
>
>
>
> ;
>
> var rects:XMLList = svg..rect;
> rects[1].@width = "100px";
> //rect
Today, the following is working too:
var svg:XML =
;
var rects:XMLList = svg..rect;
rects[1].@width = "100px";
//rects.(@id==3).@height = "100px";
trace(rects.toXMLString());
outputs:
> />;
>>
>> var rects:XMLList = svg..rect;
>> trace(rects.toXMLString());
>>
>> and g
Awesome!
I'll post if I can remember any of my other common scenarios.
Thanks,
Om
On Mon, Apr 11, 2016 at 2:54 PM, Harbs wrote:
> Absolutely!
>
> I just ran this:
> var svg:XML = />;
>
> var rects:XMLList = svg..rect;
> trace(rects.toXMLString());
>
> and got this in the console:
>
> >
>
Absolutely!
I just ran this:
var svg:XML = ;
var rects:XMLList = svg..rect;
trace(rects.toXMLString());
and got this in the console:
>
>
>
>
>
>
>
>
> var rects:XMLList = svg..rect;
>
> //rects should contain all the rects in the svg, i.e.
>
>
>
>
>
> Thanks,
> Om
>
>
Yay! That's fantastic news.
Just curious. Will this case work?
var svg:XML =
var rects:XMLList = svg..rect;
//rects should contain all the rects in the svg, i.e.
Thanks,
Om
On Mon, Apr 11, 2016 at 2:21 PM, Harbs wrote:
> I made some great progress to
I made some great progress today.
I just compared the output of some pretty whacky xml processing in Flash to the
output using the JS XML classes and the output was pretty close!
There are definitely some issues I still need to work on (besides some compiler
issues in JIRA), but I’m really happ
It did not work as well as I originally thought, but it’s working now.
Modifying XMLList should now effect the original XML as well.
There’s one caveat:
It seems like according to the spec, the original object of an XMLList can be
another XMLList which recursively works its way back to an XML o
I just added a test for indexed insertion of items in an XMLList and it works
perfectly. I’m surprised it worked on the first shot!
I need to get the syncing of the original XML object working though.
On Apr 10, 2016, at 4:02 PM, Harbs wrote:
> I reached a milestone today with E4X. I have the
Thanks Alex for putting in overtime on the compiler for this!
On Apr 10, 2016, at 5:14 PM, Alex Harui wrote:
> Awesome!
>
> On 4/10/16, 6:02 AM, "Harbs" wrote:
>
>> I reached a milestone today with E4X. I have the first working test which
>> reads an XML literal, writes it back out to a strin
Awesome!
On 4/10/16, 6:02 AM, "Harbs" wrote:
>I reached a milestone today with E4X. I have the first working test which
>reads an XML literal, writes it back out to a string and writes the value
>of an attribute using E4X notation in Javascript!
>
>Over the next couple of weeks I expect to be fi
94 matches
Mail list logo
