You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Erik Lundgren <er...@lndgrn.se> on 2012/04/10 23:05:20 UTC
Modular code (was: ComboBox Selection (was: combo box))
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
Re: Modular code (was: ComboBox Selection (was: combo box))
Posted by Bogdan DINU <fl...@gmail.com>.
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 <jo...@gmail.com>wrote:
> Someone call Ben! (Reflex)
> On Apr 10, 2012 4:06 PM, "Erik Lundgren" <er...@lndgrn.se> 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
Re: Modular code (was: ComboBox Selection (was: combo box))
Posted by Jonathan Campos <jo...@gmail.com>.
Someone call Ben! (Reflex)
On Apr 10, 2012 4:06 PM, "Erik Lundgren" <er...@lndgrn.se> 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