Nick, thanks, that's just what I was looking for, and apparently tried
to use incorrectly previously.
I think that now on. I'll use this technique for binding to
information that shouldn't be changed during the app lifetime, and
curly braces to pass the binded value from the model to the helper
function for situations where real binding is needed.
My concerns are style related only (hopefully it'll stay that way
during the development of this app) as it's my second day with
Cairngorm and I wish not to currupt my mind just so early:)
Good night for me, and best regards,
Almog Kurtser.
hopefully
--- In flexcoders@yahoogroups.com, "Uber_Nick" <[EMAIL PROTECTED]> wrote:
>
> 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 flexcoders@yahoogroups.com, "mydarkspoon" <mydarkspoon@> 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.
>
