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: MDI Application approach  (Read 8179 times)
butcher_31
Newbie
*
Posts: 2


View Profile Email
« on: April 12, 2010, 02:17:47 »

Hi,

I'm building an MDI based application (flex-mdi from flexlib), and I'm wondering if there's a best practice/approach for PureMVC within that context.

Problems, for example:
* I have a list form of users (with a mediator and proxy), and upon double clicking a user from the list, a new User Details window opens. What happens if I want 2 detail windows (same meditaor)? ok, so I started working with context object (UIDs after mediators' name). But what if the users have a sub-entity with a list and another CRUD operation?
I'm starting to dig deep with Contextual objects (the context is kept so that the proxy will send notifications only for the mediator with the same UID, of course).

* I want to enable CRUD for a user, so the proxy for the list holds CRUD functions. how does the details window knows about the proxy, if it has a different context (UID) ? and if I close the list window and remove the proxy, but the details window stays open?

* So I thought creating a proxy for each window, that has the same UID and is responsible for actions from that window. But then, what if I want to be able to change Disable/Enable settings from the details window and from the list window as well? same code twice?

If I sound a bit scrambled, it's because I am.
I'm trying to think about it, and can't come up with an ideal solution for PureMVC.
Help anyone :) ?

Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #1 on: April 13, 2010, 06:00:56 »

It does sound a little scrambled.

First, no view component should know about any Proxy, only Mediators and Commands should.

Second, it sounds as if you are having multiple instances of the list Proxy which I'm not sure you want.

You do want multiple instances of the user details mediator, named uniquely.

When a detail form sends an update user event the mediator attached calls the proxy's update method, passing the user object from the view.

The proxy makes the update call and sets a userid property on the immediately returned AsyncToken object.

Then when it recieves a result, it inspects the token and sends an UPDATED note, setting the type parameter to the value of the userid on the token.

The user details mediators are all notified because they are interested in the note, but in the handleNotification method, if the type property of the note is not equal to the user id of their view component's user object, they do nothing.

So the mediator that sent the original note will ultimately handle it.

-=Cliff> 
Logged
butcher_31
Newbie
*
Posts: 2


View Profile Email
« Reply #2 on: April 18, 2010, 04:49:43 »

Hi Cliff,
Thanks for the reply.
What you said is exactly what I did (further more, instead of applying a "userid" property to the AsyncToken, I extended the Responder class to include this property and to be retrieved at the result/fault methods).
The problem began, when the details form (i.e. UserDetails), held a list of its own (i.e. SubUsersList), which worked exactly like the main users list. Meaning, another level to the hierarchy.
I can't hold the same proxy for each list, because each list presents different data by different filters (for exmaple, the subusers are retrieved by the "parent" user id, each list is a different id).
So once I gave each list its own proxy, the details component could not know which proxy to address without a context object telling him which proxy is his "parent" proxy.

any idea for this one?

Thanks
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #3 on: April 18, 2010, 04:50:25 »

I'm just a little confused at this point. Are all these proxies showing different views of the same list, just with different filter settings?

-=Cliff>
Logged
Pages: [1]
Print