You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@royale.apache.org by Andrew Wetmore <co...@gmail.com> on 2018/12/28 13:06:53 UTC
User docs entry for strands and beads
Hi, all:
I am working on the user doc page for strands and beads [1]. This is
intended for application developers using Royale; there is unfinished
material available for developers working on Royale itself in the wiki [2],
[3].
From the app developer point of view, I want to answer these questions:
1. There are three ways of adding beads to a component: baked in using
<js:beads>, through CSS, and dynamically using addBead(). Which method is
best to use for what purposes?
1a. I can see from the wiki clear examples for two methods of adding beads.
Can someone point to an example using CSS to add a bead to a component?
2. Is the order of beads on a strand significant?
3. How much should I worry about bead cleanup when a bead is no longer
actively used? I presume this would relate to dynamically-added beads, not
the <js:beads> or CSS ones.
4. Where do I find the existing beads? Is there a curated list for each
release of Royale? How do I know which ones would be useful for a text
entry field, a list, a button?
Thanks!
a
[1]
https://apache.github.io/royale-docs/Welcome/Features/Strands%20and%20Beads.html
[2]
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=71013028
[3] https://cwiki.apache.org/confluence/display/FLEX/Creating+Components
--
Andrew Wetmore
http://cottage14.blogspot.com/
Re: User docs entry for strands and beads
Posted by Andrew Wetmore <co...@gmail.com>.
Well, cool! I will check it later today. Thank you for taking a look.
On Thu, Jan 3, 2019 at 5:41 AM Alex Harui <ah...@adobe.com> wrote:
> Actually, I found some time to look and it was quite broken, probably from
> when we merged platform files. I think it is working now (after the CI
> server builds it).
>
> -Alex
>
> On 1/1/19, 8:16 PM, "Alex Harui" <ah...@adobe.com.INVALID> wrote:
>
> Bummer. I haven’t tested that filter in a long time. It is supposed
> to filter the list of classes to only those with an @toplevel or @viewbead
> ASDoc tag. Longer term, the checkboxes would be replaced by a better
> filtering dialog otherwise after we add too many checkboxes, the UI would
> become unwieldy.
>
> Volunteers are welcome to fix it. Might be a good way to learn more
> about Royale.
>
> -Alex
>
> From: Andrew Wetmore <co...@gmail.com>
> Date: Tuesday, January 1, 2019 at 7:22 AM
> To: "dev@royale.apache.org" <de...@royale.apache.org>, Alex Harui <
> aharui@adobe.com>
> Subject: Re: User docs entry for strands and beads
>
> Hi, gang, and Happy New Year.
>
> @Alex Harui<ma...@adobe.com> thank you for your thoughts and
> pointers. I have an immediate question related to the ASDoc material: you
> say "I added a few ASDoc tags like @toplevel and @viewbead to some of the
> ASDoc and there is a cheap checkbox filter for it." No matter where I am in
> the ASDoc project, if I check that checkbox I get a blank display with an
> unending "Loading..." message. What is supposed to happen?
>
> On Sat, Dec 29, 2018 at 12:34 PM Alex Harui <ah...@adobe.com.invalid>
> wrote:
> Hi,
>
> Specifically, the "delete removeBead" change would consist of:
>
> 1) making the strand's array public
> 2) removing removeBead from IStrand and UIBase and HTMLElementWrapper
> (and other places)
> 3) adding an org.apache.royale.utils.removeBead function.
>
> Because, you are correct that someone is going to want to remove a
> bead at some point, but we shouldn't weigh down every app with
> "just-in-case" code and the API surface should discourage "un-recommended"
> practices. It should be an extremely rare occurrence to remove a bead.
>
> On a related note, I checked the other day and HelloWorld is now over
> 80K. It was once 29K. That's how much "just-in-case" code we might have
> added. At some point we need to go back and look at what was in the 51K of
> code we added and make sure it really has to be there. Refactoring many of
> our utils classes into single-purpose functions may help. Your latest
> change to UIUtils won't affect HelloWorld but will affect anyone else who
> uses UIUtils. We need to break up UIUtils into separate functions so that
> convenience functions don't add weight to apps that don't use those
> functions. Volunteers to make those changes are welcome. In Flex,
> HelloWorld was 133K, we are dangerously approaching that number and we
> should hopefully not have to be even close to it if we are handling PAYG
> correctly.
>
> My 2 cents,
> -Alex
>
> On 12/29/18, 1:33 AM, "Carlos Rovira" <carlosrovira@apache.org<mailto:
> carlosrovira@apache.org>> wrote:
>
> Hi Alex,
>
> very valuable info as always.
>
> +1 to make "getBeadByType" return latest bead added and to keep
> removeBead
> API as we have today.
>
> I found that problem and although I understand your point and
> reasons on
> what you explain, we must understand the reality that many few
> users will
> be such advanced to know exactly that we want them to use Royale
> in that
> concrete way, so some people will try to add beads of the same
> type, and I
> think that we as a framework should be as flexible as possible to
> allow
> this kind of things
>
>
>
> El sáb., 29 dic. 2018 a las 8:55, Alex Harui
> (<ah...@adobe.com.invalid>)
> escribió:
>
> > Answers/Opinions inline
> >
> > On 12/28/18, 5:07 AM, "Andrew Wetmore" <cottage14@gmail.com
> <ma...@gmail.com>> wrote:
> >
> > Hi, all:
> >
> > I am working on the user doc page for strands and beads [1].
> This is
> > intended for application developers using Royale; there is
> unfinished
> > material available for developers working on Royale itself
> in the wiki
> > [2],
> > [3].
> >
> > From the app developer point of view, I want to answer these
> questions:
> >
> > 1. There are three ways of adding beads to a component:
> baked in using
> > <js:beads>, through CSS, and dynamically using addBead().
> Which method
> > is
> > best to use for what purposes?
> >
> > CSS sets up loosely-coupled defaults. Almost all (probably all)
> Royale
> > components that are strands pick up default beads from CSS. CSS
> allows
> > setting default beads for one or more instances of a component
> in a single
> > CSS Selector, just like CSS lets you set values on one or more
> > HTMLElements. But if our SWCs specify a certain bead as a
> default, and the
> > app dev's CSS specifies a different one, it should be possible
> for certain
> > CSS tools to optimize away the original default bead so it isn't
> linked
> > into the output.
> >
> > <js:beads> is the MXML way of calling addBead(). It allows the
> developer
> > to override the defaults bead from CSS for a single instance.
> But now that
> > bead is not loosely coupled, so if someone later subclasses the
> class that
> > used js:beads or addBead, and specify a different bead, both the
> original
> > and the new bead will be in the output. It isn't that much
> different from
> > specifying the "style" property on an HTMLElement in HTML.
> Js:Beads and
> > addBead overrides the underlying CSS.
> >
> >
> >
> > 1a. I can see from the wiki clear examples for two methods
> of adding
> > beads.
> > Can someone point to an example using CSS to add a bead to a
> component?
> >
> > Almost every SWC has a defaults.css file in src/main/resources
> that
> > specify the default beads. Several examples have MXML files
> that override
> > the defaults in CSS. Search the mxml files for "ClassReference"
> >
> >
> > 2. Is the order of beads on a strand significant?
> >
> > Yes. That’s one reason I proposed "strands and beads" instead
> of "peas
> > and porridge" or some other analogy. In real life the physical
> beads you
> > put on a strand totally change the look of the necklace or
> bracelet. That
> > can be the case here as well. I don't think there are any
> examples where
> > order causes a significant difference that doesn't result in a
> thrown
> > exception from a null pointer, but if you don't specify order,
> you can get
> > indeterminate results which we definitely don't want. Others
> have pointed
> > out the common issues (model first, then view, or making sure
> event
> > listeners fire in the right order. Sadly, I just looked and
> noted that
> > getBeadByType is probably written incorrectly. It should
> probably return
> > the last bead added so you can override other beads if needed.
> Right now,
> > first-in-wins. I'm not sure we want that. But in theory, nobody
> should
> > ever add more than one bead of the same type to the strand. The
> ways of
> > overriding the defaults should prevent the need for late
> overriding of
> > beads.
> >
> >
> > 3. How much should I worry about bead cleanup when a bead is
> no longer
> > actively used? I presume this would relate to
> dynamically-added beads,
> > not
> > the <js:beads> or CSS ones.
> >
> > I've been tempted to delete the removeBead API. Beads should
> never be
> > removed. We are compositing beads to form a component instead of
> > subclassing base classes. Both build up functionality and
> should never
> > "delete" it. It might mask or block "base-class" functionality,
> but you
> > can't remove code from a base class, and theoretically, beads
> should never
> > be removed either.
> >
> >
> > 4. Where do I find the existing beads? Is there a curated
> list for each
> > release of Royale? How do I know which ones would be useful
> for a text
> > entry field, a list, a button?
> >
> > I added a few ASDoc tags like @toplevel and @viewbead to some of
> the ASDoc
> > and there is a cheap checkbox filter for it. More asdoc tags
> need to be
> > added and you are encouraged to come up with other ASDoc tags and
> > references to other components. That's one reason why ASDoc is
> a Royale
> > app, so we can add client-side logic to provide more
> sophisticated
> > filtering someday that makes use of ASDoc tags.
> >
> > Thanks for working on it,
> > -Alex
> >
> >
> > Thanks!
> >
> > a
> >
> >
> > [1]
> >
> >
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapache.github.io%2Froyale-docs%2FWelcome%2FFeatures%2FStrands%2520and%2520Beads.html&data=02%7C01%7Caharui%40adobe.com%7C619bfe182dd94778920f08d67069092d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636819993805295794&sdata=2nuiHvtk%2B6yJhAsDTaJAwSg4cgt8AY0uYo8ZGTdgbl4%3D&reserved=0
> <
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapache.github.io%2Froyale-docs%2FWelcome%2FFeatures%2FStrands%2520and%2520Beads.html&data=02%7C01%7Caharui%40adobe.com%7C619bfe182dd94778920f08d67069092d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636819993805295794&sdata=2nuiHvtk%2B6yJhAsDTaJAwSg4cgt8AY0uYo8ZGTdgbl4%3D&reserved=0
> >
> > [2]
> >
> >
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fpages%2Fviewpage.action%3FpageId%3D71013028&data=02%7C01%7Caharui%40adobe.com%7C619bfe182dd94778920f08d67069092d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636819993805305798&sdata=cSggNQKSz%2BWgwzXDW%2FF6NnDgcfW%2BOdIYG%2Bo0FAs3hMo%3D&reserved=0
> <
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fpages%2Fviewpage.action%3FpageId%3D71013028&data=02%7C01%7Caharui%40adobe.com%7C619bfe182dd94778920f08d67069092d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636819993805305798&sdata=cSggNQKSz%2BWgwzXDW%2FF6NnDgcfW%2BOdIYG%2Bo0FAs3hMo%3D&reserved=0
> >
> > [3]
> >
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FFLEX%2FCreating%2BComponents&data=02%7C01%7Caharui%40adobe.com%7C619bfe182dd94778920f08d67069092d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636819993805305798&sdata=JyFgCkuqzwMfuJDQQ5bzavZU59h%2FfAp8VUeWfnksUew%3D&reserved=0
> <
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FFLEX%2FCreating%2BComponents&data=02%7C01%7Caharui%40adobe.com%7C619bfe182dd94778920f08d67069092d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636819993805305798&sdata=JyFgCkuqzwMfuJDQQ5bzavZU59h%2FfAp8VUeWfnksUew%3D&reserved=0
> >
> >
> > --
> > Andrew Wetmore
> >
> >
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcottage14.blogspot.com%2F&data=02%7C01%7Caharui%40adobe.com%7C619bfe182dd94778920f08d67069092d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636819993805305798&sdata=eOc0EBTodoX2fkaj2XqmDQbl1AEzVLtBaJeHuRDY5QM%3D&reserved=0
> <
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcottage14.blogspot.com%2F&data=02%7C01%7Caharui%40adobe.com%7C619bfe182dd94778920f08d67069092d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636819993805305798&sdata=eOc0EBTodoX2fkaj2XqmDQbl1AEzVLtBaJeHuRDY5QM%3D&reserved=0
> >
> >
> >
> >
>
> --
> Carlos Rovira
>
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C619bfe182dd94778920f08d67069092d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636819993805305798&sdata=LZdtSnXfDUaD7%2F3ZitCEUErNoySFmggeyfHZ%2B0oJSNU%3D&reserved=0
> <
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C619bfe182dd94778920f08d67069092d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636819993805305798&sdata=LZdtSnXfDUaD7%2F3ZitCEUErNoySFmggeyfHZ%2B0oJSNU%3D&reserved=0
> >
>
>
>
> --
> Andrew Wetmore
>
>
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcottage14.blogspot.com%2F&data=02%7C01%7Caharui%40adobe.com%7C619bfe182dd94778920f08d67069092d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636819993805305798&sdata=eOc0EBTodoX2fkaj2XqmDQbl1AEzVLtBaJeHuRDY5QM%3D&reserved=0
> <
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcottage14.blogspot.com%2F&data=02%7C01%7Caharui%40adobe.com%7C619bfe182dd94778920f08d67069092d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636819993805305798&sdata=eOc0EBTodoX2fkaj2XqmDQbl1AEzVLtBaJeHuRDY5QM%3D&reserved=0
> >
>
>
>
>
>
>
>
--
Andrew Wetmore
http://cottage14.blogspot.com/
Re: User docs entry for strands and beads
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Actually, I found some time to look and it was quite broken, probably from when we merged platform files. I think it is working now (after the CI server builds it).
-Alex
On 1/1/19, 8:16 PM, "Alex Harui" <ah...@adobe.com.INVALID> wrote:
Bummer. I haven’t tested that filter in a long time. It is supposed to filter the list of classes to only those with an @toplevel or @viewbead ASDoc tag. Longer term, the checkboxes would be replaced by a better filtering dialog otherwise after we add too many checkboxes, the UI would become unwieldy.
Volunteers are welcome to fix it. Might be a good way to learn more about Royale.
-Alex
From: Andrew Wetmore <co...@gmail.com>
Date: Tuesday, January 1, 2019 at 7:22 AM
To: "dev@royale.apache.org" <de...@royale.apache.org>, Alex Harui <ah...@adobe.com>
Subject: Re: User docs entry for strands and beads
Hi, gang, and Happy New Year.
@Alex Harui<ma...@adobe.com> thank you for your thoughts and pointers. I have an immediate question related to the ASDoc material: you say "I added a few ASDoc tags like @toplevel and @viewbead to some of the ASDoc and there is a cheap checkbox filter for it." No matter where I am in the ASDoc project, if I check that checkbox I get a blank display with an unending "Loading..." message. What is supposed to happen?
On Sat, Dec 29, 2018 at 12:34 PM Alex Harui <ah...@adobe.com.invalid> wrote:
Hi,
Specifically, the "delete removeBead" change would consist of:
1) making the strand's array public
2) removing removeBead from IStrand and UIBase and HTMLElementWrapper (and other places)
3) adding an org.apache.royale.utils.removeBead function.
Because, you are correct that someone is going to want to remove a bead at some point, but we shouldn't weigh down every app with "just-in-case" code and the API surface should discourage "un-recommended" practices. It should be an extremely rare occurrence to remove a bead.
On a related note, I checked the other day and HelloWorld is now over 80K. It was once 29K. That's how much "just-in-case" code we might have added. At some point we need to go back and look at what was in the 51K of code we added and make sure it really has to be there. Refactoring many of our utils classes into single-purpose functions may help. Your latest change to UIUtils won't affect HelloWorld but will affect anyone else who uses UIUtils. We need to break up UIUtils into separate functions so that convenience functions don't add weight to apps that don't use those functions. Volunteers to make those changes are welcome. In Flex, HelloWorld was 133K, we are dangerously approaching that number and we should hopefully not have to be even close to it if we are handling PAYG correctly.
My 2 cents,
-Alex
On 12/29/18, 1:33 AM, "Carlos Rovira" <ca...@apache.org>> wrote:
Hi Alex,
very valuable info as always.
+1 to make "getBeadByType" return latest bead added and to keep removeBead
API as we have today.
I found that problem and although I understand your point and reasons on
what you explain, we must understand the reality that many few users will
be such advanced to know exactly that we want them to use Royale in that
concrete way, so some people will try to add beads of the same type, and I
think that we as a framework should be as flexible as possible to allow
this kind of things
El sáb., 29 dic. 2018 a las 8:55, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> Answers/Opinions inline
>
> On 12/28/18, 5:07 AM, "Andrew Wetmore" <co...@gmail.com>> wrote:
>
> Hi, all:
>
> I am working on the user doc page for strands and beads [1]. This is
> intended for application developers using Royale; there is unfinished
> material available for developers working on Royale itself in the wiki
> [2],
> [3].
>
> From the app developer point of view, I want to answer these questions:
>
> 1. There are three ways of adding beads to a component: baked in using
> <js:beads>, through CSS, and dynamically using addBead(). Which method
> is
> best to use for what purposes?
>
> CSS sets up loosely-coupled defaults. Almost all (probably all) Royale
> components that are strands pick up default beads from CSS. CSS allows
> setting default beads for one or more instances of a component in a single
> CSS Selector, just like CSS lets you set values on one or more
> HTMLElements. But if our SWCs specify a certain bead as a default, and the
> app dev's CSS specifies a different one, it should be possible for certain
> CSS tools to optimize away the original default bead so it isn't linked
> into the output.
>
> <js:beads> is the MXML way of calling addBead(). It allows the developer
> to override the defaults bead from CSS for a single instance. But now that
> bead is not loosely coupled, so if someone later subclasses the class that
> used js:beads or addBead, and specify a different bead, both the original
> and the new bead will be in the output. It isn't that much different from
> specifying the "style" property on an HTMLElement in HTML. Js:Beads and
> addBead overrides the underlying CSS.
>
>
>
> 1a. I can see from the wiki clear examples for two methods of adding
> beads.
> Can someone point to an example using CSS to add a bead to a component?
>
> Almost every SWC has a defaults.css file in src/main/resources that
> specify the default beads. Several examples have MXML files that override
> the defaults in CSS. Search the mxml files for "ClassReference"
>
>
> 2. Is the order of beads on a strand significant?
>
> Yes. That’s one reason I proposed "strands and beads" instead of "peas
> and porridge" or some other analogy. In real life the physical beads you
> put on a strand totally change the look of the necklace or bracelet. That
> can be the case here as well. I don't think there are any examples where
> order causes a significant difference that doesn't result in a thrown
> exception from a null pointer, but if you don't specify order, you can get
> indeterminate results which we definitely don't want. Others have pointed
> out the common issues (model first, then view, or making sure event
> listeners fire in the right order. Sadly, I just looked and noted that
> getBeadByType is probably written incorrectly. It should probably return
> the last bead added so you can override other beads if needed. Right now,
> first-in-wins. I'm not sure we want that. But in theory, nobody should
> ever add more than one bead of the same type to the strand. The ways of
> overriding the defaults should prevent the need for late overriding of
> beads.
>
>
> 3. How much should I worry about bead cleanup when a bead is no longer
> actively used? I presume this would relate to dynamically-added beads,
> not
> the <js:beads> or CSS ones.
>
> I've been tempted to delete the removeBead API. Beads should never be
> removed. We are compositing beads to form a component instead of
> subclassing base classes. Both build up functionality and should never
> "delete" it. It might mask or block "base-class" functionality, but you
> can't remove code from a base class, and theoretically, beads should never
> be removed either.
>
>
> 4. Where do I find the existing beads? Is there a curated list for each
> release of Royale? How do I know which ones would be useful for a text
> entry field, a list, a button?
>
> I added a few ASDoc tags like @toplevel and @viewbead to some of the ASDoc
> and there is a cheap checkbox filter for it. More asdoc tags need to be
> added and you are encouraged to come up with other ASDoc tags and
> references to other components. That's one reason why ASDoc is a Royale
> app, so we can add client-side logic to provide more sophisticated
> filtering someday that makes use of ASDoc tags.
>
> Thanks for working on it,
> -Alex
>
>
> Thanks!
>
> a
>
>
> [1]
>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapache.github.io%2Froyale-docs%2FWelcome%2FFeatures%2FStrands%2520and%2520Beads.html&data=02%7C01%7Caharui%40adobe.com%7C619bfe182dd94778920f08d67069092d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636819993805295794&sdata=2nuiHvtk%2B6yJhAsDTaJAwSg4cgt8AY0uYo8ZGTdgbl4%3D&reserved=0<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapache.github.io%2Froyale-docs%2FWelcome%2FFeatures%2FStrands%2520and%2520Beads.html&data=02%7C01%7Caharui%40adobe.com%7C619bfe182dd94778920f08d67069092d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636819993805295794&sdata=2nuiHvtk%2B6yJhAsDTaJAwSg4cgt8AY0uYo8ZGTdgbl4%3D&reserved=0>
> [2]
>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fpages%2Fviewpage.action%3FpageId%3D71013028&data=02%7C01%7Caharui%40adobe.com%7C619bfe182dd94778920f08d67069092d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636819993805305798&sdata=cSggNQKSz%2BWgwzXDW%2FF6NnDgcfW%2BOdIYG%2Bo0FAs3hMo%3D&reserved=0<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fpages%2Fviewpage.action%3FpageId%3D71013028&data=02%7C01%7Caharui%40adobe.com%7C619bfe182dd94778920f08d67069092d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636819993805305798&sdata=cSggNQKSz%2BWgwzXDW%2FF6NnDgcfW%2BOdIYG%2Bo0FAs3hMo%3D&reserved=0>
> [3]
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FFLEX%2FCreating%2BComponents&data=02%7C01%7Caharui%40adobe.com%7C619bfe182dd94778920f08d67069092d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636819993805305798&sdata=JyFgCkuqzwMfuJDQQ5bzavZU59h%2FfAp8VUeWfnksUew%3D&reserved=0<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FFLEX%2FCreating%2BComponents&data=02%7C01%7Caharui%40adobe.com%7C619bfe182dd94778920f08d67069092d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636819993805305798&sdata=JyFgCkuqzwMfuJDQQ5bzavZU59h%2FfAp8VUeWfnksUew%3D&reserved=0>
>
> --
> Andrew Wetmore
>
>
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcottage14.blogspot.com%2F&data=02%7C01%7Caharui%40adobe.com%7C619bfe182dd94778920f08d67069092d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636819993805305798&sdata=eOc0EBTodoX2fkaj2XqmDQbl1AEzVLtBaJeHuRDY5QM%3D&reserved=0<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcottage14.blogspot.com%2F&data=02%7C01%7Caharui%40adobe.com%7C619bfe182dd94778920f08d67069092d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636819993805305798&sdata=eOc0EBTodoX2fkaj2XqmDQbl1AEzVLtBaJeHuRDY5QM%3D&reserved=0>
>
>
>
--
Carlos Rovira
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C619bfe182dd94778920f08d67069092d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636819993805305798&sdata=LZdtSnXfDUaD7%2F3ZitCEUErNoySFmggeyfHZ%2B0oJSNU%3D&reserved=0<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C619bfe182dd94778920f08d67069092d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636819993805305798&sdata=LZdtSnXfDUaD7%2F3ZitCEUErNoySFmggeyfHZ%2B0oJSNU%3D&reserved=0>
--
Andrew Wetmore
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcottage14.blogspot.com%2F&data=02%7C01%7Caharui%40adobe.com%7C619bfe182dd94778920f08d67069092d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636819993805305798&sdata=eOc0EBTodoX2fkaj2XqmDQbl1AEzVLtBaJeHuRDY5QM%3D&reserved=0<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcottage14.blogspot.com%2F&data=02%7C01%7Caharui%40adobe.com%7C619bfe182dd94778920f08d67069092d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636819993805305798&sdata=eOc0EBTodoX2fkaj2XqmDQbl1AEzVLtBaJeHuRDY5QM%3D&reserved=0>
Re: User docs entry for strands and beads
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Bummer. I haven’t tested that filter in a long time. It is supposed to filter the list of classes to only those with an @toplevel or @viewbead ASDoc tag. Longer term, the checkboxes would be replaced by a better filtering dialog otherwise after we add too many checkboxes, the UI would become unwieldy.
Volunteers are welcome to fix it. Might be a good way to learn more about Royale.
-Alex
From: Andrew Wetmore <co...@gmail.com>
Date: Tuesday, January 1, 2019 at 7:22 AM
To: "dev@royale.apache.org" <de...@royale.apache.org>, Alex Harui <ah...@adobe.com>
Subject: Re: User docs entry for strands and beads
Hi, gang, and Happy New Year.
@Alex Harui<ma...@adobe.com> thank you for your thoughts and pointers. I have an immediate question related to the ASDoc material: you say "I added a few ASDoc tags like @toplevel and @viewbead to some of the ASDoc and there is a cheap checkbox filter for it." No matter where I am in the ASDoc project, if I check that checkbox I get a blank display with an unending "Loading..." message. What is supposed to happen?
On Sat, Dec 29, 2018 at 12:34 PM Alex Harui <ah...@adobe.com.invalid> wrote:
Hi,
Specifically, the "delete removeBead" change would consist of:
1) making the strand's array public
2) removing removeBead from IStrand and UIBase and HTMLElementWrapper (and other places)
3) adding an org.apache.royale.utils.removeBead function.
Because, you are correct that someone is going to want to remove a bead at some point, but we shouldn't weigh down every app with "just-in-case" code and the API surface should discourage "un-recommended" practices. It should be an extremely rare occurrence to remove a bead.
On a related note, I checked the other day and HelloWorld is now over 80K. It was once 29K. That's how much "just-in-case" code we might have added. At some point we need to go back and look at what was in the 51K of code we added and make sure it really has to be there. Refactoring many of our utils classes into single-purpose functions may help. Your latest change to UIUtils won't affect HelloWorld but will affect anyone else who uses UIUtils. We need to break up UIUtils into separate functions so that convenience functions don't add weight to apps that don't use those functions. Volunteers to make those changes are welcome. In Flex, HelloWorld was 133K, we are dangerously approaching that number and we should hopefully not have to be even close to it if we are handling PAYG correctly.
My 2 cents,
-Alex
On 12/29/18, 1:33 AM, "Carlos Rovira" <ca...@apache.org>> wrote:
Hi Alex,
very valuable info as always.
+1 to make "getBeadByType" return latest bead added and to keep removeBead
API as we have today.
I found that problem and although I understand your point and reasons on
what you explain, we must understand the reality that many few users will
be such advanced to know exactly that we want them to use Royale in that
concrete way, so some people will try to add beads of the same type, and I
think that we as a framework should be as flexible as possible to allow
this kind of things
El sáb., 29 dic. 2018 a las 8:55, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> Answers/Opinions inline
>
> On 12/28/18, 5:07 AM, "Andrew Wetmore" <co...@gmail.com>> wrote:
>
> Hi, all:
>
> I am working on the user doc page for strands and beads [1]. This is
> intended for application developers using Royale; there is unfinished
> material available for developers working on Royale itself in the wiki
> [2],
> [3].
>
> From the app developer point of view, I want to answer these questions:
>
> 1. There are three ways of adding beads to a component: baked in using
> <js:beads>, through CSS, and dynamically using addBead(). Which method
> is
> best to use for what purposes?
>
> CSS sets up loosely-coupled defaults. Almost all (probably all) Royale
> components that are strands pick up default beads from CSS. CSS allows
> setting default beads for one or more instances of a component in a single
> CSS Selector, just like CSS lets you set values on one or more
> HTMLElements. But if our SWCs specify a certain bead as a default, and the
> app dev's CSS specifies a different one, it should be possible for certain
> CSS tools to optimize away the original default bead so it isn't linked
> into the output.
>
> <js:beads> is the MXML way of calling addBead(). It allows the developer
> to override the defaults bead from CSS for a single instance. But now that
> bead is not loosely coupled, so if someone later subclasses the class that
> used js:beads or addBead, and specify a different bead, both the original
> and the new bead will be in the output. It isn't that much different from
> specifying the "style" property on an HTMLElement in HTML. Js:Beads and
> addBead overrides the underlying CSS.
>
>
>
> 1a. I can see from the wiki clear examples for two methods of adding
> beads.
> Can someone point to an example using CSS to add a bead to a component?
>
> Almost every SWC has a defaults.css file in src/main/resources that
> specify the default beads. Several examples have MXML files that override
> the defaults in CSS. Search the mxml files for "ClassReference"
>
>
> 2. Is the order of beads on a strand significant?
>
> Yes. That’s one reason I proposed "strands and beads" instead of "peas
> and porridge" or some other analogy. In real life the physical beads you
> put on a strand totally change the look of the necklace or bracelet. That
> can be the case here as well. I don't think there are any examples where
> order causes a significant difference that doesn't result in a thrown
> exception from a null pointer, but if you don't specify order, you can get
> indeterminate results which we definitely don't want. Others have pointed
> out the common issues (model first, then view, or making sure event
> listeners fire in the right order. Sadly, I just looked and noted that
> getBeadByType is probably written incorrectly. It should probably return
> the last bead added so you can override other beads if needed. Right now,
> first-in-wins. I'm not sure we want that. But in theory, nobody should
> ever add more than one bead of the same type to the strand. The ways of
> overriding the defaults should prevent the need for late overriding of
> beads.
>
>
> 3. How much should I worry about bead cleanup when a bead is no longer
> actively used? I presume this would relate to dynamically-added beads,
> not
> the <js:beads> or CSS ones.
>
> I've been tempted to delete the removeBead API. Beads should never be
> removed. We are compositing beads to form a component instead of
> subclassing base classes. Both build up functionality and should never
> "delete" it. It might mask or block "base-class" functionality, but you
> can't remove code from a base class, and theoretically, beads should never
> be removed either.
>
>
> 4. Where do I find the existing beads? Is there a curated list for each
> release of Royale? How do I know which ones would be useful for a text
> entry field, a list, a button?
>
> I added a few ASDoc tags like @toplevel and @viewbead to some of the ASDoc
> and there is a cheap checkbox filter for it. More asdoc tags need to be
> added and you are encouraged to come up with other ASDoc tags and
> references to other components. That's one reason why ASDoc is a Royale
> app, so we can add client-side logic to provide more sophisticated
> filtering someday that makes use of ASDoc tags.
>
> Thanks for working on it,
> -Alex
>
>
> Thanks!
>
> a
>
>
> [1]
>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapache.github.io%2Froyale-docs%2FWelcome%2FFeatures%2FStrands%2520and%2520Beads.html&data=02%7C01%7Caharui%40adobe.com%7C52c53b5cad9a49035fab08d66d70bf59%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636816728376783526&sdata=cdtZg%2FciWcDo3%2FImhl%2B9gyswCKEub0jOInb2KlXK4r8%3D&reserved=0<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapache.github.io%2Froyale-docs%2FWelcome%2FFeatures%2FStrands%2520and%2520Beads.html&data=02%7C01%7Caharui%40adobe.com%7Ca118aa06c2b14d39266f08d66ffce855%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636819529385657258&sdata=HazsYWz92dzbUs4597v8e3TDhvAxowz68cTQ1bpsOT4%3D&reserved=0>
> [2]
>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fpages%2Fviewpage.action%3FpageId%3D71013028&data=02%7C01%7Caharui%40adobe.com%7C52c53b5cad9a49035fab08d66d70bf59%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636816728376783526&sdata=AI2FjEZeWlRVXecTZ%2FZ8F7TeXIEZPAyVjlszlA6YmNg%3D&reserved=0<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fpages%2Fviewpage.action%3FpageId%3D71013028&data=02%7C01%7Caharui%40adobe.com%7Ca118aa06c2b14d39266f08d66ffce855%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636819529385667272&sdata=ZYLCP50DiWrCNMnA8ckzwzVX03tYCO%2FGpXLDmW7Jumg%3D&reserved=0>
> [3]
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FFLEX%2FCreating%2BComponents&data=02%7C01%7Caharui%40adobe.com%7C52c53b5cad9a49035fab08d66d70bf59%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636816728376783526&sdata=SVuCT0wfYvQ%2F6vfZDV0pprDk8wpgjtnLRjIAw6MPkpM%3D&reserved=0<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FFLEX%2FCreating%2BComponents&data=02%7C01%7Caharui%40adobe.com%7Ca118aa06c2b14d39266f08d66ffce855%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636819529385667272&sdata=kla2Vr0bu3pqqcXcahsE1Kqwk1xHNWRO5yc6ix1S%2Flk%3D&reserved=0>
>
> --
> Andrew Wetmore
>
>
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcottage14.blogspot.com%2F&data=02%7C01%7Caharui%40adobe.com%7C52c53b5cad9a49035fab08d66d70bf59%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636816728376783526&sdata=KVRtgQGcLFXBZY6M5WbxGwdiBbCHKPq5pYKyZ%2F4g2p4%3D&reserved=0<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcottage14.blogspot.com%2F&data=02%7C01%7Caharui%40adobe.com%7Ca118aa06c2b14d39266f08d66ffce855%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636819529385677277&sdata=M7J6zDiwGoQwrpGC6LDD49mT5unP8VJYJ7JucWTF80Y%3D&reserved=0>
>
>
>
--
Carlos Rovira
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C52c53b5cad9a49035fab08d66d70bf59%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636816728376783526&sdata=U9HgYB6mBE5bDOOmNgjUlkUFd8X6%2FCKqQY%2FbKM0pMvo%3D&reserved=0<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ca118aa06c2b14d39266f08d66ffce855%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636819529385677277&sdata=fIKeSy1DbgXY5JTTzFu5j1CL4eoRfSNdw2BAzxaDHE0%3D&reserved=0>
--
Andrew Wetmore
http://cottage14.blogspot.com/<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcottage14.blogspot.com%2F&data=02%7C01%7Caharui%40adobe.com%7Ca118aa06c2b14d39266f08d66ffce855%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636819529385687286&sdata=5Sj7Z9CvD%2BEB4PoyCeTFxF0GR6i8pOqPzarMgERqozI%3D&reserved=0>
Re: User docs entry for strands and beads
Posted by Andrew Wetmore <co...@gmail.com>.
Hi, gang, and Happy New Year.
@Alex Harui <ah...@adobe.com> thank you for your thoughts and pointers. I
have an immediate question related to the ASDoc material: you say "I added
a few ASDoc tags like @toplevel and @viewbead to some of the ASDoc and
there is a cheap checkbox filter for it." No matter where I am in the ASDoc
project, if I check that checkbox I get a blank display with an unending
"Loading..." message. What is supposed to happen?
On Sat, Dec 29, 2018 at 12:34 PM Alex Harui <ah...@adobe.com.invalid>
wrote:
> Hi,
>
> Specifically, the "delete removeBead" change would consist of:
>
> 1) making the strand's array public
> 2) removing removeBead from IStrand and UIBase and HTMLElementWrapper (and
> other places)
> 3) adding an org.apache.royale.utils.removeBead function.
>
> Because, you are correct that someone is going to want to remove a bead at
> some point, but we shouldn't weigh down every app with "just-in-case" code
> and the API surface should discourage "un-recommended" practices. It
> should be an extremely rare occurrence to remove a bead.
>
> On a related note, I checked the other day and HelloWorld is now over
> 80K. It was once 29K. That's how much "just-in-case" code we might have
> added. At some point we need to go back and look at what was in the 51K of
> code we added and make sure it really has to be there. Refactoring many of
> our utils classes into single-purpose functions may help. Your latest
> change to UIUtils won't affect HelloWorld but will affect anyone else who
> uses UIUtils. We need to break up UIUtils into separate functions so that
> convenience functions don't add weight to apps that don't use those
> functions. Volunteers to make those changes are welcome. In Flex,
> HelloWorld was 133K, we are dangerously approaching that number and we
> should hopefully not have to be even close to it if we are handling PAYG
> correctly.
>
> My 2 cents,
> -Alex
>
> On 12/29/18, 1:33 AM, "Carlos Rovira" <ca...@apache.org> wrote:
>
> Hi Alex,
>
> very valuable info as always.
>
> +1 to make "getBeadByType" return latest bead added and to keep
> removeBead
> API as we have today.
>
> I found that problem and although I understand your point and reasons
> on
> what you explain, we must understand the reality that many few users
> will
> be such advanced to know exactly that we want them to use Royale in
> that
> concrete way, so some people will try to add beads of the same type,
> and I
> think that we as a framework should be as flexible as possible to allow
> this kind of things
>
>
>
> El sáb., 29 dic. 2018 a las 8:55, Alex Harui (<aharui@adobe.com.invalid
> >)
> escribió:
>
> > Answers/Opinions inline
> >
> > On 12/28/18, 5:07 AM, "Andrew Wetmore" <co...@gmail.com> wrote:
> >
> > Hi, all:
> >
> > I am working on the user doc page for strands and beads [1].
> This is
> > intended for application developers using Royale; there is
> unfinished
> > material available for developers working on Royale itself in
> the wiki
> > [2],
> > [3].
> >
> > From the app developer point of view, I want to answer these
> questions:
> >
> > 1. There are three ways of adding beads to a component: baked in
> using
> > <js:beads>, through CSS, and dynamically using addBead(). Which
> method
> > is
> > best to use for what purposes?
> >
> > CSS sets up loosely-coupled defaults. Almost all (probably all)
> Royale
> > components that are strands pick up default beads from CSS. CSS
> allows
> > setting default beads for one or more instances of a component in a
> single
> > CSS Selector, just like CSS lets you set values on one or more
> > HTMLElements. But if our SWCs specify a certain bead as a default,
> and the
> > app dev's CSS specifies a different one, it should be possible for
> certain
> > CSS tools to optimize away the original default bead so it isn't
> linked
> > into the output.
> >
> > <js:beads> is the MXML way of calling addBead(). It allows the
> developer
> > to override the defaults bead from CSS for a single instance. But
> now that
> > bead is not loosely coupled, so if someone later subclasses the
> class that
> > used js:beads or addBead, and specify a different bead, both the
> original
> > and the new bead will be in the output. It isn't that much
> different from
> > specifying the "style" property on an HTMLElement in HTML. Js:Beads
> and
> > addBead overrides the underlying CSS.
> >
> >
> >
> > 1a. I can see from the wiki clear examples for two methods of
> adding
> > beads.
> > Can someone point to an example using CSS to add a bead to a
> component?
> >
> > Almost every SWC has a defaults.css file in src/main/resources that
> > specify the default beads. Several examples have MXML files that
> override
> > the defaults in CSS. Search the mxml files for "ClassReference"
> >
> >
> > 2. Is the order of beads on a strand significant?
> >
> > Yes. That’s one reason I proposed "strands and beads" instead of
> "peas
> > and porridge" or some other analogy. In real life the physical
> beads you
> > put on a strand totally change the look of the necklace or
> bracelet. That
> > can be the case here as well. I don't think there are any examples
> where
> > order causes a significant difference that doesn't result in a thrown
> > exception from a null pointer, but if you don't specify order, you
> can get
> > indeterminate results which we definitely don't want. Others have
> pointed
> > out the common issues (model first, then view, or making sure event
> > listeners fire in the right order. Sadly, I just looked and noted
> that
> > getBeadByType is probably written incorrectly. It should probably
> return
> > the last bead added so you can override other beads if needed.
> Right now,
> > first-in-wins. I'm not sure we want that. But in theory, nobody
> should
> > ever add more than one bead of the same type to the strand. The
> ways of
> > overriding the defaults should prevent the need for late overriding
> of
> > beads.
> >
> >
> > 3. How much should I worry about bead cleanup when a bead is no
> longer
> > actively used? I presume this would relate to dynamically-added
> beads,
> > not
> > the <js:beads> or CSS ones.
> >
> > I've been tempted to delete the removeBead API. Beads should never
> be
> > removed. We are compositing beads to form a component instead of
> > subclassing base classes. Both build up functionality and should
> never
> > "delete" it. It might mask or block "base-class" functionality, but
> you
> > can't remove code from a base class, and theoretically, beads should
> never
> > be removed either.
> >
> >
> > 4. Where do I find the existing beads? Is there a curated list
> for each
> > release of Royale? How do I know which ones would be useful for
> a text
> > entry field, a list, a button?
> >
> > I added a few ASDoc tags like @toplevel and @viewbead to some of the
> ASDoc
> > and there is a cheap checkbox filter for it. More asdoc tags need
> to be
> > added and you are encouraged to come up with other ASDoc tags and
> > references to other components. That's one reason why ASDoc is a
> Royale
> > app, so we can add client-side logic to provide more sophisticated
> > filtering someday that makes use of ASDoc tags.
> >
> > Thanks for working on it,
> > -Alex
> >
> >
> > Thanks!
> >
> > a
> >
> >
> > [1]
> >
> >
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapache.github.io%2Froyale-docs%2FWelcome%2FFeatures%2FStrands%2520and%2520Beads.html&data=02%7C01%7Caharui%40adobe.com%7C52c53b5cad9a49035fab08d66d70bf59%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636816728376783526&sdata=cdtZg%2FciWcDo3%2FImhl%2B9gyswCKEub0jOInb2KlXK4r8%3D&reserved=0
> > [2]
> >
> >
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fpages%2Fviewpage.action%3FpageId%3D71013028&data=02%7C01%7Caharui%40adobe.com%7C52c53b5cad9a49035fab08d66d70bf59%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636816728376783526&sdata=AI2FjEZeWlRVXecTZ%2FZ8F7TeXIEZPAyVjlszlA6YmNg%3D&reserved=0
> > [3]
> >
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FFLEX%2FCreating%2BComponents&data=02%7C01%7Caharui%40adobe.com%7C52c53b5cad9a49035fab08d66d70bf59%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636816728376783526&sdata=SVuCT0wfYvQ%2F6vfZDV0pprDk8wpgjtnLRjIAw6MPkpM%3D&reserved=0
> >
> > --
> > Andrew Wetmore
> >
> >
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcottage14.blogspot.com%2F&data=02%7C01%7Caharui%40adobe.com%7C52c53b5cad9a49035fab08d66d70bf59%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636816728376783526&sdata=KVRtgQGcLFXBZY6M5WbxGwdiBbCHKPq5pYKyZ%2F4g2p4%3D&reserved=0
> >
> >
> >
>
> --
> Carlos Rovira
>
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C52c53b5cad9a49035fab08d66d70bf59%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636816728376783526&sdata=U9HgYB6mBE5bDOOmNgjUlkUFd8X6%2FCKqQY%2FbKM0pMvo%3D&reserved=0
>
>
>
--
Andrew Wetmore
http://cottage14.blogspot.com/
Re: User docs entry for strands and beads
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Hi,
Specifically, the "delete removeBead" change would consist of:
1) making the strand's array public
2) removing removeBead from IStrand and UIBase and HTMLElementWrapper (and other places)
3) adding an org.apache.royale.utils.removeBead function.
Because, you are correct that someone is going to want to remove a bead at some point, but we shouldn't weigh down every app with "just-in-case" code and the API surface should discourage "un-recommended" practices. It should be an extremely rare occurrence to remove a bead.
On a related note, I checked the other day and HelloWorld is now over 80K. It was once 29K. That's how much "just-in-case" code we might have added. At some point we need to go back and look at what was in the 51K of code we added and make sure it really has to be there. Refactoring many of our utils classes into single-purpose functions may help. Your latest change to UIUtils won't affect HelloWorld but will affect anyone else who uses UIUtils. We need to break up UIUtils into separate functions so that convenience functions don't add weight to apps that don't use those functions. Volunteers to make those changes are welcome. In Flex, HelloWorld was 133K, we are dangerously approaching that number and we should hopefully not have to be even close to it if we are handling PAYG correctly.
My 2 cents,
-Alex
On 12/29/18, 1:33 AM, "Carlos Rovira" <ca...@apache.org> wrote:
Hi Alex,
very valuable info as always.
+1 to make "getBeadByType" return latest bead added and to keep removeBead
API as we have today.
I found that problem and although I understand your point and reasons on
what you explain, we must understand the reality that many few users will
be such advanced to know exactly that we want them to use Royale in that
concrete way, so some people will try to add beads of the same type, and I
think that we as a framework should be as flexible as possible to allow
this kind of things
El sáb., 29 dic. 2018 a las 8:55, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> Answers/Opinions inline
>
> On 12/28/18, 5:07 AM, "Andrew Wetmore" <co...@gmail.com> wrote:
>
> Hi, all:
>
> I am working on the user doc page for strands and beads [1]. This is
> intended for application developers using Royale; there is unfinished
> material available for developers working on Royale itself in the wiki
> [2],
> [3].
>
> From the app developer point of view, I want to answer these questions:
>
> 1. There are three ways of adding beads to a component: baked in using
> <js:beads>, through CSS, and dynamically using addBead(). Which method
> is
> best to use for what purposes?
>
> CSS sets up loosely-coupled defaults. Almost all (probably all) Royale
> components that are strands pick up default beads from CSS. CSS allows
> setting default beads for one or more instances of a component in a single
> CSS Selector, just like CSS lets you set values on one or more
> HTMLElements. But if our SWCs specify a certain bead as a default, and the
> app dev's CSS specifies a different one, it should be possible for certain
> CSS tools to optimize away the original default bead so it isn't linked
> into the output.
>
> <js:beads> is the MXML way of calling addBead(). It allows the developer
> to override the defaults bead from CSS for a single instance. But now that
> bead is not loosely coupled, so if someone later subclasses the class that
> used js:beads or addBead, and specify a different bead, both the original
> and the new bead will be in the output. It isn't that much different from
> specifying the "style" property on an HTMLElement in HTML. Js:Beads and
> addBead overrides the underlying CSS.
>
>
>
> 1a. I can see from the wiki clear examples for two methods of adding
> beads.
> Can someone point to an example using CSS to add a bead to a component?
>
> Almost every SWC has a defaults.css file in src/main/resources that
> specify the default beads. Several examples have MXML files that override
> the defaults in CSS. Search the mxml files for "ClassReference"
>
>
> 2. Is the order of beads on a strand significant?
>
> Yes. That’s one reason I proposed "strands and beads" instead of "peas
> and porridge" or some other analogy. In real life the physical beads you
> put on a strand totally change the look of the necklace or bracelet. That
> can be the case here as well. I don't think there are any examples where
> order causes a significant difference that doesn't result in a thrown
> exception from a null pointer, but if you don't specify order, you can get
> indeterminate results which we definitely don't want. Others have pointed
> out the common issues (model first, then view, or making sure event
> listeners fire in the right order. Sadly, I just looked and noted that
> getBeadByType is probably written incorrectly. It should probably return
> the last bead added so you can override other beads if needed. Right now,
> first-in-wins. I'm not sure we want that. But in theory, nobody should
> ever add more than one bead of the same type to the strand. The ways of
> overriding the defaults should prevent the need for late overriding of
> beads.
>
>
> 3. How much should I worry about bead cleanup when a bead is no longer
> actively used? I presume this would relate to dynamically-added beads,
> not
> the <js:beads> or CSS ones.
>
> I've been tempted to delete the removeBead API. Beads should never be
> removed. We are compositing beads to form a component instead of
> subclassing base classes. Both build up functionality and should never
> "delete" it. It might mask or block "base-class" functionality, but you
> can't remove code from a base class, and theoretically, beads should never
> be removed either.
>
>
> 4. Where do I find the existing beads? Is there a curated list for each
> release of Royale? How do I know which ones would be useful for a text
> entry field, a list, a button?
>
> I added a few ASDoc tags like @toplevel and @viewbead to some of the ASDoc
> and there is a cheap checkbox filter for it. More asdoc tags need to be
> added and you are encouraged to come up with other ASDoc tags and
> references to other components. That's one reason why ASDoc is a Royale
> app, so we can add client-side logic to provide more sophisticated
> filtering someday that makes use of ASDoc tags.
>
> Thanks for working on it,
> -Alex
>
>
> Thanks!
>
> a
>
>
> [1]
>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapache.github.io%2Froyale-docs%2FWelcome%2FFeatures%2FStrands%2520and%2520Beads.html&data=02%7C01%7Caharui%40adobe.com%7C52c53b5cad9a49035fab08d66d70bf59%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636816728376783526&sdata=cdtZg%2FciWcDo3%2FImhl%2B9gyswCKEub0jOInb2KlXK4r8%3D&reserved=0
> [2]
>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fpages%2Fviewpage.action%3FpageId%3D71013028&data=02%7C01%7Caharui%40adobe.com%7C52c53b5cad9a49035fab08d66d70bf59%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636816728376783526&sdata=AI2FjEZeWlRVXecTZ%2FZ8F7TeXIEZPAyVjlszlA6YmNg%3D&reserved=0
> [3]
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FFLEX%2FCreating%2BComponents&data=02%7C01%7Caharui%40adobe.com%7C52c53b5cad9a49035fab08d66d70bf59%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636816728376783526&sdata=SVuCT0wfYvQ%2F6vfZDV0pprDk8wpgjtnLRjIAw6MPkpM%3D&reserved=0
>
> --
> Andrew Wetmore
>
>
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcottage14.blogspot.com%2F&data=02%7C01%7Caharui%40adobe.com%7C52c53b5cad9a49035fab08d66d70bf59%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636816728376783526&sdata=KVRtgQGcLFXBZY6M5WbxGwdiBbCHKPq5pYKyZ%2F4g2p4%3D&reserved=0
>
>
>
--
Carlos Rovira
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C52c53b5cad9a49035fab08d66d70bf59%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636816728376783526&sdata=U9HgYB6mBE5bDOOmNgjUlkUFd8X6%2FCKqQY%2FbKM0pMvo%3D&reserved=0
Re: User docs entry for strands and beads
Posted by Carlos Rovira <ca...@apache.org>.
Hi Alex,
very valuable info as always.
+1 to make "getBeadByType" return latest bead added and to keep removeBead
API as we have today.
I found that problem and although I understand your point and reasons on
what you explain, we must understand the reality that many few users will
be such advanced to know exactly that we want them to use Royale in that
concrete way, so some people will try to add beads of the same type, and I
think that we as a framework should be as flexible as possible to allow
this kind of things
El sáb., 29 dic. 2018 a las 8:55, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> Answers/Opinions inline
>
> On 12/28/18, 5:07 AM, "Andrew Wetmore" <co...@gmail.com> wrote:
>
> Hi, all:
>
> I am working on the user doc page for strands and beads [1]. This is
> intended for application developers using Royale; there is unfinished
> material available for developers working on Royale itself in the wiki
> [2],
> [3].
>
> From the app developer point of view, I want to answer these questions:
>
> 1. There are three ways of adding beads to a component: baked in using
> <js:beads>, through CSS, and dynamically using addBead(). Which method
> is
> best to use for what purposes?
>
> CSS sets up loosely-coupled defaults. Almost all (probably all) Royale
> components that are strands pick up default beads from CSS. CSS allows
> setting default beads for one or more instances of a component in a single
> CSS Selector, just like CSS lets you set values on one or more
> HTMLElements. But if our SWCs specify a certain bead as a default, and the
> app dev's CSS specifies a different one, it should be possible for certain
> CSS tools to optimize away the original default bead so it isn't linked
> into the output.
>
> <js:beads> is the MXML way of calling addBead(). It allows the developer
> to override the defaults bead from CSS for a single instance. But now that
> bead is not loosely coupled, so if someone later subclasses the class that
> used js:beads or addBead, and specify a different bead, both the original
> and the new bead will be in the output. It isn't that much different from
> specifying the "style" property on an HTMLElement in HTML. Js:Beads and
> addBead overrides the underlying CSS.
>
>
>
> 1a. I can see from the wiki clear examples for two methods of adding
> beads.
> Can someone point to an example using CSS to add a bead to a component?
>
> Almost every SWC has a defaults.css file in src/main/resources that
> specify the default beads. Several examples have MXML files that override
> the defaults in CSS. Search the mxml files for "ClassReference"
>
>
> 2. Is the order of beads on a strand significant?
>
> Yes. That’s one reason I proposed "strands and beads" instead of "peas
> and porridge" or some other analogy. In real life the physical beads you
> put on a strand totally change the look of the necklace or bracelet. That
> can be the case here as well. I don't think there are any examples where
> order causes a significant difference that doesn't result in a thrown
> exception from a null pointer, but if you don't specify order, you can get
> indeterminate results which we definitely don't want. Others have pointed
> out the common issues (model first, then view, or making sure event
> listeners fire in the right order. Sadly, I just looked and noted that
> getBeadByType is probably written incorrectly. It should probably return
> the last bead added so you can override other beads if needed. Right now,
> first-in-wins. I'm not sure we want that. But in theory, nobody should
> ever add more than one bead of the same type to the strand. The ways of
> overriding the defaults should prevent the need for late overriding of
> beads.
>
>
> 3. How much should I worry about bead cleanup when a bead is no longer
> actively used? I presume this would relate to dynamically-added beads,
> not
> the <js:beads> or CSS ones.
>
> I've been tempted to delete the removeBead API. Beads should never be
> removed. We are compositing beads to form a component instead of
> subclassing base classes. Both build up functionality and should never
> "delete" it. It might mask or block "base-class" functionality, but you
> can't remove code from a base class, and theoretically, beads should never
> be removed either.
>
>
> 4. Where do I find the existing beads? Is there a curated list for each
> release of Royale? How do I know which ones would be useful for a text
> entry field, a list, a button?
>
> I added a few ASDoc tags like @toplevel and @viewbead to some of the ASDoc
> and there is a cheap checkbox filter for it. More asdoc tags need to be
> added and you are encouraged to come up with other ASDoc tags and
> references to other components. That's one reason why ASDoc is a Royale
> app, so we can add client-side logic to provide more sophisticated
> filtering someday that makes use of ASDoc tags.
>
> Thanks for working on it,
> -Alex
>
>
> Thanks!
>
> a
>
>
> [1]
>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapache.github.io%2Froyale-docs%2FWelcome%2FFeatures%2FStrands%2520and%2520Beads.html&data=02%7C01%7Caharui%40adobe.com%7Ca37e020467d645bd3c7908d66cc56537%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636815992401552214&sdata=WFGjvg63MiYqXlEyTGEuv1qZmcL4QtzK2kLpUAb9dKo%3D&reserved=0
> [2]
>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fpages%2Fviewpage.action%3FpageId%3D71013028&data=02%7C01%7Caharui%40adobe.com%7Ca37e020467d645bd3c7908d66cc56537%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636815992401552214&sdata=Hk2HnbcNNP9c4QcB4hrzcrB%2B2cfkGAqonMmUU2ZT94c%3D&reserved=0
> [3]
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FFLEX%2FCreating%2BComponents&data=02%7C01%7Caharui%40adobe.com%7Ca37e020467d645bd3c7908d66cc56537%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636815992401552214&sdata=xzE80YHfuAwsCtLu7vDajGevY8clorB4tGs7TH0MPm8%3D&reserved=0
>
> --
> Andrew Wetmore
>
>
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcottage14.blogspot.com%2F&data=02%7C01%7Caharui%40adobe.com%7Ca37e020467d645bd3c7908d66cc56537%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636815992401552214&sdata=5cw5KLEvWoyN427Sa8pZ0WgQW36P17P0RH%2BT2bl230k%3D&reserved=0
>
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: User docs entry for strands and beads
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Answers/Opinions inline
On 12/28/18, 5:07 AM, "Andrew Wetmore" <co...@gmail.com> wrote:
Hi, all:
I am working on the user doc page for strands and beads [1]. This is
intended for application developers using Royale; there is unfinished
material available for developers working on Royale itself in the wiki [2],
[3].
From the app developer point of view, I want to answer these questions:
1. There are three ways of adding beads to a component: baked in using
<js:beads>, through CSS, and dynamically using addBead(). Which method is
best to use for what purposes?
CSS sets up loosely-coupled defaults. Almost all (probably all) Royale components that are strands pick up default beads from CSS. CSS allows setting default beads for one or more instances of a component in a single CSS Selector, just like CSS lets you set values on one or more HTMLElements. But if our SWCs specify a certain bead as a default, and the app dev's CSS specifies a different one, it should be possible for certain CSS tools to optimize away the original default bead so it isn't linked into the output.
<js:beads> is the MXML way of calling addBead(). It allows the developer to override the defaults bead from CSS for a single instance. But now that bead is not loosely coupled, so if someone later subclasses the class that used js:beads or addBead, and specify a different bead, both the original and the new bead will be in the output. It isn't that much different from specifying the "style" property on an HTMLElement in HTML. Js:Beads and addBead overrides the underlying CSS.
1a. I can see from the wiki clear examples for two methods of adding beads.
Can someone point to an example using CSS to add a bead to a component?
Almost every SWC has a defaults.css file in src/main/resources that specify the default beads. Several examples have MXML files that override the defaults in CSS. Search the mxml files for "ClassReference"
2. Is the order of beads on a strand significant?
Yes. That’s one reason I proposed "strands and beads" instead of "peas and porridge" or some other analogy. In real life the physical beads you put on a strand totally change the look of the necklace or bracelet. That can be the case here as well. I don't think there are any examples where order causes a significant difference that doesn't result in a thrown exception from a null pointer, but if you don't specify order, you can get indeterminate results which we definitely don't want. Others have pointed out the common issues (model first, then view, or making sure event listeners fire in the right order. Sadly, I just looked and noted that getBeadByType is probably written incorrectly. It should probably return the last bead added so you can override other beads if needed. Right now, first-in-wins. I'm not sure we want that. But in theory, nobody should ever add more than one bead of the same type to the strand. The ways of overriding the defaults should prevent the need for late overriding of beads.
3. How much should I worry about bead cleanup when a bead is no longer
actively used? I presume this would relate to dynamically-added beads, not
the <js:beads> or CSS ones.
I've been tempted to delete the removeBead API. Beads should never be removed. We are compositing beads to form a component instead of subclassing base classes. Both build up functionality and should never "delete" it. It might mask or block "base-class" functionality, but you can't remove code from a base class, and theoretically, beads should never be removed either.
4. Where do I find the existing beads? Is there a curated list for each
release of Royale? How do I know which ones would be useful for a text
entry field, a list, a button?
I added a few ASDoc tags like @toplevel and @viewbead to some of the ASDoc and there is a cheap checkbox filter for it. More asdoc tags need to be added and you are encouraged to come up with other ASDoc tags and references to other components. That's one reason why ASDoc is a Royale app, so we can add client-side logic to provide more sophisticated filtering someday that makes use of ASDoc tags.
Thanks for working on it,
-Alex
Thanks!
a
[1]
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapache.github.io%2Froyale-docs%2FWelcome%2FFeatures%2FStrands%2520and%2520Beads.html&data=02%7C01%7Caharui%40adobe.com%7Ca37e020467d645bd3c7908d66cc56537%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636815992401552214&sdata=WFGjvg63MiYqXlEyTGEuv1qZmcL4QtzK2kLpUAb9dKo%3D&reserved=0
[2]
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fpages%2Fviewpage.action%3FpageId%3D71013028&data=02%7C01%7Caharui%40adobe.com%7Ca37e020467d645bd3c7908d66cc56537%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636815992401552214&sdata=Hk2HnbcNNP9c4QcB4hrzcrB%2B2cfkGAqonMmUU2ZT94c%3D&reserved=0
[3] https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FFLEX%2FCreating%2BComponents&data=02%7C01%7Caharui%40adobe.com%7Ca37e020467d645bd3c7908d66cc56537%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636815992401552214&sdata=xzE80YHfuAwsCtLu7vDajGevY8clorB4tGs7TH0MPm8%3D&reserved=0
--
Andrew Wetmore
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcottage14.blogspot.com%2F&data=02%7C01%7Caharui%40adobe.com%7Ca37e020467d645bd3c7908d66cc56537%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636815992401552214&sdata=5cw5KLEvWoyN427Sa8pZ0WgQW36P17P0RH%2BT2bl230k%3D&reserved=0
RE: User docs entry for strands and beads
Posted by Yishay Weiss <yi...@hotmail.com>.
>> 2. Is the order of beads on a strand significant?
>good question, maybe this should be answered by other.
>I think usually not if each bead is an isolated funcionality. But maybe you
>can think on some bead that requiere other beads, in that case, I suppose
>the bead that require the other one should ensure to get its own code.
I can think of 2 reasons why order matters:
1. A bead requires a different bead (e.g. view requires model)
2. Event handler priorities. Usually, the beads added first are the first to listen to events dispatched from the strand.
Re: User docs entry for strands and beads
Posted by Carlos Rovira <ca...@apache.org>.
Hi Andrew,
El vie., 28 dic. 2018 a las 14:07, Andrew Wetmore (<co...@gmail.com>)
escribió:
>
> 1. There are three ways of adding beads to a component: baked in using
> <js:beads>, through CSS, and dynamically using addBead(). Which method is
> best to use for what purposes?
>
Don't think one is better than other, adding a bead to the array of beads
should be best for users that want a concrete behavior in the current
component instance, so usually this will be done for a "special case".
CSS could be a more generalist behavior so all instance of the same
component will use the same beads.
And addBead is more programatic approach (while the first one is more
declarative through MXML).
Of course, all of this is dependent on the use case since you can create an
MXML with an instance that uses concrete beads in Js:beads, and then reuse
it over all application, and in the same way, you can create a concrete css
selector that define a bead and use it in just one instance of the
component.
> 1a. I can see from the wiki clear examples for two methods of adding beads.
> Can someone point to an example using CSS to add a bead to a component?
>
For example item renderers in Jewel:
https://royale.apache.org/tourdejewel/#
in List example search for : className="iconListItemRenderer"
then check CSS:
https://github.com/apache/royale-asjs/blob/develop/examples/royale/TourDeJewel/src/main/resources/jewel-example-styles.css
and search for :
.iconListItemRenderer
{
IItemRenderer: ClassReference("itemRenderers.IconListItemRenderer");
}
> 2. Is the order of beads on a strand significant?
>
>
good question, maybe this should be answered by other.
I think usually not if each bead is an isolated funcionality. But maybe you
can think on some bead that requiere other beads, in that case, I suppose
the bead that require the other one should ensure to get its own code.
> 3. How much should I worry about bead cleanup when a bead is no longer
> actively used? I presume this would relate to dynamically-added beads, not
> the <js:beads> or CSS ones.
>
don't think you need to remove a bead as a listener. But would like to read
Alex's response and see if removing a UIBase component will loop through
the beads and make a removal before remove the component itself.
>
> 4. Where do I find the existing beads? Is there a curated list for each
> release of Royale?
No, and I think this could be a great addition to documentation. If you
could create this list, I think it will be very valuable. Maybe you could
improve asdocs in each bead that could be needed (not all, but I think some
of the beads doesn't have a minimum doc of what we should expect to do)
> How do I know which ones would be useful for a text
> entry field, a list, a button?
>
In Jewel, the beads are organized in packages and controls. I tried to keep
organized while developing. So for Jewel that should be easy to do that
work. In Basic there's no such organization and all is in the same package.
We talked about do some package organization before 1.0.
Thanks to you to work on this :)
> Thanks!
>
> a
>
>
> [1]
>
> https://apache.github.io/royale-docs/Welcome/Features/Strands%20and%20Beads.html
> [2]
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=71013028
> [3] https://cwiki.apache.org/confluence/display/FLEX/Creating+Components
>
> --
> Andrew Wetmore
>
> http://cottage14.blogspot.com/
>
--
Carlos Rovira
http://about.me/carlosrovira