Re: [flexcoders] Re: Best Practice for Subclassed UIComponent and DataProvider
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
[flexcoders] Re: Best Practice for Subclassed UIComponent and DataProvider
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, 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, 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, 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, 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, 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
[flexcoders] Re: Best Practice for Subclassed UIComponent and DataProvider
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, 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, 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, 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:
[flexcoders] Re: Best Practice for Subclassed UIComponent and DataProvider
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, 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, 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, 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, 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
[flexcoders] Re: Best Practice for Subclassed UIComponent and DataProvider
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, 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, 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
[flexcoders] Re: Best Practice for Subclassed UIComponent and DataProvider
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
[flexcoders] Re: Best Practice for Subclassed UIComponent and DataProvider
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
[flexcoders] Re: Best Practice for Subclassed UIComponent and DataProvider
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
