Hi Erik, this was discussed in the past here on the list - you can check it here<http://markmail.org/search/?q=flex%20incubator#query:flex%20incubator%20order%3Adate-backward+page:1+mid:imps4t4ettncvdsy+state:facets>. Frédéric Thomas have started to put this into practice (for UIComponent) and the result is on this repository<https://github.com/doublefx/UIComponentBehaviors>. We haven't call them traits or servants, but the basic idea is similar and not stupid.
Kind regards, Bogdan On Wed, Apr 11, 2012 at 12:25 AM, Jonathan Campos <[email protected]>wrote: > Someone call Ben! (Reflex) > On Apr 10, 2012 4:06 PM, "Erik Lundgren" <[email protected]> wrote: > > > > > 10 apr 2012 kl. 21.08 skrev Michael A. Labriola: > > > > > It could certainly be added, but I would like you to consider thinking > > about it a different way. Rather than adding more heft to the base > > component, we could add another object that interacted with the ComboBox > to > > facilitate that selection for you. This could be done a number of > different > > ways. > > > > This may be a stupid idea. > > > > But what if we did Flex development in multiple steps. > > > > 1. Compose components > > 2. Compile components > > 3. Compose views > > 4. Compile application > > > > Eg: > > > > A custom window-like component could start with a factory-file: > > > > <Container> > > <traits> > > <Draggable/> > > <Physical/> > > <Closable/> > > <Resizable/> > > <Bar/> > > </traits> > > </Container> > > > > After the component compilation I would have a component where the > > "Draggable" trait may have added logic requiring my component skin to > > declare a "MoveArea" skin part. The "Physical" trait may have added > > properties like "friction" or "density". The "Resizable" trait may > require > > a "CloseButton" skinpart etc. > > > > At the framework level we could have a "class pyramid architecture" vs a > > "class tree structure". > > At the application level we would have "pay-as-you-go" components. > > > > The intermediary component compilation could reduce performance hits of > > modular code. > > > > I'm sure there are many problems with this approach, but ... ideas are > > better out than in ... right! :) > > > > /Erik > -- http://www.badu.ro
