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>
