incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Campos <jonbcam...@gmail.com>
Subject Re: Modular code (was: ComboBox Selection (was: combo box))
Date Tue, 10 Apr 2012 21:25:52 GMT
Someone call Ben! (Reflex)
On Apr 10, 2012 4:06 PM, "Erik Lundgren" <erik@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

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