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: How would you do this: complex view states?  (Read 3603 times)
jpwrunyan
Sr. Member
****
Posts: 84


View Profile WWW Email
« on: March 18, 2012, 06:40:53 »

I am going to have a chance to redesign/refactor one of our poorly implemented PureMVC applications in a few weeks and am trying to determine how to address what has been a huge problem.

First, we started with just a general application with several toggle-enabled views.  These toggles are controlled by A_VIEW_SHOW/A_VIEW_HIDE notifications which the view Mediators use to hide/show their viewComponents in response to user actions (the UI is a dashboard view).  Additionally, there are other notifications for changing view modes unique to each view (eg: color/black&white mode, etc.). 

Next, it was necessary to make a sort of report application.  The original thinking was that each page of the report showed different information in a logical sequence instead of forcing the user to click buttons to manipulate the view.  So, instead of Show/Hide CheckBoxes for the UI, it would have a Next/Prev page pair of Buttons.  Page 1 would have A and B visible.  Page 2 would have B and C visible.  Page 3 would have D visible.  My co-worker implemented a very complicated system to do this which records what views are visible or invisible and dispatches the Show/Hide notifications as appropriate.  But it's a holy unmaintainable mess.  Everyone, even the original author, wants to redo it.  Since he is leaving, the task falls to me.

I don't think there is anything wrong with the design of the first application.  Every minute change of view is precipitated by a user event.  But with the second semi-automated report application, there needs to be a way to organize things so that when the user clicks one button, the overall view changes (as though he had pressed several all at once with the dashboard UI).  To clarify, the first application has a dashboard and a dashboard mediator to control things.  The second application does not--it just has prev/next buttons and can cycle those views automatically on a timer.  Otherwise the features of the two applications are basically the same.

So right now I am looking into the Finite State Machine utility to see if it might give me a eureka moment.  It hasn't.  But that is because I have yet to make a connection between the demos and what I am trying to do here.  But is this the way to go?  I'm still going to spend the next few days trying to figure out FSM but if there are better approaches for what I want to do, please tell me. 

PS Please keep in mind the most complicated design pattern I have used up to this point is Factory (and I guess MVC since that's what PureMVC is).

PPS The main thing that is giving me pause is this: each set of report pages is actually a dynamic list.  Report1 might be pages [A&B, B&C, D] and Report2 might be pages [A, B, C&D, ... X], etc. customizable to infinity.  So my situation is that the various view states and combination of view states is very definitely NOT finite.
« Last Edit: March 19, 2012, 12:10:35 by jpwrunyan » Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #1 on: March 19, 2012, 07:35:51 »

Is this a Flex application? If so, I would suggest looking the use of Flex View States. There is no reason the View can't encapsulate its layout behavior, much to the relief of your Mediators, who should concentrate on mediating communications with the view components rather than managing the minute details of their state.

The State Machine utility can help manage the overall application state, and the views can organize their own internal states when the application state changes.

-=Cliff>
Logged
jpwrunyan
Sr. Member
****
Posts: 84


View Profile WWW Email
« Reply #2 on: March 20, 2012, 05:43:03 »

Well, yes, it is a Flex application.  The components are written in AS.  I think I overly simplified my example as later I realized what I described shouldn't be so difficult.  These are high level state changes.  A view class doesn't contain the controls for manipulating itself.  A separate dashboard class does.  So when a control is changed on the dashboard, a notification is sent from the dashboard Mediator and then picked up by the appropriate view Mediator(s).  So since the dashboard class and the passive views are separate, I think implementing Flex View States between them is hard to do without breaking either OOP or MVC conventions (ie just becoming an ad-hoc mess).  I really want them to be independent for the very reason that if I remove the dashboard, there isn't much coding overhead.  Now don't get me wrong, I use Flex View States where I can.  But the "currentState" change would still be precipitated from an event outside the actual view class whose state is changing.  Ergo the need of Notifications.

Now, if my problem really were as straightforward as hide/show toggles, I could just make a look-up table and have the ApplicationMediator process that and send hide/show notifications to the view mediators.  Or better yet, this situation would allow me to use Flex View States because in theory the application view would just toggle the visible properties of its sub-view components, assuming they are in its display list.  If my application were this simple that is.

Right now I have three separate applications, all using essentially the same components and very similar business logic.  But their frameworks are all written completely differently.  In the future it may be necessary to combine them under a monolithic shell application.  But for now they exist in independent browser windows.  I repeat, we plan to convert this to a multi-window AIR application in the future.  So right now, I need to think about that.  Of course, I want to avoid inner-platform effect and keep things as simple as possible (ie why make a system that simulates user-interaction when direct user-interaction itself will suffice?).  But I need a smart way to control a myriad of view combinations programatically.

These combinations are coming from the database.  So depending on what the application receives from the database, it needs to layout appropriately and update appropriately with new queries.  And it's that update part which I want to do right.  I can handle making Flex View States for each individual view component and having its mediator receive a "currentState" value via notification; it's the PureMVC level where I am wondering what to do.  BTW, before I end this with an oversimplification again, there is a reason why I can't use "currentState" (unless I want like 20 or so state declarations per view class).  Some of these views have their own sub-elements that can be toggled.  And again, the views don't control themselves.  The dashboard does.  And the dashboard must be surgically removed from one application that is otherwise essentially identical.

Anyway, if any of the above thinking seems wrong-headed, please let me know.
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #3 on: March 21, 2012, 09:30:30 »

Well, if you have a one to one relationship between application state and view state, (or close to it) you may want to use the StateMachine utility heavily.

When the a new state is entered, the mediators for your view components that need to change will be interested in the notifications from the StateMachine, and will set properties or call methods on their view components that cause them to correspondingly change their appearance (or be removed from the view). Commands may respond and register new mediators that in turn create their components and have them injected into the view by sending off a note that the ApplicationMediator or the DashBoardMediator listens for.

But you see, even for a mediated subcomponent like a form that needs to be enabled or disabled based on application state, can also implement Flex View States. It might have one way of displaying data but a different layout when it is collecting data. Not the big dashboard but the little component. The mediator may hear the state change notification from the StateMachine, and in turn call a method on the component that changes its currentState property. What's the alternative? That component's method instead does a bunch of setting visible or enabled properties or some such.

-=Cliff>
Logged
Pages: [1]
Print