Hi Carlos,
Are you saying you can see that the response from the server was received by
XHR in the browser?
I can't think of anything that I pushed yesterday that would affect response
handling. IMO, the changes I made affected the call to send(), but not the
response handling. The other change would affect what MXML elements were
created. I guess you'll just have to debug into it.
If it helps, there is a -skip-transpile option that is relatively untested, but
causes the compiler to skip over any transpilation and just run the Google
Closure Compiler on the js-debug folder. This should allow you to add trace
statements (actually console.out) to the .JS files in the js-debug folder and
help you debug. If you are only modifying framework files and not the
application files, you don't even need -skip-transpile, since the framework JS
files from the SWC that are in js-debug are not overwritten if they already
exist.
You could also revert back until you get a version that works, or compare the
current js-debug against working js-debug, if you still have a working copy
somewhere.
-Alex
On 10/16/18, 3:57 AM, "Carlos Rovira" <carlosrov...@apache.org> wrote:
Hi Alex
It seems that latest changes makes MX RO not work in js-release mode.
If you remember I could by-pass this problem setting up
-js-dynamic-access-unknown-members=true
compiling my Application, but now testing js-release it's not working at
all, since we are in release no traces are shown
calling the operation in the backend just fails silenty.
I only can say that call is done since I can see traces on my java server,
and enabling XHR in browser I can see the request is received but in Royale
nothing happens. I think this in an important issue (in the end it will be
blocking for me to go to production), do you know of something done in the
latest changes that could make this fail now?
Thanks
El lun., 15 oct. 2018 a las 21:17, Carlos Rovira (<carlosrov...@apache.org>)
escribió:
> 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%7C98cbaf3e10514e91621f08d63356393e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636752842752174626&sdata=YC5itSpv5MgLQSKdHEbJjvyzI2dvAhBu0xEVa2BXMq8%3D&reserved=0
>> > > >>> > >
>> > > >>> > >
>> > > >>> > >
>> > > >>> > >
>> > > >>> >
>> > > >>> >
>> > > >>> >
>> > > >>>
>> > > >>> --
>> > > >>> Carlos Rovira
>> > > >>>
>> > > >>>
>> > >
>> >
>>
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C98cbaf3e10514e91621f08d63356393e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636752842752174626&sdata=YC5itSpv5MgLQSKdHEbJjvyzI2dvAhBu0xEVa2BXMq8%3D&reserved=0
>> > > >>>
>> > > >>>
>> > > >>>
>> > > >>
>> > > >> --
>> > > >> Carlos Rovira
>> > > >>
>> > >
>> >
>>
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C98cbaf3e10514e91621f08d63356393e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636752842752174626&sdata=YC5itSpv5MgLQSKdHEbJjvyzI2dvAhBu0xEVa2BXMq8%3D&reserved=0
>> > > >>
>> > > >>
>> > > >
>> > > > --
>> > > > Carlos Rovira
>> > > >
>> > >
>> >
>>
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C98cbaf3e10514e91621f08d63356393e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636752842752174626&sdata=YC5itSpv5MgLQSKdHEbJjvyzI2dvAhBu0xEVa2BXMq8%3D&reserved=0
>> > > >
>> > > >
>> > >
>> > > --
>> > > Carlos Rovira
>> > >
>> > >
>> >
>>
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C98cbaf3e10514e91621f08d63356393e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636752842752184635&sdata=rPZugyhtpLAxFUTL28MGL6xowshROe3UiNP345Rw5f0%3D&reserved=0
>> > >
>> > >
>> > >
>> >
>> > --
>> > Carlos Rovira
>> >
>> >
>>
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C98cbaf3e10514e91621f08d63356393e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636752842752184635&sdata=rPZugyhtpLAxFUTL28MGL6xowshROe3UiNP345Rw5f0%3D&reserved=0
>> >
>> >
>> >
>>
>> --
>> Carlos Rovira
>>
>>
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C98cbaf3e10514e91621f08d63356393e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636752842752184635&sdata=rPZugyhtpLAxFUTL28MGL6xowshROe3UiNP345Rw5f0%3D&reserved=0
>>
>>
>>
>
> --
> Carlos Rovira
>
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C98cbaf3e10514e91621f08d63356393e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636752842752184635&sdata=rPZugyhtpLAxFUTL28MGL6xowshROe3UiNP345Rw5f0%3D&reserved=0
>
>
--
Carlos Rovira
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C98cbaf3e10514e91621f08d63356393e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636752842752184635&sdata=rPZugyhtpLAxFUTL28MGL6xowshROe3UiNP345Rw5f0%3D&reserved=0
