Hi I think we could remove one level or even two.
Have at first level MIGRATE AN EXISTING APPLICATION (instead of inside CREATE AN APPLICATION <https://apache.github.io/royale-docs/create-an-application/create-an-application> ) then MIGRATE FROM FLEX <https://apache.github.io/royale-docs/create-an-application/create-an-application/migrate-an-existing-app/migrate-from-flex.html> (nested) And inside this we can add other entries to help that migration. We still don't have anything about MX / SPARK emulation components in docs, so more info should be added if we want to make it people use it. just my 2 Carlos El mar., 8 oct. 2019 a las 19:00, Andrew Wetmore (<[email protected]>) escribió: > Really good suggestions, @Alex Harui <[email protected]> . I could add text > and links to the "migrating" page based on what you outlined. I can get > that done sometime this week, but am not going to jump on it today in case > the conversation continues and an enhanced idea bubbles up. > > Andrew > > On Tue, Oct 8, 2019 at 12:48 PM Alex Harui <[email protected]> > wrote: > > > I'm going to try to address all of Chris Velevitch's several threads from > > today in this response. > > > > We have a page on Migrating Flex Apps here: > > > https://apache.github.io/royale-docs/create-an-application/migrate-an-existing-app/migrate-from-flex.html > > But it is hard to find (took me several clicks to find it). And it > > doesn't address the questions that I think Chris is asking, which are: > > > > -Which component sets should I use? > > -After I choose a component set, how do I figure out how something that > > worked in Flex works in that component set? > > > > We've offered Chris the opportunity to help with the doc, which would be > > great, but I'd settle for having Chris and others simply add the kinds of > > questions they have so we can add them to our FAQ and/or the docs. > > > > We may need to make it easier for Chris and others to decide on component > > sets first. The way I think of it now, the trade offs are: > > A) I need the result to be as small and fast as possible and have time to > > rewrite the UI -> Use Basic and Strands and Beads > > B) I want to rewrite the UI to get a more modern look-and-feel -> Use > Jewel > > C) I want to touch as little code as possible -> Use MXRoyale and > > SparkRoyale. > > > > If you choose C, you should not have to know anything about Strands and > > Beads. MXRoyale and SparkRoyale should hide that from you. Skinning > > should work like it used to. Your app will not be as small and fast as > if > > you spend more time rewriting it to Basic or Jewel, but TourDeFlex seems > to > > be running ok. As Alina and Pashmina finish up, we'll see how a really > big > > Flex migration performs in Royale. > > > > It has taken them longer than expected, but for every bug or missing > > feature that is emulated correctly, the time to migrate for the next > person > > goes down. And as 2019 becomes 2020, there will be less time to migrate > > for some folks, so having more people on the emulation helps everyone > else. > > > > So, we should figure out where to place information like this so Chris > and > > others find it more easily. Once a component set/migration strategy is > > chosen, it focuses a lot of other questions, such as how to do skinning, > or > > how much about Strands and Beads you have to know. In fact, it would be > > great to find a place to recommend to folks that when they write to us > with > > questions that they specify which component set(s) they are using because > > the answer can be quite different based on the component sets involved. > > > > Suggestions from Chris and others as to how to make this information more > > accessible are encouraged. > > > > My 2 cents, > > -Alex > > > > > > On 10/8/19, 8:18 AM, "Carlos Rovira" <[email protected]> wrote: > > > > Hi, > > > > I mean that like RO, that's a non visual component used to perform > > communications, we have other "components" or "code" that can be > > implemented as beads or strands. > > The concept behind is that Royale have the minimum code needed for > > functionality, and compose other parts (whatever the purpose of the > > code > > could be). So while UI Components use to refer to code that are > visual > > and > > use to be a Button, a List or a Checkbox, strands are more agonistic > > about > > that particular use case, so seems, IMHO a better way to describe it > > from > > that point of view. > > > > El mar., 8 oct. 2019 a las 10:14, Chris Velevitch (< > > [email protected]>) escribió: > > > > > So you are suggesting a RemoteObject is a headless component who's > > > base class only supports the model and controller plugins and that > UI > > > classes extend the headless component to add in the view? > > > > > > On Tue, 8 Oct 2019 at 15:52, Carlos Rovira < > [email protected]> > > > wrote: > > > > > > > > Hi Chris, > > > > > > > > thanks for sharing your thoughts. > > > > > > > > IMHO, not always a "strand" is a "visual component". This > relation > > is not > > > > always true. a strand could be a non visual component (for > example > > the > > > > implementation of RemoteObject in the Network library). And a > bead > > could > > > be > > > > a strand itself. > > > > > > > > I think the term component is right in most cases and accomplish > a > > > meaning > > > > purpose, but strand/beads concept comes to give another subset of > > meaning > > > > > > > > just my opinion about this. > > > > > > > > Carlos > > > > > > > > > > > > > > > > El mar., 8 oct. 2019 a las 9:23, Chris Velevitch (< > > > [email protected]>) > > > > escribió: > > > > > > > > > The use of the terms "strands" and "beads" still doesn't make > > sense to > > > > > me because they are concepts I have never heard before and it > is > > > > > creating a barrier to acceptance and deepens the learning > curve. > > As > > > > > far as I can tell, it's something to do with visual/UI > > components. > > > > > > > > > > The section "Strands and Beads" should ideally be titled > "Visual > > > > > Components" because that section is about visual components and > > is > > > > > alluding to the fact visual components are standalone > microcosms > > of > > > > > the MVC pattern and the ability to treat the model, view and > > > > > controller as plugins to the component. The statement that > > components > > > > > are "strands" is, in my mind, misleading because it doesn't > make > > sense > > > > > to interchange terms components and strands if a strand is a > > > > > component. In fact, diving into the code, the "addBead" > function > > gives > > > > > the "bead" a reference to the component the "bead" is being > > added to. > > > > > > > > > > It is clear from the documentation that "beads" are "plugins" > > and the > > > > > documentation should be talking about extending components with > > > > > plugins. All references to "bead" should be replaced with > > "plugin" and > > > > > all references to "strand" be replaced with either > > "hostComponent", or > > > > > "parent" or appropriately something else. > > > > > > > > > > We seem to be neglecting the rich heritage that we have gotten > > from > > > > > Adobe Flex and I don't see the point giving existing concepts > new > > > > > names. > > > > > > > > > > > > > > > > > -- > > > > Carlos Rovira > > > > > > > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C56331bd7a799497db41308d74c02c990%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637061447162721530&sdata=zhUI1U2%2F0jU9Od5Pm2pE%2B6RKrJxm97BafPqJ%2FVxrB%2Bg%3D&reserved=0 > > > > > > > > > > > > -- > > > > > > > > > Chris > > > -- > > > Chris Velevitch > > > m: 0415 469 095 > > > > > > > > > -- > > Carlos Rovira > > > > > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C56331bd7a799497db41308d74c02c990%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637061447162721530&sdata=zhUI1U2%2F0jU9Od5Pm2pE%2B6RKrJxm97BafPqJ%2FVxrB%2Bg%3D&reserved=0 > > > > > > > > -- > Andrew Wetmore > > http://cottage14.blogspot.com/ > -- Carlos Rovira http://about.me/carlosrovira
