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.
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.
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.
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
