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: nested view components and mediators  (Read 8698 times)
Buakaw
Newbie
*
Posts: 4


View Profile Email
« on: June 27, 2008, 12:14:53 »

Hi all!

First off, I want to thank Cliff and all other involved developers for creating this great framework. Since some days now I've been looking into it.
I think I understand the most part of it. Now I'm trying to figure out, which is the best way to realize an upcomming application with that framework.

Before I looked into pureMVC I already used my own framework, which is a little bit simpler than pureMVC.
This was perfectly fine for smaller projects (e.g. websites and small business applications).
But our next project will be a really big application (a website builder) and later also be maintained/extended by other developers.
So I tried to enhance my framework by looking at other frameworks - that's why I'm here today.

So that's my current situation:

Imagine a website builder. There is for example a tabsystem view component which lets the user add any view component to a specific tab.
These components can be nested (e.g. different containers or even another tabsystem component).
Thurthermore there is a "remove tab" button to remove a whole tab with its related content.

Now we are going into more technical detail:

If the user clicks that "remove tab" button, the tabsystem view component will dispatch an event to its mediator (as far as I've gotten the idea).
All mediators (and corresponding view components) relating to that tab shall now be removed and "destroyed" (means also removing all eventlisteners, deleting references to complex objects etc.).

My question is here: Since only the view components are nested (DisplayObject hierarchy) and the mediators are not, how can you retrieve all the tab related mediators?

My own framework would handle it like this: Since the mediators in my framework (there is actually no mediator but controllers which do the mediator's job, too) also are nested it is quite easy:
The tabsystem's main mediator gets the button click event.
It will then call all child mediators' destroy - method. Every child mediator will do the same with its own child mediators.

...

I dont know, if the following pureMVC solution would break any rules:

So in pureMVC I would need a "MediatorHierachyProxy" storing the hierachy of all the mediators.
Then there is a "RemoveMediatorCommand" which gets the id or reference of the mediator which should be removed.
It then will retrieve all the mediator's children from the MediatorHierachyProxy and call their destroy method.
It proceeds with the children's children ...


The hierarchy also is important for the saving process of the website creation.
To store the current state of the website, every component mediator shall return its own state in XML format to its parent.
The parent collects all parts of XML, adds its own data and returns the whole thing again.

...

Maybe it's better to instantiate a proxy for each component. Maybe the proxys themselves are hierarchically structured.
Yes, they should build up the whole XML structure which will be stored in the database.

What do you think?

Thanks in advance for taking the time reading my post.

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



View Profile WWW Email
« Reply #1 on: July 02, 2008, 07:49:08 »

Its no problem in either case. The proxy and view component shouldn't know about each other of course. And the mediator and proxy will need to share a common key that the proxy passes as the type parameter of notifications bound for its mediator counterpart. That mediator compares the type property of the notification to its own key and only acts if they match.

And proxies can certainly retrieve and interact with each other to keep the integrity of the model.
-=Cliff>
Logged
Buakaw
Newbie
*
Posts: 4


View Profile Email
« Reply #2 on: July 02, 2008, 09:35:51 »

Thanks a lot for your reply Cliff.
Logged
Pages: [1]
Print