personally, I leave States to component level 'dynamic Flexi-magik' and use
Viewstacks for major view changes. Viewstacks just seem more appropriate
for major view changes. States I leave to component changes, eg a edit vs
view in a form or something like that. IIRC, States actually are more
com
I think that's a fair point you've made and I can't understand why the
constants are in the model either in the Cairngorm Store.
Seems to me like there should be a Singleton related to the view
holding the list of available views to switch between. But I'm no
Cairngorm expert either :P
justin
x27;s helpful.
Paul
- Original Message -
From: "Justin J. Moses" <[EMAIL PROTECTED]>
To:
Sent: Tuesday, September 02, 2008 12:33 AM
Subject: [flexcoders] Re: Question about Best Practices for Applications
with many views using Cairngorm
> Paul,
>
> If you
Paul,
If you're trying to understand Cairngorm by reading the docs and
going through the Cairngorm Store demo, you'll notice that the views
are toggled via constants in the model:
eg.
if( model.workflowState ==
ShopModelLocator.VIEWING_PRODUCTS_IN_THUMBNAILS )
...
so the various views or d
OK, I see what you're saying. I'm actually fairly new to Cairngorm, so
I'd be interested in what others have to say about this...
Personally, in my app, I assigned modules to user roles, and used the
class name of each module as the name of the that contains it. This
seems like it might still be c
- Original Message -
From: "j301c" <[EMAIL PROTECTED]>
To:
Sent: Monday, September 01, 2008 6:56 PM
Subject: [flexcoders] Re: Question about Best Practices for Applications
with many views using Cairngorm
>I agree that states are probably a much better option than v
I agree that states are probably a much better option than viewstacks
because they are more dynamic. I probably will consider doing this as
I move along for this reason. I guess I was just wondering if there
was a better way than using constants in the modellocator to bind what
state, or sele
For your application, have you considered separating your views within
states, and only populate them on the "EnterState" event? You could
employ modules that load up on that event, rather than preloading them
with components.
The advantage of using states is that when your user comes back to
ope
8 matches
Mail list logo
