Hi 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.
So we're converting from using e.g. spark:BorderContainer to just having a basic container and adding a 'BorderBead' to it, which takes a minute or two to write and gives us all the functionality that we need. There are other examples that are a little more complex, and we sometimes have to decide between subclassing/extending the Royale classes or adding beads vs trying to adapt the Royale components directly. But with a bit of automation, this feels like it's doable with the end result of a lightweight application that doesn't start initialising elements and properties that we don't need; once we're done with our current migration project, I'd be interested to look at how quickly we could then do another one using the tools/capabilities that we've built up.. 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... In terms of documentation, there's some pretty good stuff available online: https://apache.github.io/royale-docs/Create%20An%20Application.html The "Flex equivalents in Royale" is probably a little out of date as there's a lot more available now I think! Hope that helps Andrew -----Original Message----- From: hferreira [mailto:[email protected]] Sent: 16 November 2018 10:19 To: [email protected] Subject: [EXTERNAL] Re: Suggestion: Emulation tutorial "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: https://clicktime.symantec.com/a/1/a1R4HfGP_tCVcAJB-WsSFF6bTrpuGWGelBrotz1kt3o=?d=44csedyl_MloenmKmD_SmnLptvKHw0QF3b0NVOUCk3mVIa-zIU6kWANR57XqqiWCvyY-gxda6q4vIV-I-T9gSSpZtzE1GqgowpORC2SeuJT7uBiRsp5QEMIGV9KfNRJiWa9vno2FITS40iTMC0nL2GV_9bhNhnlPbJwnjNcEznMYo_5sT0uHfTVklvy--Q_eS-Zf8qYgSpWJdE-bKzyWQZVcc1phZZRgcmxrL49b_SP9UNKhOse-uZBM6eB3LuVEu_OKAP_8GGPBrFeu3UoqbE5Y5FXDU9qRkWa6fB9r3d8su2AQlXfR5z-VZOOtI2aVHbYT0xd0i8WqCrTWemeoWO7qG7VG7ZxqW5sf-M7SUCvuXrmtqD8h_eYpVLkmqKIXT-PRMZk2w_P2guwe82Gvh6x6P5k%3D&u=http%3A%2F%2Fapache-royale-users.20374.n8.nabble.com%2F
