You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@royale.apache.org by Harbs <ha...@gmail.com> on 2017/12/07 09:39:20 UTC
Names and Packages (was Re: MXMLDataInterpreter)
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 <ha...@gmail.com> 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 SingleSelectionBead?
> 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 <harbs.lists@gmail.com <ma...@gmail.com>> wrote:
>>
>> It is.
>>
>> Possibly it could use a better name?
>>
>>> On Dec 6, 2017, at 9:16 PM, Alex Harui <aharui@adobe.com.INVALID <ma...@adobe.com.INVALID>> wrote:
>>>
>>> There probably shouldn't have been a need for SingleSelectionContainerBead unless it is an aggregation of SingleSelectionModelBead and SingleSelectionControllerBead.
>>
>
Re: Names and Packages (was Re: MXMLDataInterpreter)
Posted by Piotr Zarzycki <pi...@gmail.com>.
If that granularity from point one is going to happen, let's it happen
before the first release. My thought is that we should get used to users
for some structures which do not fluctuate too much.
Thanks, Piotr
2017-12-07 20:04 GMT+01:00 Alex Harui <ah...@adobe.com.invalid>:
> I first want to acknowledge Piotr's concern about shuffling things around,
> but on the other hand, if we think we have a lot of beads now, I hope
> after several years we have 10x or 100x as many, so having good
> organization will help people find things.
>
> I think we also need to consider that some beads are "aggregates". They
> are more than one bead combined together for some reason (ease of use,
> inlining code, etc).
>
> Are there other buckets we need to consider?
>
> I'm on the fence about whether we need to do this renaming. If we do it,
> do we want to get it done before the first Royale release?
>
> -Alex
>
> On 12/7/17, 9:31 AM, "Harbs" <ha...@gmail.com> wrote:
>
> >Behavior would be something like: Password bead, SingleSelecttion,
> >Disabled, etc.
> >Appearance would be things like: DataGridLines, DisabledAlpha, Border,
> >Background, etc.
> >
> >> On Dec 7, 2017, at 7:16 PM, Alex Harui <ah...@adobe.com.INVALID>
> wrote:
> >>
> >> What's a "behavior" and "appearance"?
> >>
> >> -Alex
> >>
> >> On 12/7/17, 1:39 AM, "Harbs" <harbs.lists@gmail.com
> >><ma...@gmail.com>> 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 <ha...@gmail.com> 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
> >>>> SingleSelectionBead?
> >>>> 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 <harbs.lists@gmail.com
> >>>>> <mailto:harbs.lists@gmail.com <ma...@gmail.com>>>
> wrote:
> >>>>>
> >>>>> It is.
> >>>>>
> >>>>> Possibly it could use a better name?
> >>>>>
> >>>>>> On Dec 6, 2017, at 9:16 PM, Alex Harui <aharui@adobe.com.INVALID
> >>>>>><ma...@adobe.com.INVALID>
> >>>>>> <mailto:aharui@adobe.com.INVALID
> >>>>>><ma...@adobe.com.INVALID>>> wrote:
> >>>>>>
> >>>>>> There probably shouldn't have been a need for
> >>>>>> SingleSelectionContainerBead unless it is an aggregation of
> >>>>>> SingleSelectionModelBead and SingleSelectionControllerBead.
> >
>
>
--
Piotr Zarzycki
Patreon: *https://www.patreon.com/piotrzarzycki
<https://www.patreon.com/piotrzarzycki>*
Re: Names and Packages (was Re: MXMLDataInterpreter)
Posted by Alex Harui <ah...@adobe.com.INVALID>.
I first want to acknowledge Piotr's concern about shuffling things around,
but on the other hand, if we think we have a lot of beads now, I hope
after several years we have 10x or 100x as many, so having good
organization will help people find things.
I think we also need to consider that some beads are "aggregates". They
are more than one bead combined together for some reason (ease of use,
inlining code, etc).
Are there other buckets we need to consider?
I'm on the fence about whether we need to do this renaming. If we do it,
do we want to get it done before the first Royale release?
-Alex
On 12/7/17, 9:31 AM, "Harbs" <ha...@gmail.com> wrote:
>Behavior would be something like: Password bead, SingleSelecttion,
>Disabled, etc.
>Appearance would be things like: DataGridLines, DisabledAlpha, Border,
>Background, etc.
>
>> On Dec 7, 2017, at 7:16 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>
>> What's a "behavior" and "appearance"?
>>
>> -Alex
>>
>> On 12/7/17, 1:39 AM, "Harbs" <harbs.lists@gmail.com
>><ma...@gmail.com>> 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 <ha...@gmail.com> 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
>>>> SingleSelectionBead?
>>>> 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 <harbs.lists@gmail.com
>>>>> <mailto:harbs.lists@gmail.com <ma...@gmail.com>>> wrote:
>>>>>
>>>>> It is.
>>>>>
>>>>> Possibly it could use a better name?
>>>>>
>>>>>> On Dec 6, 2017, at 9:16 PM, Alex Harui <aharui@adobe.com.INVALID
>>>>>><ma...@adobe.com.INVALID>
>>>>>> <mailto:aharui@adobe.com.INVALID
>>>>>><ma...@adobe.com.INVALID>>> wrote:
>>>>>>
>>>>>> There probably shouldn't have been a need for
>>>>>> SingleSelectionContainerBead unless it is an aggregation of
>>>>>> SingleSelectionModelBead and SingleSelectionControllerBead.
>
Re: Names and Packages (was Re: MXMLDataInterpreter)
Posted by Harbs <ha...@gmail.com>.
Behavior would be something like: Password bead, SingleSelecttion, Disabled, etc.
Appearance would be things like: DataGridLines, DisabledAlpha, Border, Background, etc.
> On Dec 7, 2017, at 7:16 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> What's a "behavior" and "appearance"?
>
> -Alex
>
> On 12/7/17, 1:39 AM, "Harbs" <harbs.lists@gmail.com <ma...@gmail.com>> 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 <ha...@gmail.com> 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
>>> SingleSelectionBead?
>>> 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 <harbs.lists@gmail.com
>>>> <mailto:harbs.lists@gmail.com <ma...@gmail.com>>> wrote:
>>>>
>>>> It is.
>>>>
>>>> Possibly it could use a better name?
>>>>
>>>>> On Dec 6, 2017, at 9:16 PM, Alex Harui <aharui@adobe.com.INVALID <ma...@adobe.com.INVALID>
>>>>> <mailto:aharui@adobe.com.INVALID <ma...@adobe.com.INVALID>>> wrote:
>>>>>
>>>>> There probably shouldn't have been a need for
>>>>> SingleSelectionContainerBead unless it is an aggregation of
>>>>> SingleSelectionModelBead and SingleSelectionControllerBead.
Re: Names and Packages (was Re: MXMLDataInterpreter)
Posted by Alex Harui <ah...@adobe.com.INVALID>.
What's a "behavior" and "appearance"?
-Alex
On 12/7/17, 1:39 AM, "Harbs" <ha...@gmail.com> 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 <ha...@gmail.com> 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
>>SingleSelectionBead?
>> 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 <harbs.lists@gmail.com
>>><ma...@gmail.com>> wrote:
>>>
>>> It is.
>>>
>>> Possibly it could use a better name?
>>>
>>>> On Dec 6, 2017, at 9:16 PM, Alex Harui <aharui@adobe.com.INVALID
>>>><ma...@adobe.com.INVALID>> wrote:
>>>>
>>>> There probably shouldn't have been a need for
>>>>SingleSelectionContainerBead unless it is an aggregation of
>>>>SingleSelectionModelBead and SingleSelectionControllerBead.
>>>
>>
>
Re: Names and Packages (was Re: MXMLDataInterpreter)
Posted by Piotr Zarzycki <pi...@gmail.com>.
Hi Harbs, Peter,
I agree with point 1, 2 and 3, but I would leave as is all components which
we have currently in basic in place. Another change of API and
restructuring ? Let's make current components better and give users feeling
of stability with another moving from one place to another we cannot give
anyone that feeling.
Thanks, Piotr
2017-12-07 16:20 GMT+01:00 Peter Ent <pe...@adobe.com.invalid>:
> 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.
>
> ‹peter
>
> On 12/7/17, 4:39 AM, "Harbs" <ha...@gmail.com> 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 <ha...@gmail.com> 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
> >>SingleSelectionBead?
> >> 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 <harbs.lists@gmail.com
> >>><ma...@gmail.com>> wrote:
> >>>
> >>> It is.
> >>>
> >>> Possibly it could use a better name?
> >>>
> >>>> On Dec 6, 2017, at 9:16 PM, Alex Harui <aharui@adobe.com.INVALID
> >>>><ma...@adobe.com.INVALID>> wrote:
> >>>>
> >>>> There probably shouldn't have been a need for
> >>>>SingleSelectionContainerBead unless it is an aggregation of
> >>>>SingleSelectionModelBead and SingleSelectionControllerBead.
> >>>
> >>
> >
>
>
--
Piotr Zarzycki
Patreon: *https://www.patreon.com/piotrzarzycki
<https://www.patreon.com/piotrzarzycki>*
Re: Names and Packages (was Re: MXMLDataInterpreter)
Posted by Peter Ent <pe...@adobe.com.INVALID>.
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.
‹peter
On 12/7/17, 4:39 AM, "Harbs" <ha...@gmail.com> 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 <ha...@gmail.com> 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
>>SingleSelectionBead?
>> 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 <harbs.lists@gmail.com
>>><ma...@gmail.com>> wrote:
>>>
>>> It is.
>>>
>>> Possibly it could use a better name?
>>>
>>>> On Dec 6, 2017, at 9:16 PM, Alex Harui <aharui@adobe.com.INVALID
>>>><ma...@adobe.com.INVALID>> wrote:
>>>>
>>>> There probably shouldn't have been a need for
>>>>SingleSelectionContainerBead unless it is an aggregation of
>>>>SingleSelectionModelBead and SingleSelectionControllerBead.
>>>
>>
>