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

Show Posts

| * |

  Show Posts
Pages: [1]
1  PureMVC Manifold / MultiCore Version / Pipes, Fabrication - Excessive? on: April 20, 2009, 01:52:33
I am intimately familiar with the multiCore version and the Pipes utility since it was used on a lengthy 6 month project that I was part of.  The more experience I received with Pipes, the more cumbersome and cyclical it seemed because of the 4+ steps involved in achieving communication between 2+ modules.  Also, as the scope of the project grew, so did the number of Message-to-Notification conversions.  In the flex profiler, Notifications from one module to the other were taking anywhere from 50-150ms to get to their destinations.  Now, a utility based on it (Fabrication) seems to further exacerbate the obscurity of module-to-module communication and presumably sharpens the learning curve for those new to PureMVC. 

The code is absolutely beautiful in both utilities and they both offer some interesting benefits but there is a more direct, a faster, and an easier way that compresses the job of module-to-module, module-to-shell, and shell-to-module communication into a single method.  Its so simple, I am convinced that I am missing something but I just don't see it.  Can someone help?

Here is the method and it can be placed on any subclass of the Facade that wishes to perform module to module communication:

:
public function broadcast(name : String, body : Object = null, type : String = null, destinations : Array = null) : void
{
// Assume all modules will receive the notification, even the calling Facade instance.
if (!destinations)
{
for (var key : String in instanceMap)
Facade(instanceMap[key]).sendNotification(name, body, type);
}
else
{
while(destinations.length)
{
try
{
Facade(instanceMap[destinations.pop()]).sendNotification(name, body, type);
}
catch(e : ReferenceError){}
}
}
}

All this does is take an array of keys that were assigned to the Facade instances on creation and matches them in the instanceMap to route notifications.  All you have to do is call braodcast() (Global) instead of sendNotification() (Local) when you want to notify other modules. Targeting occurs by passing the array of keys to the method.  Since the static instanceMap already contains the instances of any and all Facade objects created within the application (provided the getInstance() factory method is used), it seems silly to do it any other way...unless of course I am missing something.

Justin
2  PureMVC Manifold / Standard Version / PureMVC use in Ajax/AMF Gateway on: April 18, 2009, 08:47:29
Hi-
Just wanted to start by saying that I am a huge PureMVC fan.  I have used the AS3 port in large Flex projects for some high profile clients and it has convincingly reduced dev time by weeks on those projects. Also, I can't think of any other community that matches the density of talented devs than right here.

That said, I am working on a project that uses the PHP port in hopes of gaining the same velocity and traction that I saw by using it in Flex.  There are potentially 3 facets: HTML, Ajax and AMF.

My thought is that I can have a single gateway for each service that shares the same business logic and CRUD routines with data formatting in the proxy based on the type of call. For AMF and Ajax, the application could enter a 'command' mode that does not technically have/need a view.  Commands and proxies would remain the same but the mediators may change to steward the request directly without the involvement of a view.  To display HTML, it would closely follow the example given in the download.

Does this seem right?  Has anyone done this before or can offer some new direction? Could the request itself serve as an abstract view of sorts? Removing the 'V' from MVC seems touchy.

Justin
Pages: [1]