Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought


Over 10 years of community discussion and knowledge are maintained here as a read-only archive.

New discussions should be taken up in issues on the appropriate projects at https://github.com/PureMVC

Pages: [1]
Print
Author Topic: VewStack  (Read 8978 times)
kmorland
Courseware Beta
Newbie
***
Posts: 6


View Profile Email
« on: January 23, 2008, 12:54:49 »

Hello,

I am a new user working with PureMVC.  I have gone through the courseware literature, which by the way is very well written and thought thru.

My question is how I can I change Views?  I have a viewstack with multiple views defined.  Per example I have a Login Form, with a Register Link Button which should go to the Register new user form.  I have tried fully some examples and cannot seem to make it work correctly.  Can someone give me an overview of the solution or maybe some sample code.

Thank you for your time,
Kevin
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #1 on: January 23, 2008, 02:54:53 »

Hi Kevin,

I'm assuming you have a ViewStack and the Login form with the Register button is in one child and the Registration form is in another child.

There are a number of ways to do things, including encapsulating all this viewstack switcheroo stuff inside a Flex component that extends ViewStack without the PureMVC apparatus ever being consulted. If the action is simple enough you may consider that.

However, I'm going to describe the approach that assumes some other view component(s) or command(s) need to hear about this action as well.

The overview of what you need to have happen is this:

When you click the Register button in LoginForm, you should dispatch an event (LoginForm.USER) that bubbles.

This event will bubble up to the ViewStack, who has an associated ViewStackMediator.

That Mediator placed an event listener on the ViewStack when it was created, and so now it hears this event (LoginForm.REGISTER).

The Mediator sends a ApplicationFacade.REGISTER_USER notification, thus translating a boundary-defined and generated event into a notification.

The ViewStackMediator can then set the viewstack's selected index to the registration form child in one of two ways:

While still in the event handler for the REGISTER event, it can set the selected child,

OR

it can list REGISTER_USER as an interest and handle this when it is subsequently notified.

The first one is straightforward and likely what you want. In fact if there are no other actors in the system that need to respond to this event, then you might just set the value of the viewstack index and never send a notification, QED.

However, if you DO have other Mediators or Commands that need to be notified, then you might consider handling the local adjustment of view state in the same place as all the other Mediators that respond to this notification, namely in handleNotification.

That last, a Mediator sending a notification that it turns around and responds to in the notification handler, might seem the long way around the barn, but if multiple mediators respond to a notification to set their local view state, it's nice to see all the handling code in the same place, irregardless of whether the Mediator in question generated the notification or not.

When you're trying to debug how the view settles on its final collective state after a notification, you don't care where the note came from, only what the aggregate response was. By looking at every Mediator responding to the given note, you see this quickly. This is why its nice to have a notification-generating Mediator respond to its own notification rather than handling its local part of the view state response and then sending a note to the others.

Hope this helps.
-=Cliff>
Logged
kmorland
Courseware Beta
Newbie
***
Posts: 6


View Profile Email
« Reply #2 on: January 23, 2008, 03:42:48 »

Thank you for the quick response.  I think I understand your response.  I am building a fairly large application with multiple views(children).  From your response, I would create a mediator for the ViewStack and call the multiple views using the controller.  Would I have to create a mediator for every child or this one ViewStack mediator that I can call from the controller to initialize the view that is needed?  I would like to only have one Mediator if possible...

Thank you for your time.
Kevin
Logged
Joel Hooks
Courseware Beta
Sr. Member
***
Posts: 146


baby steps

 - 46288188  - passport@provinsal.com  - joeltuff
View Profile WWW Email
« Reply #3 on: January 23, 2008, 03:49:11 »

Thank you for the quick response.  I think I understand your response.  I am building a fairly large application with multiple views(children).  From your response, I would create a mediator for the ViewStack and call the multiple views using the controller.  Would I have to create a mediator for every child or this one ViewStack mediator that I can call from the controller to initialize the view that is needed?  I would like to only have one Mediator if possible...

Thank you for your time.
Kevin

This is just from my experience, but I am creating a fairly large application too. The single mediator approach really screwed me as my application grew and I am currently refactoring the entire thing to separate my various view components and their associated mediators.
Logged

http://joelhooks.com - my ramblings about developing with actionscript and python using pureMVC and django respectively.
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #4 on: January 23, 2008, 03:59:13 »

Kevin,

The granularity of the mediator/view component implementation is a balance only you can decide upon based on your app. The approach I take is to start with one Mediator, then break it into further Mediators as the application grows.

Ultimately, you don't want a ViewStack mediator to know too much about its ViewStack's children, though. It should pretty much be in charge of knowing when to switch to which child, period. This keeps it simple and easy to debug.

So the ViewStackMediator would handle switching the stack index, then a Mediator for the registration form would handle the events and notifications specific to that view component. Making these separations will make your component/mediator pairs more reusable and easy to refactor.

Monolithic Mediators that know too much are an AntiPattern.

-=Cliff>
Logged
kmorland
Courseware Beta
Newbie
***
Posts: 6


View Profile Email
« Reply #5 on: January 23, 2008, 04:44:45 »

Hi Cliff and Joel,

Thank you for your inputs and advice.  In just the short amount of time working with the mediators for I can see where Cliff's approach works well and organize.  I have been able to get the viewStackMediator to utilize the selectedIndex.  I am still having trouble get the Register form to show up.  What troubleshooting advice can you give upon tracing down the problem?  I was able to get the login and login success page to show.

Thanks,
Kevin
Logged
Joel Hooks
Courseware Beta
Sr. Member
***
Posts: 146


baby steps

 - 46288188  - passport@provinsal.com  - joeltuff
View Profile WWW Email
« Reply #6 on: January 23, 2008, 09:12:50 »

Kevin,

Checkout how they manage the viewstack in this example. I found it very helpful.

Monolithic Mediators that know too much are an AntiPattern.

What a great way to put it. Reminds me of refuctoring. ;)


\
I AM THE ANTIPATTERN
Logged

http://joelhooks.com - my ramblings about developing with actionscript and python using pureMVC and django respectively.
kmorland
Courseware Beta
Newbie
***
Posts: 6


View Profile Email
« Reply #7 on: January 24, 2008, 11:11:50 »

Hi Joel,

Thanks for the response and the article.  I will check it out.  I found a method that worked, I am not sure if it is the best.  Would you happen to have any advice on commands?  When I put any code inside the execute method, I receive a flash play null object error.  It happens no matter what the code, a simple alert.show will cause the error.

Thank you for your time on these matters.  I have a made a lot of progress learning the framework...

Kevin
Logged
kmorland
Courseware Beta
Newbie
***
Posts: 6


View Profile Email
« Reply #8 on: January 24, 2008, 01:18:38 »

Hi Cliff and Joel,

Thank you for all your efforts.  I resolved the problems regarding vewStacks and commands.  Both were easy to resolve after I realized I had a stupid mistake.  For the short period of working with the framework, it is well written and pretty easy to implement.  Thank you Cliff for a job well done!!!

Kevin
Logged
Joel Hooks
Courseware Beta
Sr. Member
***
Posts: 146


baby steps

 - 46288188  - passport@provinsal.com  - joeltuff
View Profile WWW Email
« Reply #9 on: January 24, 2008, 03:17:12 »

Excellent. Glad to hear that you worked it out.
Logged

http://joelhooks.com - my ramblings about developing with actionscript and python using pureMVC and django respectively.
Pages: [1]
Print