Multitasking environment structure

[redbullmarky]

Ok, I've been doing my reading and in all honestly picked up a fair few new tricks and tactics over the last few weeks. However, pinning these tricks to what I'm trying to achieve is the hard part.

My problem: I'm trying to redesign a back-end system of mine to take a more multitasking approach. By that, I mean the ability to allow more than one 'module' to run within my environment at the same time by means of a "popup" (though not a nasty popup, more custom DHTML types that i can still drag around, etc). I'll use a proper example of what I want to achieve: lets say i have two modules open. both exist in their own Iframe/DIV (havent decided yet). Lets say one of them is a list of people i want to call/refer to later, the other is a fresh list of ALL people in my database. Depending on whether I use an Iframe or a DIV with AJAX will depend how I get my call list updated (i.e, drag+drop or a simple 'add to call list' button/link next to each result).
Now - the structure for the site suddenly sounds quite complex. I have my main application (ie, the desktop with icons to launch these modules), and now i have two seperate modules open. I'm trying to work out the best way to structure my entire code so that not only can the two modules "talk" to each other, both of them can also "phone home" to my main application if needs be. so basically, my site needs a proper 'object' approach that would also allow sharing of resources between all elements.

i need to work out (opinions or potential solutions on these welcome):
1, DIV with iframe inside or DIV who's content is loaded with AJAX for each module. Iframes would allow me to keep more seperation but would probably mean not getting the interactivity between each module that i need. AJAX would be great in many ways, only i'm worried about <form>s and their 'method' - get/post, etc, as reloading the main page would theoretically reload the entire application and close all the windows. so i'm guessing i'd need an 'onclick' to call a request to send the form data back to the model, instead of regular 'submit' buttons.

2, where to store the GLOBAL parts that the modules as well as the main application have access to. sessions? file? database? etc

3, whether, due to the seperation, i should treat each module as its own little program with its own MVC system.

4, the structure of the app's core and same for the individual modules. OOP is not totally alien to me, but when i get into 'layers' and the 'extends' / 'implements' operators, it starts to get a little hazy and hard to get ontop of.

5, directory structure for the whole thing.

each 'module' needs to be as light weight as possible in terms of what it sets up. literally it should work almost like a 'plug in'.

in terms of the coding, that's not my issue and i'd have no problems doing that. but obviously i don't want to get cracking on such a huge thing if i've not thought these things through to start with, as it needs to be relatively future proof in terms of adding things to it. oh and also - it's going to be a multi-user thing too, with each user having different 'desktop icons' and permissions, so that adds extra to the whole thing.

So - to you "pattern-meisters" and framework gurus, how would you structure THAT? :)

Cheers
Mark

[Jenk]

ok, MVC - Model, View, Controller.

Controller - The decision maker: what needs doing? Who should do it? Get them to do it.

Model - The processing of data, all of it, is done here.

View - The part the customer sees. The HTML, the Text, the pretty colours, the images, or lack of all of the above is arranged here.

With web-design, each page request (i.e. everytime a user clicks a link, enters your url in their address bar, refreshes a page etc..) is what defines each 'application' or process. For each request sent to your server, a Controller will need to decide what action is to be taken. A model will need to crunch data, and a View will need to display the results.

With regards to a plug-in system, you'll need to look into interface design - that's not to say you should just go creating actual interfaces all over the place, but look into the practice behind it. Standardise and document your methods, parameters and return values. The idea is that every plugin for a particular purpose will all require the same parameters, and will all return the same data types.

[redbullmarky]

the MVC i kinda understand. how to employ it in my situation is what i'm trying to get to grips with, as like i say i'm pretty much gonna be having the main (desktop) app working (which would be index.php) and also various popup modules working in their own DHTML windows. tasked with doing something like that, what would the very basic file structure be? how would you define a module that works in its own "window"? how would you allow these windows to work closely with the main app? how would you allow info to flow between all of these?

Cheers
Mark

[redbullmarky]

any more thoughts on how i could go about structuring this?

[Jenk]

Each popup will invoke it's own MVC process, thus you pretty much just go about processing them as that. Any interaction between pop-up's/windows is done just as is in any other situation.