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%7C4250674c8c1946097a9f08d632948a2d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636752010888007469&sdata=WneHWoddmCPQgvsjT2tX4CyCHx%2FdNl%2BsGopKC35DWZg%3D&reserved=0 > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > >>> > > >>> > > >>> > >>> -- > >>> Carlos Rovira > >>> > >>> > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C4250674c8c1946097a9f08d632948a2d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636752010888017469&sdata=8%2F%2F1k%2FGCTKSrcUJg0kCFLeI4M76J3IFl26SyDrqoPe8%3D&reserved=0 > >>> > >>> > >>> > >> > >> -- > >> Carlos Rovira > >> > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C4250674c8c1946097a9f08d632948a2d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636752010888017469&sdata=8%2F%2F1k%2FGCTKSrcUJg0kCFLeI4M76J3IFl26SyDrqoPe8%3D&reserved=0 > >> > >> > > > > -- > > Carlos Rovira > > > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C4250674c8c1946097a9f08d632948a2d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636752010888017469&sdata=8%2F%2F1k%2FGCTKSrcUJg0kCFLeI4M76J3IFl26SyDrqoPe8%3D&reserved=0 > > > > > > -- > Carlos Rovira > > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C4250674c8c1946097a9f08d632948a2d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636752010888017469&sdata=8%2F%2F1k%2FGCTKSrcUJg0kCFLeI4M76J3IFl26SyDrqoPe8%3D&reserved=0 > > > -- Carlos Rovira http://about.me/carlosrovira
