Bjorn, THe difficult part with runtime stuff is that I think Flex is compiled as a SWF when it is first accessed in your container. I wanted something (I'm guessing through a Java RO) that would return all the mxml files in a given directory. The hard part is getting Flex to import them..I tried and tried but I don't know if it's possible.
For transitions, I just have a show and hide effect for each screen bound to a fade transition. Nothing special. Brennan --- In [email protected], "Bjorn Schultheiss" <[EMAIL PROTECTED]> wrote: > > Hey Brennan, > > I'm hearing you all the way, > I'm using a similar technique in my AS2 app. > > I wanted to ask, do you have any particular technique for applying > transitions between screens, and also loading in screens at runtime. > I know the transitioning aint hard but i can see a few ways of doing it. > > In terms of loading screens at runtime, say for example i was was to have > 100+ screens and only load them into the viewstack as they were required, > and also remove them? > I want to create a wizard style scenario, and load each screen as required. > With so many alternatives it is unlikely a user will browse all screens, > therefore why load all into the viewstack on initialization? > > > Regards, > > Bjorn Schultheiss > Senior Flash Developer > QDC Technologies > > > _____ > > From: [email protected] [mailto:[EMAIL PROTECTED] On > Behalf Of dreuimar > Sent: Tuesday, 12 September 2006 12:03 AM > To: [email protected] > Subject: [flexcoders] Re: cairngorm: managing hundred of views > > > > 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] <mailto:flexcoders%40yahoogroups.com> 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] <mailto:flexcoders%40yahoogroups.com> 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] <mailto:flexcoders%40yahoogroups.com> > 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] <mailto:flexcoders%40yahoogroups.com> > ups.com > > > > [mailto:[EMAIL PROTECTED] <mailto:flexcoders%40yahoogroups.com> > ups.com] On > > > > > Behalf Of Diego Guebel > > > > > Sent: Monday, 11 September 2006 12:07 PM > > > > > To: [EMAIL PROTECTED] <mailto:flexcoders%40yahoogroups.com> > 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. > <http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt> > yahoo.com/group/flexcoders/files/flexcodersFAQ.txt > > > > > Search Archives: http://www.mail- > <http://www.mail-archive.com/flexcoders%> archive.com/flexcoders% > > > > 40yahoogroups.com > > > > > Yahoo! Groups Links > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Flexcoders Mailing List > > > > FAQ: > http://groups. > <http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt> > yahoo.com/group/flexcoders/files/flexcodersFAQ.txt > > > > Search Archives: > > http://www.mail- > <http://www.mail-archive.com/flexcoders%40yahoogroups.com> > archive.com/flexcoders%40yahoogroups.com > > > > Yahoo! Groups Links > > > > > > > > > > > > > > > > (Yahoo! ID required) > > > > > > > > mailto:flexcoders-fullfeat > <mailto:flexcoders-fullfeatured%40yahoogroups.com> [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Ralf Bokelberg <ralf.bokelberg@> > > > Flex & Flash Consultant based in Cologne/Germany > > > > > > -- 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 <*> To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/flexcoders/join (Yahoo! ID required) <*> To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
