Changing subject in case people have stopped reading.
I think the question in the subject should be decided before we continue the
package name discussion. After thinking about it more, I really do think that
Jewel should default to using Express beads (which might also mean that we need
to create a few more Express beads). My reasoning is that we've already
heard from users that a "high-configuration" component set like Basic was a
pain to work with, which is why started creating a "low-configuration" set with
Express. It doesn't make sense to go back to "high-configuration" in Jewel.
Jewel should be the one component set folks use to get to know Royale and it
should have both a good default look-and-feel (which Carlos has done) but also
be "low-configuration". Jewel has enough CSS and complex Views that we
shouldn't be worried about trying to make Jewel lighter by not using Express
beads. Folks can optimize by swapping out beads as needed.
Thoughts?
-Alex
On 5/22/18, 3:59 PM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
<carlos.rov...@gmail.com on behalf of carlosrov...@apache.org> wrote:
Hi Alex,
I think we are saying the same in essence.
I want to reuse beads. So lets take "TextPrompt" bead and have only one in
all Royale (always that make the same of course), think that is in a
library called "Foundation" that depends from Core but is not core. Seems
"Foundation" is a name less confusing than Basic. All UI sets, link this
foundation library and take what they want from it. Normally all UI sets
will borrow "TextPrompt" bead. The same with the pieces in you DataGrid
example.
In the other hand, UI sets has its own implementation of "Button" (and the
rest of components), and the CSS that wires all the beads used in that
concrete Button, and the rest of controls and components in that UI Set. I
think we all said that we want to reuse, but we don't want to use a CSS
from other UI set. So this concrete implementations of controls and
components and the CSS should go in each library, and so we'll have Basic,
Jewel, MDL, CreateJS,...
Have sense to have Basic CSS and controls in Foundation? for me clearly no,
since Jewel will not use it at all. Will use Foundation classes, (in your
example DataGrid pieces to reuse almost all of it). Will use the CSS that
wires all beads used in Basic, clearly not. So the code that goes in each
UI set library is clearly not reusable at all, and we don't want the
compiler to take extra time processing the CSS that wires all beads from a
UI Set that will not be used right?.
The opposite will be "lets take all ui set implementations (Basic, Jewel,
MDL, CreateJS,...) and mix altogether in a unique Foundation library with
all control and components implementations and all the CSSs that wires the
beads". Make this sense? For me clearly not. Moreover, in this case why
have libraries for Network, Binding, Collections...? Hope this extreme case
showcased makes more sense to explain.
If we want to reuse lets go and reuse, I'm all for it, but we shouldn't
have the CSS that binds all together for a UI Set that will not be used
since doesn't support anything in the normal use. And all of this even if
we get rid of the current bugs that brings lots of things to the final bake.
I think a library or SWC is in essence a reusable piece, but we not link
all existing SWC for all projects since we know we'll not using *all*
available SWCs we have, and since we don't want the compiler process all
CSSs in all that libraries all the time, since is time consuming. For this
reason we create the current SWC libraries, since if people will not use
Network, they normally don't link, if they use Basic, but not Jewel, MDL,
and CreateJS, those are not linked.
Finaly, if I'll not use Basic...then I don't want to be obligated to link
Basic (basic controls, and CSS) but I want to link Foundation since are the
reusable pieces in all Royale UI Sets.
Hope this explanation make more sense.
Thanks
Carlos
2018-05-22 23:43 GMT+02:00 Alex Harui <aha...@adobe.com.invalid>:
> Hi Carlos,
>
> I guess I don't understand why separating beads from TLCs is better. How
> will that make things better for users or other component set developers?
> That would effectively double the number of SWCs and each TLC SWC will
need
> its bead SWC. That doesn't sound like a good thing to me, but if that's
> what other folks want to do, that's fine with me.
>
> I was just looking through the classes in Jewel. It looks like JeweL
> doesn't have a DataGrid yet.. When it does, I would think you will want
to
> use the DataGridModel from Express as it handles both Arrays and
> ICollectionViews. We will probably create a similar model bead that takes
> both ICollectionViews and Arrays for Lists and put that in Express as
> well. Then we might decide that is better for Jewel to use that model
> instead. Or maybe we'll decide to create a JewelExpress set that has
those
> more general models that don't require as much configuration. Anyway, I
> hope you agree that at some point, these more general models will be used
> by Express and some flavor of Jewel. I don't think this general model
> should go in Core, or Basic (or some new category called Foundation). And
> at that point, Jewel or JewelExpress is going to re-use that code in
> Express.
>
> Component sets are encouraged to re-use existing code from any other SWC
> since I think we've agreed that re-use is important.
>
> My 2 cents,
> -Alex
>
> On 5/21/18, 11:16 AM, "carlos.rov...@gmail.com on behalf of Carlos
> Rovira" <carlos.rov...@gmail.com on behalf of carlosrov...@apache.org>
> wrote:
>
> Hi Alex
>
> what do you think about separating the part in Basic that is
> inherently the
> same as in Jewel (Button, CheckBox, TextInput, List, ...) along with
> CSS
> that wire the beads for Basic UI set, and left the fundamental
building
> blocks as something that is not Core but can be reused by Basic and
> Jewel
> (Let's call this "Foundation" Lib, I even like this name for this
> library).
>
> I mean that having "Foundation" lib and "Basic" lib, will be more
> clear,
> since we can expect what is in Basic will be never reused to build
> other UI
> Sets (MDL, or others can still hang from there or if someone wants to
> take
> the time refactor it).
>
> Foundation will not have any CSS wiring beads. We can return classes
> from
> Core to Foundation.
>
> Basic will have its own CSS wiring beads, the same for Jewel. Both
will
> requiere Core and Foundation.
>
> I assume this will make all of us happy.
>
> We can as well do the package name changes to ensure consistency along
> all
> code and libraries.
>
> Let me know what do you think
>
> thanks
>
> Carlos
>
>
> 2018-05-21 19:38 GMT+02:00 Alex Harui <aha...@adobe.com.invalid>:
>
> > I understand this isn't the latest post on this thread, but it is
the
> > easiest one for me to reply to:
> >
> > First, the hopefully easy things we can agree on:
> > -I have no objection to dropping "Bead" off of bead class names
> > -I have no objection to moving all views into a view subfolder as
> long as
> > nobody else is concerned about the size and performance issues.
> > -I have no objection to moving classes in Basic that are
> > org.apache.royale.html to org.apache.royale.basic.
> > -I have no objection to doing a massive rename and long as it isn't
> me
> > doing the work.
> > -Whatever is in Core and Basic now or before Carlos's started moving
> > things around is not perfect.
> >
> > Now for the less easy. Regarding Core vs Basic, I see it this way:
> Basic
> > is the simplest implementation of the constructs/concepts in
> Royale. It is
> > intended to be extended and enhanced by other component sets via our
> PAYG
> > principles. Core is intended to identify the constructs/concepts
> and their
> > fundamental contracts.
> >
> > Think of it this way: When you open any class in Royale, you will
> want to
> > know what kind of class it is. It is a TLC, a Bead? And what kind
> of TLC
> > or Bead? Is it View, Model, Controller? An ItemRenderer? These
> are the
> > categories of classes we had, even in Flex. I've probably left out
> a few
> > categories. It is the interfaces for these categories that go in
> Core.
> > And maybe some classes we think are universal implementations of
> those
> > categories. And some beads that are component set agnostic, like
> > BrowserResizeHandler, although we could move those to another SWC
> and say
> > that Core should not have any MXML components except maybe State.
> >
> > After any rename/refactor we decide on, Basic should still have some
> > interfaces because those interfaces describe the contract required
> for the
> > simplest implementation. I get that it can be a fine line between
> > "fundamental" and "simplest", but where many classes that were in
> Basic get
> > away from "fundamental" is mainly around Containers. The way we
> handle
> > Containers in Basic really seems like an opinion instead of a
> universal,
> > "everyone must implement Containers this way" sort of thing. So it
> does
> > not seem right that lots of Container-related things were moved to
> Core.
> >
> > I thought we had agreement on the Terminology and Concepts thread
> that
> > re-usable pieces would be organized into multiple SWCs like Apache
> or AS3
> > Commons. Any component set designer gets to choose what SWCs to
> borrow
> > from. The emulation SWCs may borrow from Express because they want
> to
> > re-use multi-purpose beads and aren't interested in the smallest,
> fastest,
> > implementation. Assuming we fix any issues with accidentally
> dragging in
> > classes that aren't used, if you can re-use code from some other
> group of
> > classes in another SWC, just do it. But do it because you "want
to".
> > There is no "need to". The implementers should "want" to re-use
> code when
> > possible.
> >
> > In the end, many component sets will re-use Basic beads. Maybe even
> > transitively because they re-use Express which re-uses Basic. That
> should
> > be ok. That doesn't make it Core. It just that lots of component
> sets
> > will start from simple implementations and add more complex
> functionality.
> > The goal is to minimize code size and maximize performance by
> re-using
> > code. And as I thought we had agreed upon in Terminology and
> Concepts, we
> > should not be afraid to re-use code. We are asking our users to do
> exactly
> > the same. We must create testing infrastructure and have review
> periods
> > and other processes so we don't break downstream component sets or
> our
> > users applications.
> >
> > One related tidbit: IMO, the way folks will know what beads work
> with
> > what components will be done by identifying what interfaces the
beads
> > implement, but also, I expected that we would use ASDoc as well. If
> you
> > rummage through the source, you'll see that I annotated a few
> classes with
> > @viewbead and @toplevel. We could add more. And because our ASDoc
> is an
> > app, we can then apply smarter filtering that help folks narrow down
> what
> > their choices are, similar to many of the online shopping filters I
> see.
> >
> > My 2 cents,
> > -Alex
> >
> >
> > On 5/21/18, 3:53 AM, "Harbs" <harbs.li...@gmail.com> wrote:
> >
> > Thank you for this.
> >
> > There’s two groups of files that were changed: Interfaces and
and
> > Classes.
> >
> > In general, I would be more inclined to move interfaces than
> classes,
> > but there are some things to consider:
> >
> > 1. There are still 17 interfaces in Basic. If the 5 that were
> moved
> > belong in Core, what about the remaining 17?
> > 2. I don’t think we’ve come to an agreement on what belongs in
> Core
> > and what belongs in Basic.
> > 3. I’d like to some to an agreement on a package name pattern.
> What
> > defines something belonging to a “core” path as opposed to an “html”
> path?
> > Some classes are in supportClasses and some had that removed from
> the path.
> > What’s the logic? etc.
> > 4. How should different pieces (such as different bead types) be
> > defined in paths? (I don’t think we’re completely consistent today.)
> >
> > I think we are coming to a conclusion on the CSS issues that
> Jewel
> > brought up. I think the CSS problems can be solved no matter whether
> we
> > move things between packages and no matter wether we change package
> paths.
> > I think the question on reorganization needs to be discussed on its
> own
> > right. Do you agree with that?
> >
> > First organization of packages:
> > To me, there are two primary questions related to Core vs.
Basic:
> > 1. What is the defining criteria for something to belong in Core
> as
> > opposed to Basic?
> > 2. Is there an issue with one component set (i.e. Jewel) to rely
> on
> > another (i.e. Basic).
> >
> > To be clear: I do believe that there is likely some
> reorganization
> > appropriate, but I’m not clear on exactly what and how.
> >
> > Depending on the answers to these questions, we can have a
> number of
> > different courses of action. We might keep things very similar to
> how they
> > are. We might move things from Basic to Core. We might split Basic
> into two
> > packages. Other options?
> >
> > Regarding package paths: I don’t think there’s a single “right”
> answer
> > to that, but we do need to agree on a pattern that we all stick to.
> > Currently (even before any refactor) package paths feel like many
are
> > haphazard, and I often have difficulty guessing what the path is for
> a
> > specific class. I also sometimes have difficulty guessing which
> package a
> > specific class belongs to.
> >
> > These are the high-level questions I have.
> >
> > Please allow me to focus on question #2. I find it easiest to
> discuss
> > concrete examples, so I’m taking TextPrompt, but it’s just an
> example.
> > Basic has a TextPromptBead. Jewel has TextPrompt. The code of the
two
> > classes are identical. I’m assuming TextPrompt was copied because
> > TextPromptBead does not belong in Core (something I agree with), and
> you
> > did not want Jewel to have a dependency on Basic. So my question is
> > (assuming CSS and classes not used are not copied), what is wrong
> with
> > Jewel using the TextPromptBead in Basic? To me the advantage of
> using the
> > Basic bead is that there’s no code duplication and that helps from a
> > development perspective (i.e. only a single place to fix bugs) and
> from a
> > perspective of code size in the resulting application (in case both
> classes
> > are used somewhere).
> >
> > Harbs
> >
> > > On May 21, 2018, at 11:29 AM, Carlos Rovira <
> carlosrov...@apache.org>
> > wrote:
> > >
> > > Hi,
> > >
> > > as we talked I take the time to make a list of package name
> changes.
> > > Finally 20 classes were changed from package.
> > > Here's the list from 16c0dcd643974fe708fd67a3774ea6e35e879811
> (in
> > red the
> > > changes to better following)
> > >
> > > frameworks/projects/Core/src/main/royale/org/apache/royale/
> > core/MXMLBeadView.as
> > >
> > > frameworks/projects/Basic/src/main/royale/org/apache/royale/
> html
> > > /MXMLBeadView.as
> > > frameworks/projects/Core/src/main/royale/org/apache/royale/
> > core/beads/views/ContainerView.as
> > > frameworks/projects/Basic/src/
> > main/royale/org/apache/royale/html/beads/ContainerView.as.
> > > (1)
> > > frameworks/projects/Core/src/main/royale/org/apache/royale/
> > core/beads/views/DataContainerView.as
> > > frameworks/projects/Basic/src/
> main/royale/org/apache/royale/
> > html
> > > /beads/DataContainerView.as
> > > frameworks/projects/Core/src/main/royale/org/apache/royale/
> > core/beads/GroupView.as
> > >
> > > frameworks/projects/Basic/src/main/royale/org/apache/royale/
> html
> > > /beads/GroupView.as
> > > frameworks/projects/Core/src/main/royale/org/apache/royale/
> > core/beads/IBackgroundBead.as
> > > frameworks/projects/Basic/src/
> > main/royale/org/apache/royale/
> > > html/beads/IBackgroundBead.as
> > > frameworks/projects/Core/src/main/royale/org/apache/royale/
> > core/beads/IBorderBead.as
> > >
> > > frameworks/projects/Basic/src/main/royale/org/apache/royale/
> html
> > > /beads/IBorderBead.as
> > > frameworks/projects/Core/src/main/royale/org/apache/royale/
> > core/beads/IDropDownListView.as
> > > frameworks/projects/Basic/src/
> > main/royale/org/apache/royale/html
> > > /beads/IDropDownListView.as
> > > frameworks/projects/Core/src/main/royale/org/apache/royale/
> > core/IListView.as
> > >
> > > frameworks/projects/Basic/src/main/royale/org/apache/royale/
> > html/beads/IListView.as.
> > > (2)
> > > frameworks/projects/Core/src/main/royale/org/apache/royale/
> > core/beads/ITextFieldView.as
> > > frameworks/projects/Basic/src/
> > main/royale/org/apache/royale/
> > > html/beads/ITextFieldView.as (2)
> > > frameworks/projects/Core/src/main/royale/org/apache/royale/
> > core/beads/TextFieldViewBase.as
> > > frameworks/projects/Basic/src/
> > main/royale/org/apache/royale/html/beads/TextFieldViewBase.as
> > > (2)
> > > frameworks/projects/Core/src/main/royale/org/apache/royale/
> > core/beads/layouts/LayoutChangeNotifier.as
> > > frameworks/projects/Basic/src/main/royale/org/apache/royale/
> html
> > > /beads/layouts/LayoutChangeNotifier.as
> > > frameworks/projects/Core/src/main/royale/org/apache/royale/
> > core/beads/models/ArraySelectionModel.as
> > > frameworks/projects/Basic/src/main/royale/org/apache/royale/
> html
> > > /beads/models/ArraySelectionModel.as
> > > frameworks/projects/Core/src/main/royale/org/apache/royale/
> > core/beads/models/ViewportModel.as
> > > frameworks/projects/Basic/src/
> main/royale/org/apache/royale/
> > html
> > > /beads/models/ViewportModel.as
> > > frameworks/projects/Core/src/main/royale/org/apache/royale/
> > core/supportClasses/Border.as
> > > frameworks/projects/Basic/src/
> > main/royale/org/apache/royale/
> > > html/supportClasses/Border.as
> > > frameworks/projects/Core/src/main/royale/org/apache/royale/
> > core/supportClasses/ContainerContentArea.as
> > > frameworks/projects/Basic/src/main/royale/org/apache/royale/
> > html/supportClasses/ContainerContentArea.as.
> > > (2)
> > > frameworks/projects/Core/src/main/royale/org/apache/royale/
> > core/supportClasses/DataGroup.as
> > > frameworks/projects/Basic/src/
> > main/royale/org/apache/royale/html/supportClasses/DataGroup.as
> > >
> > > frameworks/projects/Core/src/main/royale/org/apache/royale/
> > core/DataItemRenderer.as
> > >
> > > frameworks/projects/Basic/src/main/royale/org/apache/royale/
> html/
> > > supportClasses/DataItemRenderer.as (3)
> > > frameworks/projects/Core/src/main/royale/org/apache/royale/
> > core/MXMLItemRenderer.as
> > >
> > > frameworks/projects/Basic/src/main/royale/org/apache/royale/
> html/
> > > supportClasses/MXMLItemRenderer.as
> > > frameworks/projects/Core/src/main/royale/org/apache/royale/
> > core/UIItemRendererBase.as
> > >
> > > frameworks/projects/Basic/src/main/royale/org/apache/royale/
> html/
> > > supportClasses/UIItemRendererBase.as
> > > frameworks/projects/Core/src/main/royale/org/apache/royale/
> > core/supportClasses/Viewport.as
> > > frameworks/projects/Basic/src/
> > main/royale/org/apache/royale/html
> > > /supportClasses/Viewport.as
> > >
> > > Some comments:
> > >
> > > (1) "views" should follow the same package structure we have
> with
> > other
> > > beads 8"models", "controllers"...) to be consistent.
> > > (2) should go to "core/beads/views" as well
> > > (3) item renderers that should normaly be used by final users
> could
> > go some
> > > kind of "itemRenderers" package, while base item redeemer
> classes
> > could go
> > > again to supportClasses.
> > >
> > > As Harbs said, if we agree in the change of packages, we
> should do
> > this
> > > well and perform some other changes that make all more
> consistent
> > though
> > > libraries.
> > >
> > > Thanks
> > >
> > > Carlos
> > >
> > >
> > >
> > >
> > > 2018-05-17 11:16 GMT+02:00 Harbs <harbs.li...@gmail.com>:
> > >
> > >> Definitely a plan.
> > >>
> > >> My guess is that if we agree on changing package paths, there
> will
> > likely
> > >> be other classes that should be considered.
> > >>
> > >> My preference would be to have this discussion after we
> finish the
> > project
> > >> refactor discussion because I think it’s going to be related
> to the
> > outcome
> > >> of that.
> > >>
> > >> Either way, I don’t think discussion should hold up the 0.9.3
> > release.
> > >> We’re already past due for a release. We want to “release
> early and
> > release
> > >> often”… ;-)
> > >>
> > >> Thanks,
> > >> Harbs
> > >>
> > >>> On May 17, 2018, at 12:07 PM, Carlos Rovira <
> > carlosrov...@apache.org>
> > >> wrote:
> > >>>
> > >>> Ok,
> > >>>
> > >>> what if:
> > >>>
> > >>> * I take the time to generate a list of classes with package
> name
> > changes
> > >>> * Make a thread with the list to expose it
> > >>> * Let's see from there if people can live with it (We'll
call
> > people to
> > >>> express about this changes and could see if are or not
> dramatic to
> > them)
> > >>>
> > >>> Sounds this like a plan?
> > >>>
> > >>> Thanks
> > >>>
> > >>>
> > >>>
> > >>> 2018-05-17 10:58 GMT+02:00 Harbs <harbs.li...@gmail.com>:
> > >>>
> > >>>> Sure. Same here.
> > >>>>
> > >>>> But things are much more stable now. As we move closer to
> “1.0”,
> > I think
> > >>>> we should be more careful about breaking changes and
> documenting
> > them
> > >> when
> > >>>> we decide they are necessary.
> > >>>>
> > >>>> As far as these specific changes go: We haven’t even come
> to a
> > >> conclusion
> > >>>> on what (if any) package names should change yet, and
> including
> > those
> > >>>> changes in a release is premature. If we do change package
> names,
> > I’m of
> > >>>> the opinion that they should be decided on and all happen
> at once
> > to
> > >>>> minimize impact on end-users.
> > >>>>
> > >>>> Does that help clarify things?
> > >>>>
> > >>>> Thanks,
> > >>>> Harbs
> > >>>>
> > >>>>> On May 17, 2018, at 11:49 AM, Justin Mclean <
> > jus...@classsoftware.com>
> > >>>> wrote:
> > >>>>>
> > >>>>> Hi,
> > >>>>>
> > >>>>>> We are at the point where people are using Royale in
> > production. While
> > >>>> we can make breaking changes if they are warranted, they
> should
> > be kept
> > >> to
> > >>>> an absolute minimum and be carefully considered and well
> > documented if
> > >> we
> > >>>> do.
> > >>>>>
> > >>>>> There has been many previous breaking changes that broke
> the
> > >> application
> > >>>> I was working on and some more major than this and cost me
> a lot
> > of
> > >> time to
> > >>>> fix. Until you make it version 1.0 I think people will
> expect
> > that some
> > >>>> things may break with a new version. So why should this be
> an
> > exception
> > >> to
> > >>>> what has happened before? Saying that however, what would
> be good
> > to
> > >> see is
> > >>>> to provide guidance to what users need to change so their
> app
> > works with
> > >>>> any changes / backward compatibility issues.
> > >>>>>
> > >>>>> Thanks,
> > >>>>> Justin
> > >>>>
> > >>>>
> > >>>
> > >>>
> > >>> --
> > >>> Carlos Rovira
> > >>> https://na01.safelinks.protection.outlook.com/?url=
> > http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%
> 40adobe.com%
> > 7Cbbb82e5ac5e34921bfe908d5bf09044e%7Cfa7b1b5a7b34438794aed2c178de
> > cee1%7C0%7C0%7C636624967805497091&sdata=
> bdXVzZzjutIIwP9lWwAjosfP3JsQDt
> > rkTp%2FcrETCLE4%3D&reserved=0
> > >>
> > >>
> > >
> > >
> > > --
> > > Carlos Rovira
> > > https://na01.safelinks.protection.outlook.com/?url=
> > http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%
> 40adobe.com%
> > 7Cbbb82e5ac5e34921bfe908d5bf09044e%7Cfa7b1b5a7b34438794aed2c178de
> > cee1%7C0%7C0%7C636624967805497091&sdata=
> bdXVzZzjutIIwP9lWwAjosfP3JsQDt
> > rkTp%2FcrETCLE4%3D&reserved=0
> >
> >
> >
> >
>
>
> --
> Carlos Rovira
> https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%
> 7C7fb72469866647e4264108d5bf46fcb5%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C636625234021648344&sdata=VP%2BrBk%2FGm2iYVLGKZBb5W%
> 2FSAPKFpD763hkpcXbTjPkA%3D&reserved=0
>
>
>
--
Carlos Rovira
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C956be5c671194d88bc2d08d5c037a842%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636626267659136456&sdata=Uakuu2OcNqkYSLgx1FOqFUC75funWJ1gZgN5pEPjzs4%3D&reserved=0
