Hi Almog,
I see your concern now. You're right in that the logic for creation
of the view stack should remain in the view code, not the command or
in some other binding.
Here's how we handle that situation. On the component's
creationComplete, we call init():
private function init():void
{
Changewatcher.watch(_model, servicesList, createViewStack)
}
private function createViewStack(event:PropertyChangeEvent):void
{
//do view stack creation logic here
}
This way, your view logic is in one place and built off the model. In
terms of the redundant dispatching of events, it will fire once or
twice on startup will a null value, but after that it should only fire
the one time your property is set. That's how all binding works and
it's nothing to worry about. Are your concerns performance-related,
or more about style/elegance?
-Nick Matelli
Amentra, Inc
--- In [email protected], "mydarkspoon" <[EMAIL PROTECTED]> wrote:
>
> Hi Nick,
> Thanks for the help, the reasons why I'm not satisfied with #5 are
> like that: The tabs naming is one operation that takes place, another
> one is creating a ViewStack object to correspond those tabs.
> Obviously, the view stack Can be built upon setting the TabBar
> dataProvider, however, I think it's not readable beacuse when I open
> an mxml component in search for a specific view control, the viewstack
> in this example, I would look first at the <mx:ViewStack /> tag
> instead, not at the TabBar, which should have nothing to do with the
> ViewStack leaving it to be loosely coupled as much as possible.
> Actually, this brings me the idea which I'll have to implement anyway,
> to bind the ViewStack object's selectedIndex to the model using a
> local helper function to get the selectedIndex, null checking the
> model for the config file, and eventually returning an index.
> This is not perfect but more elegant I think, yet I'd like to adapt
> best practices dealing with such issues so feel about it :)
>
> I almost forgot, my second drawback from the curly braces metjod is
> the dispatching of redundant event, which is the reason that causes
> the null checking to be essential.
>
>
> Thanks and best regards,
>
> Almog Kurtser.
