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" <harbs.li...@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 <harbs.li...@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.li...@gmail.com >>><mailto:harbs.li...@gmail.com>> wrote: >>> >>> It is. >>> >>> Possibly it could use a better name? >>> >>>> On Dec 6, 2017, at 9:16 PM, Alex Harui <aha...@adobe.com.INVALID >>>><mailto:aha...@adobe.com.INVALID>> wrote: >>>> >>>> There probably shouldn't have been a need for >>>>SingleSelectionContainerBead unless it is an aggregation of >>>>SingleSelectionModelBead and SingleSelectionControllerBead. >>> >> >
