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 <aha...@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" <aha...@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 <cottag...@gmail.com> > Date: Tuesday, January 1, 2019 at 7:22 AM > To: "dev@royale.apache.org" <dev@royale.apache.org>, Alex Harui < > aha...@adobe.com> > Subject: Re: User docs entry for strands and beads > > Hi, gang, and Happy New Year. > > @Alex Harui<mailto:aha...@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 <aha...@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" <carlosrov...@apache.org<mailto: > carlosrov...@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 > (<aha...@adobe.com.invalid>) > escribió: > > > Answers/Opinions inline > > > > On 12/28/18, 5:07 AM, "Andrew Wetmore" <cottag...@gmail.com > <mailto:cottag...@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/
