Use the –keep-generated-actionscript MXMLC options and see the pile of code it
generates.
On 8/29/11 7:31 AM, "hanzo55" <shawn.a.hol...@gmail.com> wrote:
I actually did a bit of research on the COLLECTION_CHANGE event as well as the
setter prior to posting here, and neither seemed to apply, since my initial
tests of working with a plain ComboBox were completely fine:
<mx:ComboBox dataProvider="{model.facilities}" />
caused the combobox to be populated correctly. What I was really looking for
was what was going on under-the-hood for the code above when it is processed
during compilation into AS3. Does this MXML mean that there is assignment going
on in the constructor? (current results seem to point to 'no'), or does the
Flex compiler look at binding related attributes (surrounded by curly braces)
and translate those into a series of calls to BindingUtils.bindProperty()
I suppose I could have just downloaded the flex source and looked. :\
--- In flexcoders@yahoogroups.com <mailto:flexcoders%40yahoogroups.com> ,
"turbo_vb" <TimHoff@...> wrote:
>
> Back to your problem. If you're not seeing the combo box's dataProvider
> populate or update, then it's a binding problem. Good idea to try the
> BindingUtils, but it's easier to fix the binding events in the model. If
> you're using a getter / setter in the model, for the facilities collection,
> make sure that the binding event is dispatched in the setter. If you're not
> seeing the collection update, when existing items have been changed
> elsewhere, then listen for the COLLECTION_CHANGE event on the facilities
> collection, and in the listener function, manually dispatch the collection's
> binding event (same as the one in the setter). If this doesn't work, look
> further upstream; in the service, delegate or controller. You'll find the
> short.
>
> -TH
>
> --- In flexcoders@yahoogroups.com <mailto:flexcoders%40yahoogroups.com> ,
> "turbo_vb" <TimHoff@> wrote:
> >
> > You have the right idea; to encapsulate the dataProvider, validation and
> > change event handler. But, instead of putting them inside the control,
> > wrap all of that into a common facilities model, that gets used anywhere
> > it's needed in the application. I stopped using Cairngorm a long time ago,
> > but hopefully the newest version supports dependency injection; so you can
> > just inject a reference to the facilities model where needed, and hook it
> > up to the combo box. That would be best practice. But, at the end of the
> > day, the goal is to make it work, so...
> >
> > -TH
> >
> > --- In flexcoders@yahoogroups.com <mailto:flexcoders%40yahoogroups.com> ,
> > "hanzo55" <shawn.a.holmes@> wrote:
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > I very much appreciate the help! Any chance I can take to improve the
> > > design would be greatly beneficial, from a maintenance standpoint.
> > >
> > > My feeling originally was if I have two comboboxes that are in entirely
> > > different parts of the app, but that will always be populated by the same
> > > data provider, always have the same validation and always utilize the
> > > same change function (while being different from other comboboxes in the
> > > site), it made sense to encapsulate the dataprovider/validation/change
> > > events into the box itself so it could be added to a view without having
> > > to specify all of the various attributes a combobox needs--since they are
> > > not changing.
> > >
> > > Initially, it seemed a bit pointless to write:
> > >
> > > <components:FacilityComboBox dataProvider="{model.facilities}" />
> > >
> > > everywhere I implemented the Facility ComboBox since everywhere the
> > > Facility ComboBox is implemented...the dataProvider is *going* to be
> > > model.facilities and will never change.
> > >
> > > If you think that there is a good example somewhere that demonstrates a
> > > better design for this type of class hierachy, please point me to it and
> > > I'll have a look. As the subject states, I'm very much looking for the
> > > best practice here.
> > >
> > > --- In flexcoders@yahoogroups.com <mailto:flexcoders%40yahoogroups.com> ,
> > > "turbo_vb" <TimHoff@> wrote:
> > > >
> > > > 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 <mailto:flexcoders%40yahoogroups.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
> > > > > <mailto:flexcoders%40yahoogroups.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
> > > > > > <mailto:flexcoders%40yahoogroups.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
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
--
Alex Harui
Flex SDK Team
Adobe System, Inc.
http://blogs.adobe.com/aharui
