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: Windowing Architecture  (Read 8832 times)
danmvc
Jr. Member
**
Posts: 13


View Profile Email
« on: July 07, 2009, 11:59:11 »

Hi, I'm doing my first MVC project as a test of the framework, keeping in mind some projects in the future. I still don't fully understand the flow/where to put everything (especially with pipes) but I'm getting there.

The project I'm starting with is to create a basic windowing setup similar to an OS allowing for dragging, resizing, opening and closing the content of these windows. I want to use the Multicore functionality of PureMVC. At first I was thinking of making a WindowModule, and then the shell would load in a window module every time it needs to create one. This would work fine, however, I then realized I'd need to manage these windows somehow, for instance if the user wanted to cascade, resize, them or something, or just to enforce boundaries and theings on the windows, so I then thought I would need a WindowContainerModule. What I'm having trouble with is the communication between these elements, and if this is actually how it should be done.

This is what I was thinking:
1) The shell would take a button click to open a new window.
2) It would then pipe a message to the WindowContainerModule to create a new window.
3) The WindowContainerModule would load a WindowModule
4) Certain messages in the WindowModule would then be piped to the WindowContainerModule, while other messages would need to be piped all around the application to any possibly interested party ( I guess mainly to the shell which would then handle the logic ).

Does this sound right? I'm separating WindowContainerModule from WindowModule to allow for multiple types of window modules, like a notepad or a traditional window, etc.

Anyway I realize it can be done a number of ways, but I'm currently at a loss for how to setup the piping channels. I've followed the HelloPipes tutorial so I can get the shell to talk to a sub-module, but I'm not sure how to get The windowContainerModule to talk to the other modules. I guess I can just treat the WindowContainerModule as if it is a shell of sorts and have it talk to it's submodules with a TEE-SPLIT and a TEE-MERGE, but then it would also need a pipe that goes back to the main shell.

I'm obviously out of my element, but if there is anything that I'm obviously going astray about, let me know, or maybe there is an example of a pipes windowing system already?
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #1 on: July 07, 2009, 01:52:58 »

... while other messages would need to be piped all around the application to any possibly interested party ( I guess mainly to the shell which would then handle the logic ).

Beware overburdening the Shell by conceiving it as a Grand Central Station type object;Everything doesn't have to be routed through the Shell. Think very carefully about your desired plumbing architecture and the relationships between modules.

-=Cliff>
Logged
danmvc
Jr. Member
**
Posts: 13


View Profile Email
« Reply #2 on: July 07, 2009, 02:47:16 »

Yes, I am aware of this. The only reason I guess I fall back to that is that it seems like the Shell would be the only place that is 'AWARE' of the configuration of modules since they should be unaware of eachother.

One place I'm confused is this:

I have a module listening for a message of type ADD_WINDOW. The ADD_WINDOW constant is stored in this module's constants file or application facade. If I had another module connected somewhere else in the application that should open a new window without going through the shell, that second module would have to refer specifically to the constants file of the first module breaking the generic usability of it. That's why traditionally I would send a message to the shell, then the shell would send a message out. I'm kind of stating this just so you will tell me how to do this correctly. I don't like sending everything through the shell, but it seems kind of necessary if all modules are independent and can't specifically target eachother.
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #3 on: July 08, 2009, 08:30:12 »

It all depends on your custom plumbing and protocol as to whether a module is aware of another.

For instance, consider a module that does nothing but communicate with a set of services. Consider a view module that has need of that service module's functionality.

You could plumb it so that the shell has the reference to both modules, and the view module sends messages to the shell, and the shell rebroadcasts them to the service module, and also forwards the responses back to the view module. That makes the Shell the middleman for all transactions between the view and service modules, simply due to brute force plumbing and protocol. The message name constants must be shared by the shell, the view module and the service module.

Imagine instead that the Shell creates the view module and the view module sends the shell a request to have a service module connected. The shell instantiates and plumbs the service module bidirectionally to the view module and sends the view module a message with the name of the pipe to the service module.

From that point on the view module sends messages to the service module on that pipe and the service module responds on stdout which comes into the view's stdin. The message constants need only be shared between the view and service modules and the shell does not need to participate in ongoing communications. And the view module need not reference the service module to get the constants, you put protocol constants in separate classes in a library and have every module include the constants it needs for the protocols it will participate in.

There are many approaches to the plumbing. Here is a deeplink into the MultiCore presentation describing various arrangements: http://puremvc.tv/#P002/T235

-=Cliff>
Logged
danmvc
Jr. Member
**
Posts: 13


View Profile Email
« Reply #4 on: July 08, 2009, 12:04:58 »

OK that's starting to make sense now. I have another very basic question now though :). Maybe I should move to the getting started forum.

I have a button in my viewComponent that should create a window with some content in it. In the examples I have seen, the Loaders for modules have always gone into the viewComponent file ( I guess since they are display objects ). The problem I was running into with having the Loaders be in the view component is that, I would create the window module in the view component via a Loader then dispatch an event that it was initialized. The mediator would then receive that event but it wouldn't have a specific reference to which Loader was loaded without creating a custom event, which should be unnecessary with notificaitons.

However, it seems to make sense to me that the viewComponent should only dispatch an event to the Mediator that a module should be loaded. Then the mediator can create a loader and load the module. Is this an OK way to do it? That way the mediator has a reference to the module and can pass it on in Notifications and things.
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #5 on: July 08, 2009, 03:31:38 »

Sure. A module can be considered just another view component really. In a simple design having a view component use a loader to load in a module and tell the mediator about it via an event is perfectly fine, and you could consider it the same as a case of deferred view component instantiation.

It all depends on how complex your system is as to whether this is the right answer. If you do lots of module loading and unloading and multiple instances, etc, it might be best to centralize the loading of and management of modules their plumbing.

-=Cliff>
Logged
Pages: [1]
Print