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 <[email protected]>: > 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" <[email protected]> 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 <[email protected]> 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 <[email protected] > >>><mailto:[email protected]>> wrote: > >>> > >>> It is. > >>> > >>> Possibly it could use a better name? > >>> > >>>> On Dec 6, 2017, at 9:16 PM, Alex Harui <[email protected] > >>>><mailto:[email protected]>> 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>*
