Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: flex-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of jonbcampos@gmail.com designates
 209.85.214.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <B73F5AA8-6526-42B7-B3DD-AC4CA2F4CFE9@lndgrn.se>
References: 
 <EB6F7A48D477254EAB8F675582F80CD726737C69@DPSBS1.digitalprimates.local>
	<B73F5AA8-6526-42B7-B3DD-AC4CA2F4CFE9@lndgrn.se>
Date: Tue, 10 Apr 2012 16:25:52 -0500
Message-ID: 
 <CAAd0WrZSK-iZ7hF7mvMH_9FV0eNq4FnBj09Bb=jU0D_cykYb5w@mail.gmail.com>
Subject: Re: Modular code (was: ComboBox Selection (was: combo box))
From: Jonathan Campos <jonbcampos@gmail.com>
To: flex-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=f46d0447a2b574493504bd59c40f

--f46d0447a2b574493504bd59c40f
Content-Type: text/plain; charset=ISO-8859-1

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

--f46d0447a2b574493504bd59c40f--