Hi Alex, with your latest fixes all is working ok :) thanks! El lun., 15 oct. 2018 a las 20:12, Alex Harui (<aha...@adobe.com.invalid>) escribió:
> Either syntax should work. I just pushed changes to AbstractService that > got service.echo() to work. > > -Alex > > On 10/15/18, 10:51 AM, "Carlos Rovira" <carlosrov...@apache.org> wrote: > > Hi Alex, > > one thing I not understand is that this: > > (service.echo as Operation).send(); > > should be > > service.echo() > > I think we're trying to remove "send()" and call directly "echo()" > > I can go to your latest commits in both compiler and framework and > try, but > don't understand the purpose, since calling with send() was what we > had, > right? > > Or maybe I'm missing something? > > thanks > > Carlos > > > > > > El lun., 15 oct. 2018 a las 19:15, Alex Harui > (<aha...@adobe.com.invalid>) > escribió: > > > About 10 hours ago, after I cast the call to send in the example to > be > > (service.echo as Operation).send() , it worked for me. > > > > I see you have made several changes to the example since. Go back to > > where the example was about 10 hours ago, make that one change to > > service.echo.send() and it should work. If other things are not > working, I > > will look into them later. > > > > -Alex > > > > On 10/15/18, 10:11 AM, "Carlos Rovira" <carlosrov...@apache.org> > wrote: > > > > Hi Alex, > > > > El lun., 15 oct. 2018 a las 18:54, Alex Harui > > (<aha...@adobe.com.invalid>) > > escribió: > > > > > There may be a couple of things affecting you. One is that in > the > > bug you > > > reported, it looks like only the first RO is created and the > others > > are not. > > > > > > > I 'm pretty sure the bug about mx:method is not present since I > test > > in my > > real project and in the example in our repo. In the first one I > don't > > have > > any mx:method and in the second I comment to test. Maybe we > should > > comment > > mx:method section in the example for now. > > > > > > > > > > Second, if you notice in the example, you'll see things like > > (service.echo > > > as Operation).lastResult. After adding support for > callProperty, > > the calls > > > now have to change to be either (service.echo as > Operation).send() or > > > service.echo(). The current syntax in the repo: > service.echo.send() > > will > > > result in an error because the compiler cannot know if the echo > > property on > > > service is also a proxy or not. The compiler currently guesses > > "yes" to > > > make it easier for folks who have existing nested ObjectProxy > data > > sets. > > > So, Royale developers will have to do more "casting" with "as" > than > > in > > > Flash. > > > > > > > check the example since I change already to the new syntax to > help you > > try > > it. There's no "send()" anymore in the example in our repo. > > > > > > > > > > In Flash, the difference between proxy access and regular > property > > access > > > is handled in the runtime. The JS runtimes do not do this. > The > > compiler > > > could generate code that tests the class at runtime, but I > think > > that will > > > be too slow. > > > > > > Specific to RemoteObject, it might be possible to declare the > JS > > > RemoteObject to not be a Proxy and just Dynamic and have the > > constructor > > > and getOperation call Object.defineProperty, but that is not a > > general case > > > solution for Proxy. > > > > > > > Hi Alex, that's for me a bit far from my knowledge. I'm sure > whatever > > you > > get would be the best solution. > > Currently mx:RO is broken and I'm working with the repo just > before the > > change localy to advance, hope you could take a look and see if > you > > can fix > > the issue. > > If not, probably is better to comment the changes in the > compiler (and > > maybe in the framework?) to make it work again until we know how > to > > fix it. > > > > One thing I could test today (not related) in the meanwhile is > if mx:RO > > works with small messages on. The response is not, I think that > is the > > AMF > > serialization-deserialization. But I think this is not crucial, > just > > disabling it could be ok for now for most of folks out there > (just > > knowing > > that they need to configure that to false). > > > > Thanks > > > > Carlos > > > > > > > > > > My 2 cents, > > > -Alex > > > > > > On 10/15/18, 4:51 AM, "Carlos Rovira" <carlosrov...@apache.org > > > > wrote: > > > > > > Hi Alex, > > > > > > I added to the RO test example the CompressedRO test case > > commented to > > > help > > > you find the problem. > > > I couldn't test like in net RO since now the entire > example is > > > failing, but > > > once the callProperty works for a normal case should help > us to > > check > > > if > > > the rest of RO works since it uses > "convertParametersHandler" > > > > > > I'll revert localy this changes in order to advance in my > real > > world > > > app in > > > the mean while > > > > > > thanks > > > > > > > > > > > > El lun., 15 oct. 2018 a las 13:40, Carlos Rovira (< > > > carlosrov...@apache.org>) > > > escribió: > > > > > > > Hi Alex, > > > > > > > > I found that even if I remove completely > > CompressedRemoteObject and > > > use > > > > only normal mx:RemoteObject the error shows: > > > > > > > > [Error] TypeError: undefined is not an object (evaluating > > > > 'this.remoteObject.convertParametersHandler') > > > > > > > > > > > > > > > > > > > > El lun., 15 oct. 2018 a las 13:00, Carlos Rovira (< > > > carlosrov...@apache.org>) > > > > escribió: > > > > > > > >> Hi Alex, > > > >> > > > >> I'm finding a problem with callProperty. I'm using a > > > >> CompressedRemoteObjeect that uses two hooks in > RemoteObject > > API > > > >> > > > >> public var convertParametersHandler:Function; > > > >> > > > >> and > > > >> public var convertResultHandler:Function; > > > >> > > > >> this makes the call fail with > > > >> > > > >> [Error] TypeError: undefined is not an object > (evaluating > > > >> 'this.remoteObject.convertParametersHandler') > > > >> send (Operation.js:109) > > > >> callProperty (AbstractService.js:147:111) > > > >> dologin (LoginForm.js:181) > > > >> $EH1 (LoginForm.js:226) > > > >> (función anónima) > > > >> fireListener (events.js:744) > > > >> fireListenerOverride (HTMLElementWrapper.js:61) > > > >> handleBrowserEvent_ (events.js:870) > > > >> (función anónima) (events.js:289) > > > >> > > > >> So I guess the proxy is trying to proxy all even its own > > member > > > functions > > > >> that should not be affected, makes this sense? > > > >> > > > >> thanks > > > >> > > > >> > > > >> El lun., 15 oct. 2018 a las 7:15, Alex Harui > > > (<aha...@adobe.com.invalid>) > > > >> escribió: > > > >> > > > >>> I pushed changes to the compiler and framework to try > to get > > > >>> callProperty to work. I don't have a test case but > give it > > a try > > > and see > > > >>> what happens. > > > >>> > > > >>> If you compare the size of the output with and without > > > >>> -js-dynamic-access, you can see the theoretical > savings of > > not > > > using that > > > >>> option. If that savings might matter, then it might > be worth > > > spending some > > > >>> time on fixing up the issues that -js-dynamic-access > "works > > > around". But > > > >>> keep in mind that there probably isn't any way to grab > all > > of the > > > >>> theoretical savings. What we don’t know yet is where > you'll > > > actually end > > > >>> up. It might even be true that -js-dynamic-access is > more > > optimal. > > > >>> > > > >>> -Alex > > > >>> > > > >>> On 10/14/18, 3:02 PM, "Carlos Rovira" < > > carlosrov...@apache.org> > > > wrote: > > > >>> > > > >>> Hi Alex > > > >>> > > > >>> El dom., 14 oct. 2018 a las 23:48, Alex Harui > > > >>> (<aha...@adobe.com.invalid>) > > > >>> escribió: > > > >>> > > > >>> > I got the resources working so I will look into > > > Proxy.callProperty. > > > >>> > > > > >>> > > > > >>> That's cool, I'm closing for today, I can try in > some > > hours if > > > you > > > >>> upload > > > >>> some changes. Thanks > > > >>> > > > >>> > > > >>> > The issue with js-dynamic-access isn't about MX > > RemoteObject > > > vs > > > >>> Basic > > > >>> > RemoteObject, it is whether, if we fixed places > in any > > of > > > the code > > > >>> where > > > >>> > minification breaks things, what the > size/performance > > > trade-off > > > >>> would be. > > > >>> > Some variable names would be longer, but some > other > > code > > > might be > > > >>> more > > > >>> > verbose as public vars are converted into > > getter/setters and > > > have > > > >>> function > > > >>> > call overhead. I guess we'll find out when we > get > > someone's > > > app > > > >>> to the > > > >>> > point where they are ready to get the production > > version to > > > run. > > > >>> > > > > >>> > > > >>> Well, I'll need to have my app in production by the > > end/start > > > of the > > > >>> year, > > > >>> so we'll can check this with mine. For now it > seems I > > need to > > > left > > > >>> this > > > >>> configuration or release version can pass the > login (the > > mx RO > > > call > > > >>> to the > > > >>> server) > > > >>> > > > >>> > > > >>> > > > >>> > > > > >>> > -Alex > > > >>> > > > > >>> > On 10/14/18, 2:23 PM, "Carlos Rovira" < > > > carlosrov...@apache.org> > > > >>> wrote: > > > >>> > > > > >>> > Hi Alex, > > > >>> > > > > >>> > El dom., 14 oct. 2018 a las 18:32, Alex Harui > > > >>> > (<aha...@adobe.com.invalid>) > > > >>> > escribió: > > > >>> > > > > >>> > > Hi Carlos, > > > >>> > > > > > >>> > > JS proxy doesn't support callProperty > yet. Feel > > free > > > to add > > > >>> it, or > > > >>> > I will > > > >>> > > after I finish up ResourceManager. > > > >>> > > > > > >>> > > > > >>> > JS proxy is mx.utlis.ObjectProxy or you mean > maybe > > > >>> AbstractService > > > >>> > callProperty? > > > >>> > I could take a look, but no promises since I > don't > > know > > > >>> exactly how > > > >>> > that > > > >>> > works. A little of guidance here could me > make get > > this > > > done. > > > >>> > > > > >>> > > > > >>> > > > > > >>> > > I don't doubt that minification breaks > lots of > > things > > > that > > > >>> > > js-dynamic-access fixes. Hard to say how > much > > smaller > > > your > > > >>> app > > > >>> > would be if > > > >>> > > we fixed anough stuff without that option. > > > >>> > > > > > >>> > > > > > >>> > well, including mx:RemoteObject seems to > increase > > > >>> significantly my > > > >>> > current > > > >>> > app in release mode "mx" is 1'8mb while > > > "org.apache.royale" is > > > >>> > 1'8mb...but > > > >>> > is ok for me since I think is a normal > payload for > > the > > > base of > > > >>> a normal > > > >>> > App, and MX RO here does an important role > in my > > case. So > > > >>> happy to pay > > > >>> > the > > > >>> > price ;) > > > >>> > > > > >>> > > > > >>> > > > > >>> > > -Alex > > > >>> > > > > > >>> > > -- > > > >>> > > Carlos Rovira > > > >>> > > > > > >>> > > > > >>> > > > > > > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cfb1a4f2191594e64a0b408d632c6d78b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636752226933961718&sdata=eJ40VRUzVjylpzaDR5TRG0ofllr%2F3dRvnydGEu36fPk%3D&reserved=0 > > > >>> > > > > > >>> > > > > > >>> > > > > > >>> > > > > > >>> > > > > >>> > > > > >>> > > > > >>> > > > >>> -- > > > >>> Carlos Rovira > > > >>> > > > >>> > > > > > > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cfb1a4f2191594e64a0b408d632c6d78b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636752226933961718&sdata=eJ40VRUzVjylpzaDR5TRG0ofllr%2F3dRvnydGEu36fPk%3D&reserved=0 > > > >>> > > > >>> > > > >>> > > > >> > > > >> -- > > > >> Carlos Rovira > > > >> > > > > > > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cfb1a4f2191594e64a0b408d632c6d78b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636752226933961718&sdata=eJ40VRUzVjylpzaDR5TRG0ofllr%2F3dRvnydGEu36fPk%3D&reserved=0 > > > >> > > > >> > > > > > > > > -- > > > > Carlos Rovira > > > > > > > > > > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cfb1a4f2191594e64a0b408d632c6d78b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636752226933961718&sdata=eJ40VRUzVjylpzaDR5TRG0ofllr%2F3dRvnydGEu36fPk%3D&reserved=0 > > > > > > > > > > > > > > -- > > > Carlos Rovira > > > > > > > > > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cfb1a4f2191594e64a0b408d632c6d78b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636752226933961718&sdata=eJ40VRUzVjylpzaDR5TRG0ofllr%2F3dRvnydGEu36fPk%3D&reserved=0 > > > > > > > > > > > > > -- > > Carlos Rovira > > > > > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cfb1a4f2191594e64a0b408d632c6d78b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636752226933961718&sdata=eJ40VRUzVjylpzaDR5TRG0ofllr%2F3dRvnydGEu36fPk%3D&reserved=0 > > > > > > > > -- > Carlos Rovira > > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cfb1a4f2191594e64a0b408d632c6d78b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636752226933961718&sdata=eJ40VRUzVjylpzaDR5TRG0ofllr%2F3dRvnydGEu36fPk%3D&reserved=0 > > > -- Carlos Rovira http://about.me/carlosrovira
