The technique I use is probably a bit unorthodox.
I have view stack
that holds every screen possible in the application.
In Cairngorm, each
screen that has a helper (based off ViewHelper)
registers itself. I modified
this process to have a BaseHelper class
that extends ViewHelper, and the
helper classes for each view extend
BaseHelper. Now, in BaseHelper I have
each view register itself in a
collection in the model, along with whether
it's a system screen
(login page, main menu, etc), whether the view has any
requirements
before being switched to or exited from. I do this by having a
Screen
VO with different properties (application title string [for menu
at
top], page title string, whether it's a system screen, and a boolean
of
if it's accessible, which defaults to false.)
Each view helper implements
IEnterExit, an interface that has four
methods: enter(), exit(), setup() and
destruct(). I really only use
the first three in my application.
The
command that switches state will reference the view that's being
called by
the collection that the BaseHelper registered it's parent
with. It can then
perform any enter or exit logic on the screen being
entered and the screen
being left.
I also have in the relational database what screens each user
is
permitted to see.
My applications process is
this:
Application begins, each view registers itself with both
the
ViewLocator and the BaseHelper's collection. Since the login view
is
the first in the stack, it is shown. Upon successful login, the
user's
available screens are filtered through the application's
total
screens, and a final collection of Screen VO objects are put in
this
collection. Each screen the user has accessed to switches the
access
from false to true.
So to switch screens I have full
flexibility in being able to search
through available screens per user, along
with showing certain ones
(my main menu shows every available screen that
isn't a system
screen.) Switching screens becomes as easy as dispatching a
cairngorm
switch screen event with the screen you want to access, for
instance:
CairngormEventDispatcher.getInstance().dispatchEvent(new
SwitchScreenEvent("mainmenu"));
or,
if you're like
me:
CairngormEventDispatcher.getInstance().dispatchEvent(new
SwitchScreenEvent(
Constants.MAINMENU ));
And in the BaseState's registration, it takes the
screen's page title
from that same constants file. So Constants.MAINMENU :
String might
equal "Welcome to the Application's Main Menu", and this is
the same
string being dispatched.
Sorry if this is incoherent and
sloppy.
Brennan
--- In [EMAIL PROTECTED]ups.com,
"bjorn.schultheiss"
<bjorn.schultheiss@...> wrote:
>
>
True indeed.
>
> But when dealing with 100+ screens, surely not all
view related logic
> can be contained on a traditional Model.
> I
think Cairngorm leave alot of freedom in terms of how you implement
> the
view. DataBinding is an efficient way of updating the view with
> business
logic. But there is still the requirement of using a view
> framework. The
mx framework offers a awesome components and extending
> the existing
viewstack, box, etc, you can achieve good managable code.
> But i think
there are various view specific patterns to use
> inconjuction with
cairngorm.
>
> A key flex advantage in my opinion is that used with
cairngorm 2, the
> difficulty of handling client data has been totally
removed. This
> leaves more time available for enhanced the view and
providing Awesome
> GUI's. I cant wait for Blaze and Robert Penner's AS3
Animation
> contribution.
>
> My current 100+ View Screen app
that i'm working on is in AS2, i would
> so love to be using AS3
instead.
>
> Regards,
> Bjorn
>
>
>
> --- In [EMAIL PROTECTED]ups.com,
"Ralf Bokelberg"
> <ralf.bokelberg@> wrote:
>
>
> > Maybe the provided examples are a little bit misleading,
because they
> > are too simple. On the other hand, who is able to
create an example
> > with hundreds of views :) But the point is,
ModelLocator is just
> > that, a locator for the model and not the
model itself. If you have a
> > view or a group of views, which needs
multiple properties of your
> > model, you should create a class for
that and add an instance of this
> > class to the ModelLocator.
>
>
> > Cheers,
> > Ralf.
> >
> > On
9/11/06, Tim Hoff <TimHoff@> wrote:
> > > With views, the main
thing to keep in mind is directory
> > > organization. Respectfully,
I have a few differing ideas, than
> > > Steven, when it comes to
views. But at Cairngorm's current
> > > iteration, "all" state ==
model (local and common). Organize the
> > > actual view classes in
functional directory groups; for easy
> > > identification. In the
ModelLocator, bind the state of the views
> > > accordingly. With
hundreds of views, you will probably want to
> > > subclass the
ModelLocator, into functional groups, to aid in
> > > organization.
Ultimately, it boils down to each application's
> > >
requirements. For me, I just try to keep things as simple and
> > >
maintainable as possible; even when endless local state variables
> >
> tend to clutter and complicate the ModelLocator. I'm calling this
>
> > model happy. :)
> > >
> > > -TH
> >
>
> > > --- In [EMAIL PROTECTED]ups.com,
"Bjorn Schultheiss"
> > > <bjorn.schultheiss@>
wrote:
> > > >
> > > > Good Question and I hope
this thread gets a lot of posts.
> > > >
> > > >
Personally I don't think that the modelLocator is always upto the
> >
> job.
> > > > Don't get me wrong, in a data-driven
application this methodology
> > > is
> > > >
beautiful,
> > > > But my feeling is it will not satisfy all
requirements.
> > > >
> > > > For example, say you
have about 100 view states that are loaded in
> > > and
> >
> > disposed of, at runtime, as required.
> > > > I don't
think the ModelLocator is up to the task.
> > > > I think
possibly a "ViewManager" of sorts is required that acts as
> > > a
middle
> > > > tier between the Views and the
ModelLocator.
> > > >
> > > > I don't have any
concrete classes to show an example of what I
> > > mean as
I
> > > > haven't developed such a solution as yet.
> >
> > But I am at the beginning of a project that will require such
>
> > consideration.
> > > >
> > > >
>
> > > Regards,
> > > >
> > > > Bjorn
Schultheiss
> > > > Senior Flash Developer
> > > >
QDC Technologies
> > > >
> > > > -----Original
Message-----
> > > > From: [EMAIL PROTECTED]ups.com
>
> > [mailto:[EMAIL PROTECTED]ups.com]
On
> > > > Behalf Of Diego Guebel
> > > > Sent:
Monday, 11 September 2006 12:07 PM
> > > > To: [EMAIL PROTECTED]ups.com
>
> > > Subject: [flexcoders] cairngorm: managing hundred of
views
> > > >
> > > > Hi there,
> > >
> My questions is theoretical and best practice oriented, I just
> >
> wonder what
> > > > is the best approach to manage hundreds
of views since
> > > > viewhelper/viewlocator is out of
fashion.
> > > > I was reading previous post but didn't find a
good example or
> > > tutorial.
> > > > Can anyone
put some light on this?
> > > >
> > > > Sorry if
some of you receive this post twice, I think the first
> > > once
was
> > > > moderated.
> > > > Thanks in advance.
Diego.
> > > >
> > > >
> > > >
--
> > > > Flexcoders Mailing List
> > > >
FAQ:
> > > http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
>
> > > Search Archives: http://www.mail-archive.com/flexcoders%
>
> > 40yahoogroups.com
> > > > Yahoo! Groups
Links
> > > >
> > >
> > >
> >
>
> > >
> > >
> > >
> > >
--
> > > Flexcoders Mailing List
> > > FAQ:
http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
>
> > Search Archives:
> http://www.mail-archive.com/flexcoders%40yahoogroups.com
>
> > Yahoo! Groups Links
> > >
> > >
> >
>
> > > (Yahoo! ID required)
> > >
> > >
mailto:flexcoders-fullfeat[EMAIL PROTECTED].com
>
> >
> > >
> > >
> > >
> >
>
> > >
> > >
> >
> >
>
> --
> > Ralf Bokelberg <ralf.bokelberg@>
> >
Flex & Flash Consultant based in Cologne/Germany
>
>
>
