Validation can be abstracted just like dataProviders. For a combo box, you
only need to validate the selectedItem; from the view, presentation model, or a
common utility class. Most other stuff happens in itemRenderers; that have a
little more freedom. It may be that you're locked into a structure that was
handed to you, but hardcoding a reference to a singleton model, from which you
set the data provider of a combo box from within the combo box, breaks the
rules. If you're having problems with binding the dataProvider to the model's
property, the binding problem is probably upstream from the combo box. Good
luck Shawn, just trying to help.
-TH
--- In flexcoders@yahoogroups.com, "hanzo55" <shawn.a.holmes@...> wrote:
>
>
>
> There's more to the story in regards to the class design than what's provided
> here; The subclass is actually part of a larger set of classes that share
> common functionality in terms of their validation and change events based on
> the data-providers for a global app.
>
> That common functionality is centralized in their parent class. The
> dataProvider assignment in the constructor is tying those specific ComboBox
> subclasses to a family of service providers that produce an expected set of
> columns. Since those ComboBoxes, with their very specific validation and
> change routines (which are common to each other), apply very tightly to those
> service providers and no others, it made sense to subclass them and
> encapsulate dataProvider assignment, so those ComboBoxes could be used in any
> views that apply to that family of services.
>
> ...if that makes sense.
>
> --- In flexcoders@yahoogroups.com, "turbo_vb" <TimHoff@> wrote:
> >
> > Can't see any good reason to subclass a control in order to hardcode the
> > dataProvider. The idea is to keep the components loosely coupled. Are you
> > having a problem with dataProvider="{model.facilities}"?
> >
> > -TH
> >
> > --- In flexcoders@yahoogroups.com, Alex Harui <aharui@> wrote:
> > >
> > > Binding a visual component to a singleton limits its reuse. So there may
> > > not really a best practice. The minimum code way is probably to assign
> > > the dataProvider in commitProperties instead of the constructor. The
> > > model.facilities might have its final assignment by then.
> > >
> > >
> > > On 8/25/11 9:41 AM, "hanzo55" <shawn.a.holmes@> wrote:
> > >
> > >
> > >
> > >
> > >
> > >
> > > I am working with a project already in place. It uses Cairngorm and is
> > > built on Flex 3.0.2.2113
> > >
> > > A standard ComboBox is implemented in one of the views like so:
> > >
> > > <mx:ComboBox dataProvider="{model.facilities}" id="Facility">
> > >
> > > "model" is a bindable singleton, and one of its properties, "facilities"
> > > is a public ArrayCollection. On initialization, a function runs in the
> > > singleton to populate facilities; it does this by pointing
> > > model.facilities to another ArrayCollection that has been previously
> > > populated, such as:
> > >
> > > model.facilities = model.assigned_facilities;
> > >
> > > This works without issue; when the application starts, the ComboBox is
> > > properly populated with the values pointed to by model.facilities.
> > >
> > > I have decided! to come in and build a subclass of ComboBox in
> > > ActionScript, and rather than pass the dataProvider in, I want to include
> > > the singleton within the ActionScript, and simply do the same assignment
> > > in the constructor. The resulting MXML would look like this:
> > >
> > > <components:FacilityComboBox id="Facility" />
> > >
> > > and the constructor would look like this:
> > >
> > > public function FacilityComboBox()
> > > {
> > > super();
> > > ! BindingUtils.bindProperty(this, "dataProvider", model, "facilities");
> > > }
> > >
> > > My question is: Is this the best practice when subclassing a UIComponent
> > > and wanting to handle the dataProvider assignment internally? The reason
> > > I ask is, I had originally built the constructor like this:
> > >
> > > public function FacilityComboBox()
> > > {
> > > super();
> > > thi! s.dataProperty = model.facilities;
> > > }
> > >
> > > which worked for other subclassed ComboBoxes where the dataProvider *did
> > > not change after initialization*. However, because of how
> > > model.facilities is assigned (to an existing ArrayCollection), no change
> > > was ever detected, and upon launch the application, the ComboBox sat
> > > dormant and never received any values to populate. Changing to the
> > > BindingUtils method solved this problem, but I now fear I'm missing a
> > > much broader concept about dataProvider assignment in pure ActionScript
> > > classes. Is my BindingUtils methodology the one to go with? Or should I
> > > be considering something drastically different?
> > >
> > >
> > >
> > >
> > >
> > > --
> > > Alex Harui
> > > Flex SDK Team
> > > Adobe System, Inc.
> > > http://blogs.adobe.com/aharui
> > >
> >
>
