You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@royale.apache.org by Chris Velevitch <ch...@gmail.com> on 2019/10/08 07:23:07 UTC
Acceptance of Royale by Flex Developers
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.
Re: Acceptance of Royale by Flex Developers
Posted by Alex Harui <ah...@adobe.com.INVALID>.
The migration page I linked to earlier attempts to help people get started with MXRoyale and SparkRoyale (by changing the namespaces). After that, the goal is for the components to work similar to the Flex components, so from an ASDoc standpoint, they “should” be able to use the Flex ASDoc and then ask for help when some API they need isn’t emulated.
HTH,
-Alex
From: Carlos Rovira <ca...@apache.org>
Date: Tuesday, October 8, 2019 at 11:59 AM
To: "dev@royale.apache.org" <de...@royale.apache.org>
Cc: Alex Harui <ah...@adobe.com>
Subject: Re: Acceptance of Royale by Flex Developers
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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapache.github.io%2Froyale-docs%2Fcreate-an-application%2Fcreate-an-application&data=02%7C01%7Caharui%40adobe.com%7Cfe552f70e9654e48cb4f08d74c21a519%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637061579699191300&sdata=psCaSm1gieUiw0Vr0SzUcbS3FHh1gaTyZwBgEP%2BC%2Bgs%3D&reserved=0>
)
then MIGRATE FROM FLEX<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapache.github.io%2Froyale-docs%2Fcreate-an-application%2Fcreate-an-application%2Fmigrate-an-existing-app%2Fmigrate-from-flex.html&data=02%7C01%7Caharui%40adobe.com%7Cfe552f70e9654e48cb4f08d74c21a519%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637061579699191300&sdata=BM%2B1rdQp2M5EeDlQzkP0U8%2FLtS7MBnz%2BhMBnDqpz38Q%3D&reserved=0> (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 (<co...@gmail.com>>) escribió:
Really good suggestions, @Alex Harui <ah...@adobe.com>> . 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 <ah...@adobe.com.invalid> 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<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapache.github.io%2Froyale-docs%2Fcreate-an-application%2Fmigrate-an-existing-app%2Fmigrate-from-flex.html&data=02%7C01%7Caharui%40adobe.com%7Cfe552f70e9654e48cb4f08d74c21a519%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637061579699201297&sdata=oLHRIOLrNgyQIfLZ906xWFa5WvAMOy9RanvTjdClSAI%3D&reserved=0>
> 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" <ca...@apache.org>> 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 (<
> chris.velevitch@gmail.com<ma...@gmail.com>>) 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 <ca...@apache.org>>
> > 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 (<
> > chris.velevitch@gmail.com<ma...@gmail.com>>)
> > > 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<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cfe552f70e9654e48cb4f08d74c21a519%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637061579699201297&sdata=CBgt8wnbekAcp4d7mIBkyCCuxFQvmHg2WA1wUh3GtEM%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<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cfe552f70e9654e48cb4f08d74c21a519%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637061579699211295&sdata=Hmz2d6hnWr8jPJ2WbnJTb3s0jRGl541zDyhXF1UxiUQ%3D&reserved=0>
>
>
>
--
Andrew Wetmore
http://cottage14.blogspot.com/<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcottage14.blogspot.com%2F&data=02%7C01%7Caharui%40adobe.com%7Cfe552f70e9654e48cb4f08d74c21a519%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637061579699211295&sdata=nNNwS5MGWD2prya73EXKzTjqyqLrXYb3E1zgSuKgC9Y%3D&reserved=0>
--
Carlos Rovira
http://about.me/carlosrovira<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cfe552f70e9654e48cb4f08d74c21a519%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637061579699221282&sdata=ONKAUA9eMEH9jnZw1lZX6y9vfsrsawuCdNB3K%2BqrpaU%3D&reserved=0>
Re: Acceptance of Royale by Flex Developers
Posted by Carlos Rovira <ca...@apache.org>.
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 (<co...@gmail.com>)
escribió:
> Really good suggestions, @Alex Harui <ah...@adobe.com> . 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 <ah...@adobe.com.invalid>
> 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" <ca...@apache.org> 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 (<
> > chris.velevitch@gmail.com>) 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 <
> carlosrovira@apache.org>
> > > 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 (<
> > > chris.velevitch@gmail.com>)
> > > > 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
Re: Acceptance of Royale by Flex Developers
Posted by Andrew Wetmore <co...@gmail.com>.
Really good suggestions, @Alex Harui <ah...@adobe.com> . 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 <ah...@adobe.com.invalid> 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" <ca...@apache.org> 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 (<
> chris.velevitch@gmail.com>) 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 <ca...@apache.org>
> > 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 (<
> > chris.velevitch@gmail.com>)
> > > 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/
Re: Acceptance of Royale by Flex Developers
Posted by Alex Harui <ah...@adobe.com.INVALID>.
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" <ca...@apache.org> 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 (<
chris.velevitch@gmail.com>) 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 <ca...@apache.org>
> 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 (<
> chris.velevitch@gmail.com>)
> > 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
Re: Acceptance of Royale by Flex Developers
Posted by Carlos Rovira <ca...@apache.org>.
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 (<
chris.velevitch@gmail.com>) 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 <ca...@apache.org>
> 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 (<
> chris.velevitch@gmail.com>)
> > 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
> > http://about.me/carlosrovira
>
>
>
> --
>
>
> Chris
> --
> Chris Velevitch
> m: 0415 469 095
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Acceptance of Royale by Flex Developers
Posted by Chris Velevitch <ch...@gmail.com>.
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 <ca...@apache.org> 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 (<ch...@gmail.com>)
> 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
> http://about.me/carlosrovira
--
Chris
--
Chris Velevitch
m: 0415 469 095
Re: Acceptance of Royale by Flex Developers
Posted by Carlos Rovira <ca...@apache.org>.
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 (<ch...@gmail.com>)
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
http://about.me/carlosrovira