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%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636624967805497091&sdata=bdXVzZzjutIIwP9lWwAjosfP3JsQDtrkTp%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%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636624967805497091&sdata=bdXVzZzjutIIwP9lWwAjosfP3JsQDtrkTp%2FcrETCLE4%3D&reserved=0
