royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Ent <>
Subject Re: Names and Packages (was Re: MXMLDataInterpreter)
Date Thu, 07 Dec 2017 15:20:22 GMT
I also wonder if List, DataGrid, Tree shouldn't be moved out of "basic"
and into "advanced" - they along with their supporting beads. From the
work I've been doing with handling "itemAdded" event vs
"dataProviderChanged", it might be easier for customers who want the
expense of a DataGrid to just pay for ArrayList as the default model
rather than trying to maintain Array as an entry point model. Having
Array, which does not offer a uniform access method (eg, getItemAt) means
duplicating code to support it. Then if ArrayList supported IDataModel (a
more generic name) instead of IArrayList, an app writer's more complex
data source, like a database, could implement IDataModel and be easily
substituted as the dataProvider to the List support beads.

Just a thought.


On 12/7/17, 4:39 AM, "Harbs" <> wrote:

>Related thoughts about names and packages:
>1. I think the bead classes should be organized better. There¹s currently
>controllers, layouts and models packages. There should be views,
>behaviors, appearances, etc.
>2. I¹m not sure that the ³html² package in Basic is the right name.
>³basic² seems much more appropriate to me as it¹s really not HTML
>specific and there¹s no guarantee in the components as to which html
>element is actually used.
>3. It also might be time to move code around in the different swcs.
>³core² in the Basic package might belong in Core rather than Basic. ³svg²
>should probably be moved into an SVG package, etc.
>> On Dec 7, 2017, at 10:13 AM, Harbs <> wrote:
>> I was thinking a bit about naming. A few points to ponder:
>> 1. If anything it should mention Group rather than Container, because
>>anything subclassing GroupBase should work.
>> 2. Maybe mentioning the ³holder² type is just confusing. Maybe
>> 3. This got me thinking about bead names in general:
>> I¹m wondering if bead names should be more explicit about their
>>function? We already have view beads with a suffix of View, controllers
>>with a suffix of Controller, models with a suffix of Model and Layout
>>for layout. What about SingleSelectionBehavior? Some suffixes might be:
>>Behavior, Appearance, Measurement. Basically, I¹m suggesting that the
>>bead names should describe what category they fit into. We can also drop
>>the word ³Bead² from them.
>> Thoughts?
>>> On Dec 6, 2017, at 11:35 PM, Harbs <
>>><>> wrote:
>>> It is.
>>> Possibly it could use a better name?
>>>> On Dec 6, 2017, at 9:16 PM, Alex Harui <
>>>><>> wrote:
>>>> There probably shouldn't have been a need for
>>>>SingleSelectionContainerBead unless it is an aggregation of
>>>>SingleSelectionModelBead and SingleSelectionControllerBead.

View raw message