You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@royale.apache.org by hferreira <hf...@solidsoft.pt> on 2018/11/16 00:24:36 UTC
Suggestion: Emulation tutorial
Would be great if one of the experients Royale developers produce a basic
step by step tutorial how to implement a MXRoyale or SparkRoyale component
from scratch (a button for example).
So, let's imagine that there is no MXRoyale button iet and with this
tutorial, would be possible to create a button and test it (press it and do
an action).
If you believe that's worth it.
--
Sent from: http://apache-royale-users.20374.n8.nabble.com/
Re: Suggestion: Emulation tutorial
Posted by Serkan Taş <se...@likyateknoloji.com>.
Yes Piotr, it is true.
I am using some libs that are modified like fiber and as3corelib and
shared them on github.
Thanks,
Serkan
16.11.2018 08:56 tarihinde Piotr Zarzycki yazdı:
> Hugo,
>
> I'm not sure where I have seen this but I think Serkan who migrating
> his app has it on the GitHub.
>
> Serkan please correct me if I'm wrong. Maybe it can help, depends
> where he is with his migration...
>
> Piotr
>
> On Fri, Nov 16, 2018, 5:10 AM Alex Harui <aharui@adobe.com
> <ma...@adobe.com>> wrote:
>
> Yeah, it is a lot to learn. Did you ever make patches to the Flex
> SDK framework code?
>
> I will try to put together a step-by-step tutorial on the next
> component I get to run. I'm not sure there is only one path to
> take, but maybe. Until I get to that, you can try looking at the
> change history in MXRoyale around a component that you think is
> similar to one you need.
>
> HTH,
> -Alex
>
> On 11/15/18, 4:52 PM, "hferreira" <hferreira@solidsoft.pt
> <ma...@solidsoft.pt>> wrote:
>
> Yes. I read before posted.
> In a conceptual point of view is a good material.
> Explains the approach.
> Create the component without implementation, surrounding
> Royale API (the
> important is the emulation like an interface, the
> content/implementation can
> and should be different from Flex SDK, using directly Royale
> API as match as
> possible).
> And on the finish like, code the implementation.
> Also, I understand now, that correctly MXRoyale it's very
> uggly because the
> intention is first to compile a big project (recently done),
> then put the
> things work (components implementation) and only then maybe
> try to simulate
> more or less the Flex SDK UI.
>
> Perhaps, it's just me, but for someone inexperience with
> Royale API, breads,
> etc ..., became lost (or worst can follow to do a bad
> implementation)
> without a code sample guide.
>
> But if there are guys that are doing this successful, perhaps
> it's just me.
>
>
>
> --
> Sent from:
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-royale-users.20374.n8.nabble.com%2F&data=02%7C01%7Caharui%40adobe.com%7Cc046da5127e44ea591b308d64b5dd615%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636779263730583017&sdata=04xS6uZzR8rVOlCILO%2B9%2BRsnVkmoWThOX9ADUqXibwo%3D&reserved=0
>
>
Re: Suggestion: Emulation tutorial
Posted by hferreira <hf...@solidsoft.pt>.
"Yeah, it is a lot to learn. Did you ever make patches to the Flex SDK
framework code? "
A few ones yes, but the deepest I went was:
1. Debug;
2. Find bugs that affects my code;
3. Find logical patch;
4. Copy the original code from the SDK to my project;
5. Apply the patch;
6. Fill a bug on the JIRA with the suggestion of the patch;
7. If (probably not) my patch appear on a future SDK release, I used it and
delete my custom patch.
"I will try to put together a step-by-step tutorial on the next component I
get to run."
That would be great !
"I'm not sure where I have seen this but I think Serkan who migrating his
app has it on the GitHub."
Serkan, can you help ?
It's a big world and I believe that there at least 100 (if not 1000 or more)
developers using Flex SDK that would love to migrate to Royale.
The new components and a new foundation makes sense but it's the emulation
that counts for this set of developers.
Probably they have knowledge to build Flex application and already created
hundreds of widgets using Flex components and perhaps a few patch at most
but if you ask the build a component from scratch for SDK they would not be
able to do and did not know even here to start.
Probably they are all waiting to see what's happen here (if the Roayle with
emulation see the light one day).
I don't believe that this force (a lot of developers) would help but if 1%
of them help developing at least one component or component implementation,
would be a giant help and this "guide for dummies" it's necessary.
It happens all the time, and that's why Flex SDK was successful with samples
and .NET, etc ...
But I may be wrong because I don't have numbers ...
--
Sent from: http://apache-royale-users.20374.n8.nabble.com/
Re: Suggestion: Emulation tutorial
Posted by Piotr Zarzycki <pi...@gmail.com>.
Hugo,
I'm not sure where I have seen this but I think Serkan who migrating his
app has it on the GitHub.
Serkan please correct me if I'm wrong. Maybe it can help, depends where he
is with his migration...
Piotr
On Fri, Nov 16, 2018, 5:10 AM Alex Harui <ah...@adobe.com> wrote:
> Yeah, it is a lot to learn. Did you ever make patches to the Flex SDK
> framework code?
>
> I will try to put together a step-by-step tutorial on the next component I
> get to run. I'm not sure there is only one path to take, but maybe. Until
> I get to that, you can try looking at the change history in MXRoyale around
> a component that you think is similar to one you need.
>
> HTH,
> -Alex
>
> On 11/15/18, 4:52 PM, "hferreira" <hf...@solidsoft.pt> wrote:
>
> Yes. I read before posted.
> In a conceptual point of view is a good material.
> Explains the approach.
> Create the component without implementation, surrounding Royale API
> (the
> important is the emulation like an interface, the
> content/implementation can
> and should be different from Flex SDK, using directly Royale API as
> match as
> possible).
> And on the finish like, code the implementation.
> Also, I understand now, that correctly MXRoyale it's very uggly
> because the
> intention is first to compile a big project (recently done), then put
> the
> things work (components implementation) and only then maybe try to
> simulate
> more or less the Flex SDK UI.
>
> Perhaps, it's just me, but for someone inexperience with Royale API,
> breads,
> etc ..., became lost (or worst can follow to do a bad implementation)
> without a code sample guide.
>
> But if there are guys that are doing this successful, perhaps it's
> just me.
>
>
>
> --
> Sent from:
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-royale-users.20374.n8.nabble.com%2F&data=02%7C01%7Caharui%40adobe.com%7Cc046da5127e44ea591b308d64b5dd615%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636779263730583017&sdata=04xS6uZzR8rVOlCILO%2B9%2BRsnVkmoWThOX9ADUqXibwo%3D&reserved=0
>
>
>
Re: Suggestion: Emulation tutorial
Posted by Alex Harui <ah...@adobe.com>.
Yeah, it is a lot to learn. Did you ever make patches to the Flex SDK framework code?
I will try to put together a step-by-step tutorial on the next component I get to run. I'm not sure there is only one path to take, but maybe. Until I get to that, you can try looking at the change history in MXRoyale around a component that you think is similar to one you need.
HTH,
-Alex
On 11/15/18, 4:52 PM, "hferreira" <hf...@solidsoft.pt> wrote:
Yes. I read before posted.
In a conceptual point of view is a good material.
Explains the approach.
Create the component without implementation, surrounding Royale API (the
important is the emulation like an interface, the content/implementation can
and should be different from Flex SDK, using directly Royale API as match as
possible).
And on the finish like, code the implementation.
Also, I understand now, that correctly MXRoyale it's very uggly because the
intention is first to compile a big project (recently done), then put the
things work (components implementation) and only then maybe try to simulate
more or less the Flex SDK UI.
Perhaps, it's just me, but for someone inexperience with Royale API, breads,
etc ..., became lost (or worst can follow to do a bad implementation)
without a code sample guide.
But if there are guys that are doing this successful, perhaps it's just me.
--
Sent from: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-royale-users.20374.n8.nabble.com%2F&data=02%7C01%7Caharui%40adobe.com%7Cc046da5127e44ea591b308d64b5dd615%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636779263730583017&sdata=04xS6uZzR8rVOlCILO%2B9%2BRsnVkmoWThOX9ADUqXibwo%3D&reserved=0
Re: Suggestion: Emulation tutorial
Posted by hferreira <hf...@solidsoft.pt>.
Yes. I read before posted.
In a conceptual point of view is a good material.
Explains the approach.
Create the component without implementation, surrounding Royale API (the
important is the emulation like an interface, the content/implementation can
and should be different from Flex SDK, using directly Royale API as match as
possible).
And on the finish like, code the implementation.
Also, I understand now, that correctly MXRoyale it's very uggly because the
intention is first to compile a big project (recently done), then put the
things work (components implementation) and only then maybe try to simulate
more or less the Flex SDK UI.
Perhaps, it's just me, but for someone inexperience with Royale API, breads,
etc ..., became lost (or worst can follow to do a bad implementation)
without a code sample guide.
But if there are guys that are doing this successful, perhaps it's just me.
--
Sent from: http://apache-royale-users.20374.n8.nabble.com/
Re: Suggestion: Emulation tutorial
Posted by Alex Harui <ah...@adobe.com>.
Have you already read this? https://github.com/apache/royale-asjs/wiki/emulation-components#getting-an-emulation-component-to-run
-Alex
On 11/15/18, 4:24 PM, "hferreira" <hf...@solidsoft.pt> wrote:
Would be great if one of the experients Royale developers produce a basic
step by step tutorial how to implement a MXRoyale or SparkRoyale component
from scratch (a button for example).
So, let's imagine that there is no MXRoyale button iet and with this
tutorial, would be possible to create a button and test it (press it and do
an action).
If you believe that's worth it.
--
Sent from: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-royale-users.20374.n8.nabble.com%2F&data=02%7C01%7Caharui%40adobe.com%7Cfe4210c71e4b4cdd86f808d64b59e67e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636779246822011899&sdata=BMqqI62s0Bs4egvhqdyW%2FQrJ0jwtxM7w4%2F4VjhWjXDw%3D&reserved=0
Re: Suggestion: Emulation tutorial
Posted by hferreira <hf...@solidsoft.pt>.
Great example Carlos.
Thank you very much.
I will play around with Royale and I have a few question that I will put in
different threads.
--
Sent from: http://apache-royale-users.20374.n8.nabble.com/
Re: Suggestion: Emulation tutorial
Posted by Carlos Rovira <ca...@apache.org>.
Hi Hugo,
I think the closest is this:
https://royale.apache.org/customization-through-the-royale-api/
Is a jewel button that popups a jewel alert and inside some content is
added (a jewel checkbox). You can prepare some content in mxml and add to
the alert content
HTH
Carlos
El vie., 16 nov. 2018 a las 18:37, hferreira (<hf...@solidsoft.pt>)
escribió:
> Hi Carlos,
>
> Thanks for sharing.
>
> Yes, that's an alternative way to migrate and at same point of view, it's a
> good strategy.
> It's not proper a migrate/port process but more a total UI refactoring.
> It's 2 steps in 1 if someone move from mx/spark Flex to mx/spark Royale and
> then jewel Royale.
>
> Yes, for my forum readings and so on, I see that jewel it's advance and
> mx/spark compile as a shell a few days ago and there is a lot of work to do
> to make it running, however seems that is on the good track.
>
> I will "play" around with jewel.
> Can you point a sample (if there is one) that opens a popup window with a
> form ?
>
>
>
> --
> Sent from: http://apache-royale-users.20374.n8.nabble.com/
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Suggestion: Emulation tutorial
Posted by hferreira <hf...@solidsoft.pt>.
Hi Carlos,
Thanks for sharing.
Yes, that's an alternative way to migrate and at same point of view, it's a
good strategy.
It's not proper a migrate/port process but more a total UI refactoring.
It's 2 steps in 1 if someone move from mx/spark Flex to mx/spark Royale and
then jewel Royale.
Yes, for my forum readings and so on, I see that jewel it's advance and
mx/spark compile as a shell a few days ago and there is a lot of work to do
to make it running, however seems that is on the good track.
I will "play" around with jewel.
Can you point a sample (if there is one) that opens a popup window with a
form ?
--
Sent from: http://apache-royale-users.20374.n8.nabble.com/
Re: Suggestion: Emulation tutorial
Posted by Carlos Rovira <ca...@apache.org>.
Hi,
I'm migrating a project and choose to make a mixed approach based on the
following points:
1.- Left server side (Java with BlazeDS) part without touch. Just turning
off small messages for remote object calls
2.- Migrate as many AS3 code as we can, that part that is not tied to MX or
SPARK component sets
3.- As we need a "refresh" in the UI that support modern approach mostly
responsiveness and adaptiveness and something that looks good now since is
what client buys in the end,
so I started doing the Jewel Component Set to match this point.
In the end we are matching all problematic points and we are near to need
only normal user-dev royale work (although we are finding many bugs and
things we need to be solved, but can be solved over time. So we can
consider we are very near of a 1.0 release, in that side (not talking about
Mx/Spark that still needs more work and get more eye candy).
I'm happy with the point we are reaching, but still there's much work to
do! :)
Carlos
El vie., 16 nov. 2018 a las 12:19, hferreira (<hf...@solidsoft.pt>)
escribió:
> We're following a slightly different approach; the effort in getting the
> emulation classes all put together and working properly is huge and it will
> end up being a similar scale to the Flex libraries - lots of code handling
> cases that are very rarely used... so I've much preferred the Royale
> concepts of keeping everything as simple and modular as possible.
> > Yes, I read about that and it's not difficult to see that is a better
> > approach however is Royale exclusive to new applications (the Royale
> > approach), Flex compatibility (emulation) or both ?
> At the beginning of this project (it's already years I think) I saw a lot
> of
> discussion about it and ends up to the new Roayle approach.
> I have a project with 1.5 millions lines of code and more then 500 views.
> Change this to a new approach it's not viable at all.
> Change to the emulation approach in a more mature state will probably need
> weeks of fixs and probably month to the stable but it's acceptable.
> Royale came from Flex, have a new structure and it's good but should not
> forget from where it came from that's why I think that the mix approach
> that
> we have now it's the better one. How prefer using the new approach is not
> affecta at all.
> Perhaps migration a project and letter starting moving thinks to the new
> approach.
> The new emulation that I read on Flex foruns kept my attention.
>
> Anyway, there's always choices for how to do things! And it's perfectly
> possible to use a mixture of the emulation classes, your own classes, and
> other Royale ones...
> > That's true. Flex SDK is a beast and loads many thinks that I don't need.
>
> In terms of documentation, there's some pretty good stuff available
> online:
> https://apache.github.io/royale-docs/Create%20An%20Application.html
> > Thanks. I already saw that. I will read more.
>
>
>
> --
> Sent from: http://apache-royale-users.20374.n8.nabble.com/
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Suggestion: Emulation tutorial
Posted by hferreira <hf...@solidsoft.pt>.
We're following a slightly different approach; the effort in getting the
emulation classes all put together and working properly is huge and it will
end up being a similar scale to the Flex libraries - lots of code handling
cases that are very rarely used... so I've much preferred the Royale
concepts of keeping everything as simple and modular as possible.
> Yes, I read about that and it's not difficult to see that is a better
> approach however is Royale exclusive to new applications (the Royale
> approach), Flex compatibility (emulation) or both ?
At the beginning of this project (it's already years I think) I saw a lot of
discussion about it and ends up to the new Roayle approach.
I have a project with 1.5 millions lines of code and more then 500 views.
Change this to a new approach it's not viable at all.
Change to the emulation approach in a more mature state will probably need
weeks of fixs and probably month to the stable but it's acceptable.
Royale came from Flex, have a new structure and it's good but should not
forget from where it came from that's why I think that the mix approach that
we have now it's the better one. How prefer using the new approach is not
affecta at all.
Perhaps migration a project and letter starting moving thinks to the new
approach.
The new emulation that I read on Flex foruns kept my attention.
Anyway, there's always choices for how to do things! And it's perfectly
possible to use a mixture of the emulation classes, your own classes, and
other Royale ones...
> That's true. Flex SDK is a beast and loads many thinks that I don't need.
In terms of documentation, there's some pretty good stuff available online:
https://apache.github.io/royale-docs/Create%20An%20Application.html
> Thanks. I already saw that. I will read more.
--
Sent from: http://apache-royale-users.20374.n8.nabble.com/