You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by "Michael A. Labriola" <la...@digitalprimates.net> on 2012/04/10 21:08:21 UTC
ComboBox Selection (was: combo box)
>Is there a possibility to add this feature to ComboBox?
Dany,
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 is one way I have implemented it and something I want to discuss here.
It is the idea of adding behaviors to items, so, in my approach, I have something like a ComboBox:
<ComboBox dataProvider="blah">
<behaviors>
<ValueSelectionBehavior id="vsb" dataProvideValueField="someID" selectedValue="{someThingElse.someValue}/>
</behaviors>
</ComboBox>
In this way we have just defined an interface for the Behavior classes and a minimal extension to UIComponent for a property and registration step. However, we have enable people to add a pay as you go approach to adding behavior to components. It's something that has worked well for us and, eventually, I would like us to consider here as it has made extending and adding to Flex without bloating all of the base components much easier.
Mike
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
Modular code (was: ComboBox Selection (was: combo box))
Posted by Erik Lundgren <er...@lndgrn.se>.
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: ComboBox Selection (was: combo box)
Posted by Mick Powell <mi...@veeops.com>.
Hello All,
I haven't spoken yet on this list although I have been receiving mail for a few months. I have been developing Flex applications for a number of years now (professionally), and I have found the pattern that Mike suggests to be something I have used time and again. I would argue that this was the servant pattern : http://en.wikipedia.org/wiki/Servant_%28design_pattern%29 (not a great article) but as Mike says, I can be interested in what I like and I suppose I can also call things what I like too.
Either way, IMHO this pattern is a great way of separating concerns from the base-class while providing both extensibility and flexibility, and I think that something like what Mike suggests would be a great addition to the framework. Reducing bloat has been of a primary concern to me, and I know it has for many other developers, and this "bolt-on" approach fits into that rather nicely.
Of course, this is only if I have actually understood what Mike is positing.
All the best,
Mick
On Apr 10, 2012, at 1:28 PM, Michael A. Labriola wrote:
>> I think you are referring to the decorator pattern. It has pros and cons, as do all architectural decisions. Personally I am more interested in the what/result, not so much in the how/way. But it takes all sorts, right?
>
> Nope. It's not a decorator pattern. Yes this idea does have pros and cons, and you can reserve the right to be interested in anything you like.
>
> Cheers,
> Mike
RE: ComboBox Selection (was: combo box)
Posted by David Coleman <da...@hotmail.com>.
yes, I myself have done this quite often. for instance you have a bunch of objects and you set the selectedValue field to be "foo.id".. then you would expect (or at least you would desire) that setting the selected value to 123 would search for the item in the dataProvider that has the "id" field == 123 and set it as selected item... or set selected item to -1 and the selected item to the emptyItem (the proposal i made, which is valid in the case of working with dto's in this way). These behaviors are common in web forms and even in native applications... I think that it would be beneficial to have them as native behaviors (if they are delicately and correctly implemented).
> Subject: Re: ComboBox Selection (was: combo box)
> From: archemedia@mac.com
> Date: Tue, 10 Apr 2012 21:51:13 +0200
> To: flex-dev@incubator.apache.org
>
> Hi Mike,
>
> The behavior solution would be an acceptable solution. Whether the functionality should be implemented in the base component or higher up is up to the contributors with their level of expertise but the use case of setting a combobox' selected item by an arbitrary value id is very common one I believe, so I'm very much in favour of making it possible.
>
> -Dany
>
>
> Op 10-apr.-2012, om 21:28 heeft Michael A. Labriola het volgende geschreven:
>
> >> I think you are referring to the decorator pattern. It has pros and cons, as do all architectural decisions. Personally I am more interested in the what/result, not so much in the how/way. But it takes all sorts, right?
> >
> > Nope. It's not a decorator pattern. Yes this idea does have pros and cons, and you can reserve the right to be interested in anything you like.
> >
> > Cheers,
> > Mike
>
Re: ComboBox Selection (was: combo box)
Posted by Dany Dhondt <ar...@mac.com>.
Hi Mike,
The behavior solution would be an acceptable solution. Whether the functionality should be implemented in the base component or higher up is up to the contributors with their level of expertise but the use case of setting a combobox' selected item by an arbitrary value id is very common one I believe, so I'm very much in favour of making it possible.
-Dany
Op 10-apr.-2012, om 21:28 heeft Michael A. Labriola het volgende geschreven:
>> I think you are referring to the decorator pattern. It has pros and cons, as do all architectural decisions. Personally I am more interested in the what/result, not so much in the how/way. But it takes all sorts, right?
>
> Nope. It's not a decorator pattern. Yes this idea does have pros and cons, and you can reserve the right to be interested in anything you like.
>
> Cheers,
> Mike
RE: ComboBox Selection (was: combo box)
Posted by "Michael A. Labriola" <la...@digitalprimates.net>.
>I think you are referring to the decorator pattern. It has pros and cons, as do all architectural decisions. Personally I am more interested in the what/result, not so much in the how/way. But it takes all sorts, right?
Nope. It's not a decorator pattern. Yes this idea does have pros and cons, and you can reserve the right to be interested in anything you like.
Cheers,
Mike
Re: ComboBox Selection (was: combo box)
Posted by John Cunliffe <ma...@gmail.com>.
I think you are referring to the decorator pattern. It has pros and cons,
as do all architectural decisions. Personally I am more interested in the
what/result, not so much in the how/way. But it takes all sorts, right?
John
Am 10.04.2012 21:08 schrieb "Michael A. Labriola" <
labriola@digitalprimates.net>:
> >Is there a possibility to add this feature to ComboBox?
>
> Dany,
>
> 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 is one way I have implemented it and something I want to discuss
> here.
>
> It is the idea of adding behaviors to items, so, in my approach, I have
> something like a ComboBox:
>
> <ComboBox dataProvider="blah">
> <behaviors>
> <ValueSelectionBehavior id="vsb"
> dataProvideValueField="someID" selectedValue="{someThingElse.someValue}/>
> </behaviors>
> </ComboBox>
>
> In this way we have just defined an interface for the Behavior classes and
> a minimal extension to UIComponent for a property and registration step.
> However, we have enable people to add a pay as you go approach to adding
> behavior to components. It's something that has worked well for us and,
> eventually, I would like us to consider here as it has made extending and
> adding to Flex without bloating all of the base components much easier.
>
> Mike
>
>