royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlos Rovira <carlosrov...@apache.org>
Subject Re: Proxy method calls with RemoteObject
Date Wed, 10 Oct 2018 23:38:21 GMT
I must close for today, tomorrow will try to change net RO for mx RO if you
finally get this build error fixed.

Thanks

Carlos


El mié., 10 oct. 2018 a las 23:34, Carlos Rovira (<carlosrovira@apache.org>)
escribió:

> That's great Alex! :)
>
> I want to try it but I found the following error building with maven:
>
>
> [*INFO*] *----------------< *org.apache.royale.framework:MXRoyale*
> >----------------*
>
> [*INFO*] *Building Apache Royale: Framework: Libs: MXRoyale
> 0.9.4-SNAPSHOT [32/118]*
>
> [*INFO*] *--------------------------------[ swc
> ]---------------------------------*
>
> [*INFO*]
>
> [*INFO*] *--- *maven-clean-plugin:3.0.0:clean *(default-clean)* @ MXRoyale*
> ---*
>
> [*INFO*]
>
> [*INFO*] *--- *royale-maven-plugin:0.9.4-SNAPSHOT:generate-extern
> *(default-generate-extern)* @ MXRoyale* ---*
>
> [*INFO*]
>
> [*INFO*] *--- *maven-remote-resources-plugin:1.5:process
> *(process-resource-bundles)* @ MXRoyale* ---*
>
> [*INFO*]
>
> [*INFO*] *--- *maven-resources-plugin:2.7:resources *(default-resources)*
> @ MXRoyale* ---*
>
> [*INFO*] Using 'UTF-8' encoding to copy filtered resources.
>
> [*INFO*] Copying 3 resources
>
> [*INFO*] Copying 3 resources
>
> [*INFO*]
>
> [*INFO*] *--- *royale-maven-plugin:0.9.4-SNAPSHOT:compile-as
> *(default-compile-as)* @ MXRoyale* ---*
>
> [*INFO*] Executing COMPC in tool group Royale with args:
> [-load-config=/Users/carlosrovira/Dev/Royale/Source/royale-asjs/frameworks/projects/MXRoyale/target/compile-swf-config.xml,
> -js-compiler-define=COMPILE::JS,true,
> -js-compiler-define=COMPILE::SWF,false,
> -js-compiler-define=GOOG::DEBUG,goog.DEBUG,
> -js-compiler-define=ROYALE::DISPLAYOBJECT,IUIComponent,
> -compiler.targets=SWF,JSRoyale, -compiler.strict-xml=true]
>
> args:
>
>
> -load-config=/Users/carlosrovira/Dev/Royale/Source/royale-asjs/frameworks/projects/MXRoyale/target/compile-swf-config.xml
>
> -js-compiler-define=COMPILE::JS,true
>
> -js-compiler-define=COMPILE::SWF,false
>
> -js-compiler-define=GOOG::DEBUG,goog.DEBUG
>
> -js-compiler-define=ROYALE::DISPLAYOBJECT,IUIComponent
>
> -compiler.targets=SWF,JSRoyale
>
> -compiler.strict-xml=true
>
> target:SWF
>
> target:JSRoyale
>
> COMPC
>
> Loading configuration:
> /Users/carlosrovira/Dev/Royale/Source/royale-asjs/frameworks/projects/MXRoyale/target/compile-swf-config.xml
>
>
> Error: Unexpected exception 'java.lang.NullPointerException'.
>
>
>
> Unexpected exception 'java.lang.NullPointerException'.
>
>
> ...
>
> [*INFO*] Apache Royale: Framework: Libs: RoyaleSite ......... *SUCCESS*
> [  0.771 s]
>
> [*INFO*] Apache Royale: Framework: Libs: MXRoyale ........... *FAILURE*
> [  1.529 s]
>
> [*INFO*] Apache Royale: Framework: Libs: Icons .............. *SKIPPED*
>
> [*INFO*] Apache Royale: Framework: Libs: SparkRoyale ........ *SKIPPED*
>
> I'm trying to build with the 2 commits of the latest failed release
> reverted to build 0.9.4. (I think we should revert those since, I suppose
> are not valid now).
>
> Thanks
>
>
>
> El mié., 10 oct. 2018 a las 21:41, Alex Harui (<aharui@adobe.com.invalid>)
> escribió:
>
>> We especially want the RemoteObject in Network.swc to be PAYG.  MX
>> RemoteObject was never PAYG.
>>
>> Having looked at the code more, I see what you are saying about Operation
>> not having its own fault and result handlers.  It looks like there already
>> is a SimpleOperation, so Operation could introduce its own fault and result
>> handlers.
>>
>> FWIW, I just pushed the changes to the compiler and emulation code that
>> got MX RemoteObject to work.  So that could be an option for you.  I'm sure
>> there might be bugs remaining to be fixed, but there is quite a bit of old
>> Flex code that is now running pretty much unchanged.
>>
>> -Alex
>>
>> On 10/10/18, 2:33 AM, "Carlos Rovira" <carlosrovira@apache.org> wrote:
>>
>>     Hi Alex
>>
>>     El mar., 9 oct. 2018 a las 18:14, Alex Harui
>> (<aharui@adobe.com.invalid>)
>>     escribió:
>>
>>     > As long as Responders are PAYG and not baked into the basic RO
>>     > implementation, it is fine for others to try to replicate subsets
>> of MX
>>     > RemoteObject, but it still seems like duplication of effort.
>>     >
>>
>>     well, I'm talking not about MX RO, bur the current one we have in
>>     Network.swc that is working.
>>
>>     That means is not a duplicate effort, take into account that I'm
>> right now
>>     coding a real world Apache Royale application, and need to get the
>> work
>>     done. I expect this could be a win for this project since is an
>> important
>>     project and an important client that are betting for Apache Royale :).
>>
>>
>>     >
>>     > That said, I have not used RO or Responders in any real world
>> application
>>     > myself.  I'm not sure I understand the need for them vs just adding
>> more
>>     > listeners to the result and fault event.
>>     >
>>
>>     Each RO use to have several Operations (aka methods that we want to
>> call in
>>     the backend). In real world scenarios, we want each RO callback logic
>> will
>>     be unique. If I call a service for a user list, I want to fill the
>> list in
>>     royale, but if I want to ask for a concrete user data, I want to fill
>> a
>>     form with that data.
>>
>>     Now, all Operations will be throw a result event and therefor all
>> listeners
>>     will fire, executing all methods. With listeners, we can use
>> if-then-else
>>     to and some logic to execute parts of the listener, but a Responder
>>     implementation, should make the appropriate responder be executed.
>>
>>     In order to structure and organizar a real world application that is
>> a bit
>>     complex this is needed to separate all this logic across files.
>>     (In a tiny application, you can use the if-then-else approach since
>> is more
>>     like a example).
>>
>>
>>
>>     >
>>     > My 2 cents,
>>     > -Alex
>>     >
>>     > On 10/9/18, 3:46 AM, "Carlos Rovira" <carlosrovira@apache.org>
>> wrote:
>>     >
>>     >     Hi Piotr,
>>     >
>>     >     I think if I get some improvement over the current RO with
>> Responders
>>     > that
>>     >     could go to develop. Other thing is I tried to make it work in
>> mx RO.
>>     >     People using Royale RO will benefit from it. If some day mx RO
>> is
>>     > ready, I
>>     >     think we'll shift to mx RO, although royale RO could be
>> continue to be
>>     >     valid (since is a small implementation that works), or we could
>> decide
>>     >     deprecate it. Anyway, I'm not talking to make improvements over
>>     > something
>>     >     that others will evolve separately, I want to improve something
>> that
>>     >     otherwise will remain as is.
>>     >
>>     >
>>     >
>>     >     El mar., 9 oct. 2018 a las 12:39, Piotr Zarzycki (<
>>     > piotrzarzycki21@gmail.com>)
>>     >     escribió:
>>     >
>>     >     > Carlos,
>>     >     >
>>     >     > You can always use branch, make your changes and wait for the
>> proper
>>     > one
>>     >     > using branch. Some time ago Harbs did it the same as far as I
>>     > remember.
>>     >     > There is no need to wait if you need something ASAP.
>>     >     >
>>     >     > Thanks,
>>     >     > Piotr
>>     >     >
>>     >     > wt., 9 paź 2018 o 12:36 Carlos Rovira <
>> carlosrovira@apache.org>
>>     >     > napisał(a):
>>     >     >
>>     >     > > Hi Alex,
>>     >     > >
>>     >     > > since there's no planned ETA for anyone here (that I know),
>> I
>>     > could try
>>     >     > at
>>     >     > > some point to have a minimal Responder functionality in the
>> current
>>     >     > working
>>     >     > > RO. Does not have sense to duplicate all the code but I
>> think has
>>     > sense
>>     >     > to
>>     >     > > see if some little changes can provide the minimal needs.
>>     >     > >
>>     >     > > thanks
>>     >     > >
>>     >     > >
>>     >     > >
>>     >     > > El mar., 9 oct. 2018 a las 0:25, Alex Harui
>>     > (<aharui@adobe.com.invalid>)
>>     >     > > escribió:
>>     >     > >
>>     >     > > > I think you'll have to wait until someone gets all of
the
>> old
>>     > Flex RO
>>     >     > > code
>>     >     > > > to compile and run.  I'm currently still debugging the
>> compiler,
>>     > so no
>>     >     > > way
>>     >     > > > it will be ready tomorrow.
>>     >     > > >
>>     >     > > > It doesn't make sense to try to duplicate all of this
>> code and
>>     > get it
>>     >     > to
>>     >     > > > work some other way.
>>     >     > > >
>>     >     > > > -Alex
>>     >     > > >
>>     >     > > > On 10/8/18, 3:21 PM, "Carlos Rovira" <
>> carlosrovira@apache.org>
>>     > wrote:
>>     >     > > >
>>     >     > > >     Hi Alex,
>>     >     > > >
>>     >     > > >     I'm closing for today, but tomorrow I'll need to
>> handle more
>>     > than
>>     >     > one
>>     >     > > >     Responder for RemoteObject calls, so each
>> operation/method
>>     > can have
>>     >     > > > it's
>>     >     > > >     own responder and create methods for each one in
my
>>     > controllers.
>>     >     > with
>>     >     > > > the
>>     >     > > >     current RemoteObject implementation could you share
>> what
>>     > could be
>>     >     > the
>>     >     > > > most
>>     >     > > >     quick and easy way to get this while the full RO
>>     > implementation is
>>     >     > on
>>     >     > > > the
>>     >     > > >     works? Now that I'm starting to grow the app code
>> base I can
>>     > rely
>>     >     > on
>>     >     > > a
>>     >     > > >     result handler full of if-then-else
>>     >     > > >
>>     >     > > >     Thanks for any help on this
>>     >     > > >
>>     >     > > >     Carlos
>>     >     > > >
>>     >     > > >
>>     >     > > >
>>     >     > > >
>>     >     > > >     El lun., 8 oct. 2018 a las 18:52, Carlos Rovira (<
>>     >     > > > carlosrovira@apache.org>)
>>     >     > > >     escribió:
>>     >     > > >
>>     >     > > >     > Ok Alex, thanks, didn't know that you have this
>> task to
>>     > make it
>>     >     > > work
>>     >     > > > RO. I
>>     >     > > >     > though you only try to compile it.
>>     >     > > >     > That's good to know. I'm trying right now to
make a
>> real
>>     > world
>>     >     > app
>>     >     > > > and
>>     >     > > >     > since I don't have a micro structural IOC framework
>> like
>>     > Swiz,
>>     >     > that
>>     >     > > > was
>>     >     > > >     > that I use in Flex, I'm trying to structure
and
>> organize
>>     > screens,
>>     >     > > >     > controllers, delegates, and so on, and I'm trying
>> to put
>>     > things
>>     >     > as
>>     >     > > > easy as
>>     >     > > >     > possible so I can refactor more later to something
>> more
>>     > suited
>>     >     > for
>>     >     > > > this
>>     >     > > >     > task, since I don't have time now to build a
>> framework for
>>     > this
>>     >     > due
>>     >     > > > to
>>     >     > > >     > reduced time lines.
>>     >     > > >     >
>>     >     > > >     > If you get this RO proxy way to call backend
>> methods and
>>     >     > > AsyncToken,
>>     >     > > >     > that's what I need to connect with MX RemoteObject
>> in the
>>     > same
>>     >     > way
>>     >     > > > we use
>>     >     > > >     > to do.
>>     >     > > >     >
>>     >     > > >     > I'll be waiting for your. progress there
>>     >     > > >     >
>>     >     > > >     > thanks
>>     >     > > >     >
>>     >     > > >     > Carlos
>>     >     > > >     >
>>     >     > > >     >
>>     >     > > >     >
>>     >     > > >     >
>>     >     > > >     >
>>     >     > > >     >
>>     >     > > >     > El lun., 8 oct. 2018 a las 17:28, Alex Harui
>>     >     > > > (<aharui@adobe.com.invalid>)
>>     >     > > >     > escribió:
>>     >     > > >     >
>>     >     > > >     >> I believe I already said I am working on
>> RemoteObject.
>>     >     > > >     >>
>>     >     > > >     >> The Flex compiler generates custom code
for
>>     > mx:RemoteObject.
>>     >     > The
>>     >     > > > Royale
>>     >     > > >     >> Compiler currently does not.  I am working
on it.
>>     >     > > >     >>
>>     >     > > >     >> Thanks,
>>     >     > > >     >> -Alex
>>     >     > > >     >>
>>     >     > > >     >> On 10/8/18, 3:13 AM, "Carlos Rovira" <
>>     > carlosrovira@apache.org>
>>     >     > > > wrote:
>>     >     > > >     >>
>>     >     > > >     >>     Hi,
>>     >     > > >     >>
>>     >     > > >     >>     I was experimenting trying to get RemoteObject
>> to
>>     > proxy
>>     >     > method
>>     >     > > > calls.
>>     >     > > >     >>
>>     >     > > >     >>     so instead of doing
>>     >     > > >     >>
>>     >     > > >     >>     service.send("echo", [name_txt.text]);
>>     >     > > >     >>
>>     >     > > >     >>     be able to do:
>>     >     > > >     >>
>>     >     > > >     >>     service.echo(name_txt.text);
>>     >     > > >     >>
>>     >     > > >     >>     I tried with Proxy class
>>     >     > > >     >>
>>     >     > > >     >>     (org.apache.royale.utils.Proxy)
>>     >     > > >     >>
>>     >     > > >     >>     and implementing IEventDispatcher, but
>> compiler throws
>>     >     > error:
>>     >     > > >     >>
>>     >     > > >     >>     Call to a possibly undefined method
echo
>> through a
>>     > reference
>>     >     > > > with
>>     >     > > >     >> static
>>     >     > > >     >>     type RemoteObject.
>>     >     > > >     >>
>>     >     > > >     >>     It's possible to do something like this?
what
>> I'm
>>     > missing?
>>     >     > > >     >>
>>     >     > > >     >>     This seems a little enhancement, but
it would
>> be cool
>>     > if we
>>     >     > > get
>>     >     > > > it in
>>     >     > > >     >> order
>>     >     > > >     >>     to be more near of the normal syntax
we all
>> have in
>>     > our code
>>     >     > > > bases.
>>     >     > > >     >>
>>     >     > > >     >>     thanks
>>     >     > > >     >>
>>     >     > > >     >>     --
>>     >     > > >     >>     Carlos Rovira
>>     >     > > >     >>
>>     >     > > >     >>
>>     >     > > >
>>     >     > >
>>     >     >
>>     >
>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&amp;data=02%7C01%7Caharui%40adobe.com%7Cba2019660bf9437e4b2408d62e936fc2%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636747608145213634&amp;sdata=gOm6NVhNiVLLMcxt%2BpN%2BPBbAVEqZLAVp9yIhL3HnvKw%3D&amp;reserved=0
>>     >     > > >     >>
>>     >     > > >     >>
>>     >     > > >     >>
>>     >     > > >     >
>>     >     > > >     > --
>>     >     > > >     > Carlos Rovira
>>     >     > > >     >
>>     >     > > >
>>     >     > >
>>     >     >
>>     >
>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&amp;data=02%7C01%7Caharui%40adobe.com%7Cba2019660bf9437e4b2408d62e936fc2%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636747608145213634&amp;sdata=gOm6NVhNiVLLMcxt%2BpN%2BPBbAVEqZLAVp9yIhL3HnvKw%3D&amp;reserved=0
>>     >     > > >     >
>>     >     > > >     >
>>     >     > > >
>>     >     > > >     --
>>     >     > > >     Carlos Rovira
>>     >     > > >
>>     >     > > >
>>     >     > >
>>     >     >
>>     >
>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&amp;data=02%7C01%7Caharui%40adobe.com%7Cba2019660bf9437e4b2408d62e936fc2%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636747608145223648&amp;sdata=Bmfn%2BXy%2BVe7Fyw3EX3YkUZ1avT6v3H9WnCer5lff6rA%3D&amp;reserved=0
>>     >     > > >
>>     >     > > >
>>     >     > > >
>>     >     > >
>>     >     > > --
>>     >     > > Carlos Rovira
>>     >     > >
>>     >
>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&amp;data=02%7C01%7Caharui%40adobe.com%7Cba2019660bf9437e4b2408d62e936fc2%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636747608145223648&amp;sdata=Bmfn%2BXy%2BVe7Fyw3EX3YkUZ1avT6v3H9WnCer5lff6rA%3D&amp;reserved=0
>>     >     > >
>>     >     >
>>     >     >
>>     >     > --
>>     >     >
>>     >     > Piotr Zarzycki
>>     >     >
>>     >     > Patreon: *
>>     >
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&amp;data=02%7C01%7Caharui%40adobe.com%7Cba2019660bf9437e4b2408d62e936fc2%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636747608145223648&amp;sdata=bbHxu%2BpLk6%2FYYuBfODryx%2FN8wmX13xx2VzEwyRoK4Pc%3D&amp;reserved=0
>>     >     > <
>>     >
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&amp;data=02%7C01%7Caharui%40adobe.com%7Cba2019660bf9437e4b2408d62e936fc2%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636747608145223648&amp;sdata=bbHxu%2BpLk6%2FYYuBfODryx%2FN8wmX13xx2VzEwyRoK4Pc%3D&amp;reserved=0
>>     > >*
>>     >     >
>>     >
>>     >
>>     >     --
>>     >     Carlos Rovira
>>     >
>>     >
>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&amp;data=02%7C01%7Caharui%40adobe.com%7Cba2019660bf9437e4b2408d62e936fc2%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636747608145223648&amp;sdata=Bmfn%2BXy%2BVe7Fyw3EX3YkUZ1avT6v3H9WnCer5lff6rA%3D&amp;reserved=0
>>     >
>>     >
>>     >
>>
>>     --
>>     Carlos Rovira
>>
>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&amp;data=02%7C01%7Caharui%40adobe.com%7Cba2019660bf9437e4b2408d62e936fc2%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636747608145223648&amp;sdata=Bmfn%2BXy%2BVe7Fyw3EX3YkUZ1avT6v3H9WnCer5lff6rA%3D&amp;reserved=0
>>
>>
>>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
>

-- 
Carlos Rovira
http://about.me/carlosrovira

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message