royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Piotr Zarzycki <piotrzarzyck...@gmail.com>
Subject Re: Names and Packages (was Re: MXMLDataInterpreter)
Date Thu, 07 Dec 2017 15:30:11 GMT
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 <pent@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" <harbs.lists@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.lists@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>> wrote:
> >>>
> >>> It is.
> >>>
> >>> Possibly it could use a better name?
> >>>
> >>>> On Dec 6, 2017, at 9:16 PM, Alex Harui <aharui@adobe.com.INVALID
> >>>><mailto:aharui@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>*

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message