PureMVC Architects Lounge

PureMVC Manifold => MultiCore Version => Topic started by: Stray on May 23, 2008, 10:25:50

Title: New MultiCore PureMVC project - UML tool - advice and requests appreciated.
Post by: Stray on May 23, 2008, 10:25:50
Hi, I'm organising an opensource project to develop an integrated planning-modelling-documenting-coding tool which will run on AIR.

The project is called Identity Modeller and the objective is to deliver a friendly UML tool which also allows you to do CRC planning (on the reverse of your 'virtual index card' for each class) and to add comments to projects and classes, with automatic stubcode generation with asDoc compatible comments, and reverse engineering from code files. The project will be 100% AS3, not flash or flex specific. The initial target language is AS3 but as the parser will be a module and the language definition will be held in external XML, there is potential to support other languages as well.

A project participant has suggested PureMVC as an alternative to cairngorm and we're definitely going to use it. I'd like all modules to be PureMVC structured as well, and we may later have a project-per-window view, similar to that of omnigraffle or coda, which also cries out for the MultiCore version.

The building of this tool will probably generate a number of useful extensions to PureMVC - some along the lines of undo / redo / history, others to do with remembering application state for each loaded module ... and more that we haven't specified yet!

In the spirit of open source we'd like those features to be as generic as possible - so I'd hoped to post information about the project here to get feedback on those aspects as we develop?

I'm particularly interested in how the MultiCore stuff works within the AIR sandbox. Has anyone done any MultiCore work within AIR yet - or will we be the first?

Title: Re: New MultiCore PureMVC project - UML tool - advice and requests appreciated.
Post by: puremvc on May 23, 2008, 06:44:38
Good to hear you're going to use MultiCore for the project. You will find that it is almost not different from Standard. Just that getInstance requires a unique string for the app and each module.

And don't handle the facade in the constructor of a mediator or proxy. Wait until onRegister. This is a newly recognised best practice in Standard as well, don't take actions that could start a conversation until registered.

One of the big struggles still, is how do wou make modules and the app talk to each other in a loosely coupled way. I've just finished a new MultiCore utility for intermodule communication called Pipes. It has been thoroughly unit tested, and a demo is on the way. You might want to investigate that. Filters could really be helpful to you in template munging when moving data between modules for instance.

I also finished porting the framework unit tests to MultiCore so it is nearing a production status announcement.

Definitely keep us posted on your progress.


Title: Re: New MultiCore PureMVC project - UML tool - advice and requests appreciated.
Post by: puremvc on May 25, 2008, 11:44:04
Hey, here's a quick link about modules in the AIR sandbox.


Someone posted to these forums yesterday with a cautionary note (they may have removed it as I can't find it now) saying there was a problem with modules in AIR only being able to communicate over an interface and sending simple properties (String, Number, etc) as opposed to complex objects. This article seems to indicate otherwise, but I'll find out. I'm going to demo the Pipes utility today, which allows inter-modular communications via message objects.


Title: Re: New MultiCore PureMVC project - UML tool - advice and requests appreciated.
Post by: Stray on May 29, 2008, 10:35:08
Hi Cliff - hugely appreciated!

Pipes sounds ideal, and I think the post you're referring to about data moving over the sandbox bridge was one I left myself possibly?

You can move complex data structures between the module and the loading app, but the custom type information is lost - so if the application is expecting an instance of MyClass and what it receives is simply an Object then it chucks a runtime error. Of course you can wrap the error and cast the object to what you know it to be, or strip the data and populate a new typed class, but so far we've preferred to stick to passing simple data - putting a 'createDataObject' and 'createFromDataObject' function in where necessary, because you lose all your functions on the object anyway, so it seems more honest (and less confusing) to just deal with the simple typed data that can pass around intact.

From my own testing I would imagine that sending the message objects would be possible as long as you're not strictly typing them on receipt - or are deliberately casting them, confident that you're receiving something you're expecting. Let me know how it goes though - it's possible that I've over generalised from the specific case of the application I was building!