I decided to experiment with combining both Gaia's frontend flash framework together with PureMVC.

http://www.gaiaflashframework.com/index.php/topic,914.msg3943.html#new

Though the results seem pretty cool and really powerful combining the functionalities between both frameworks, there were definitely issues with which "framework does what". Mrs Gaia, being a front-end framework, should normally be restricted to the View context of the application, and should wait for notifications executed on  Mr PureMVC's backend  (whether through Commands or Notifications), before letting Mrs Gaia execute through it's different mediators. But conceptually, because Gaia also has "very useful" commands within it's Gaia.api, couldn't Gaia be also be part of the Controller aspect of an application? So, do I lump a Gaia.api command within a concrete Command class or is it better to notify some Gaia mediator or proxy to execute such a Gaia.api command? There are options to both tightly couple or looesly couple the 2 frameworks, providing an immense load of possibilities and power here. It also allows one framework to execute something first, than let the other execute in response to the first, providing an additional layer of synchronisation.

And there comes the prospect of event hijacking. Do we take advantage of this front-end aspect in Gaia to dispatch an event to the appropiate mediator to run application-specific commands, and then wait for a notification to release that Gaia hijack?  Often, it's safer and perhaps more managable to keep Gaia's hijack handling within the view context of the application only, Gaia within Gaia, even though cross-framework execution is still possible. Somehow, PureMVC's concrete commands prior to running Gaia, sounds safer. Yet, letting Gaia hijack and than running PureMVC's commands via a mediator sounds perfectly fair as well. After all, aren't they both in the Controller context in essence?

It's like a real-life marriage situation no doubt, with roles ---- roles that may not be clearly spelt out at the first instance. Mrs Gaia combines logic with view. But Mr PureMVC seperates logic and view. Oh gosh.

For PureMVC veterans/users familiar with how Gaia' s frontend works, give your advice. Can both frameworks work together in harmony?

If you don't want to reinvent the wheel too much with SWFAddress, deep-linking, among other stuffs ,you might want to consider Gaia Framework. http://www.gaiaflashframework.com . It already has a wide array of front-end features which you can leverage upon to deliver your site's basic features immediately. Event hijacking would come in useful for your transitions (your index page which could house your 3D spaceScene that hijacks every onBeforeGoto event to navigate about in space prior to transitioning in the page). Your nav overlay would be on a TOP depth layer. And your other concrete content pages could transition in accordingly in the middle depth layer, each page having an onDeepLink event to basically handle lots of deeplinking/bookmarking, easily. I see your site concrete content pages has very little bookmarking.. In such a scenerio, the front-to-back approach (the bookmark triggering the COMMAND) could be more effective, with the bookmarks actually controlling what gets displayed. It'd also make your site information more accessible for people, since each page in Gaia already has a onDeepLink event method built in already.
 
Of course, PureMVC is useful for linking your content with your backend model proxies, and your view medaitors to receive/send notifications. Thus, I came up with some experiments combining both PureMVC and Gaia to take advantage of both frameworks which you can see here.  http://www.gaiaflashframework.com/index.php/topic,898.msg3868.html . Of course, you can still rely on a traditional PureMVC SWFProxy to send out notifications. I guess, since you already have many 'wheel" feature proxies, commands & mediators within PureMVC itself, there comes a delimma of deciding whether PureMVC's way is still better, since custom made "wheel" features still provide better control for the developer, and the ability to register/unregister such services as and when you like.