greg-dove commented on pull request #969:
URL: https://github.com/apache/royale-asjs/pull/969#issuecomment-748543038


   Thanks for your patience. I took a quick look just now.
   There are 3 unit tests that no longer pass in JS after the changes. Probably 
you did not figure out how to run those yet. 
   For me to run those, I just need to ensure that PLAYERGLOBAL_HOME is defined 
(as a parent folder with versions subfolders containing playerglobal.swc ... 
e.g. %PLAYERGLOBAL_HOME$/11.1/playerglobal.swc ). Then cd to 
frameworks/projects/XML and run ant in that folder with all other normal royale 
env vars set. It should build both swf and js swcs for XML, and then run both 
swf and js tests (the same tests run in js and swf, but obviously this is 
mainly to use the swf version as a reference for language level stuff). Without 
PLAYERGLOBAL_HOME set I don't think any tests are run, but I have not checked 
to see why.
   I have added a new start of tests for XML notification - this is now in 
develop, but not compiled in (because it obviously will fail in current 
develop). These tests are just for the language level implementation in XML 
notification, not the mx/emulation stuff. I did not add anything for bubbling 
tests yet, and I was only exploring this to figure out ways to do it in the 
past. And the tests are only a start I expect. I did push where I had gotten to 
as WIP to a branch 
(https://github.com/apache/royale-asjs/tree/XML_Notification_prototype_swap) 
which you should feel free to harvest if you feel you can use anything from it. 
The general principle I was aiming for there wass to make the runtime 
implementation of XML notification available for dead-code elimination if it 
was never used, in case you are wondering about the 'strangeness' of it.
   
   At the moment I don't see the same initial notification tests passing which 
do pass on the Flash player, so I am not sure to do about that. Maybe the goal 
of your PR is more focused on the emulation support and not at the language 
(XML) level, which is probably sufficient, because I suspect it is how most 
people would use this feature.
   I think that if the stringification tests that currently have errors in your 
branch could be fixed then I I think it is probably good for merge, so long as 
others are fine with that. Thanks again for your efforts on this. I know how 
time-consuming testing this stuff can be....
   
   
   


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
[email protected]


Reply via email to