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  Announcements and General Discussion / Public Demos, Tools and Applications / Re: ZamfBrowser - ZendAMF Service Browser on: March 09, 2010, 08:14:33
Invaluable tool and a much needed one.  Thanks!
2  PureMVC Manifold / Standard Version / Re: as3 and concurrency on: January 04, 2010, 03:20:39
Flash does not multi-thread so concurrency is never a concern for developers.  I can however, attampt to clarify how the notificationList is used as it relates to observers.

The observer array might change in the case of a notification triggering the creation of additional observers.  For example, if a notification response is to create a view component and that component has a Mediator with notification interests, Observers are created and added to that array prior to the loop completing but are not available until the next notification is sent. (again, no concurrency here)

The notification list itself is used just a single time as a map for creating observers when a Mediator is created.  If the list is altered at runtime after the observers have been created, nothing will result.  That being said, an immutable becomes superlative.

@cliff - this was what I gathered as I was doing the MooTools JS port.  Is this accurate?

3  PureMVC Manifold / Standard Version / Re: Problem with pmvc php port on: April 29, 2009, 03:47:15
Are you receiving any errors in the script?

Try pasting atop your index.php and run it again.
ini_set('display_errors', '1');
4  PureMVC Manifold / MultiCore Version / Re: Pipes, Fabrication - Excessive? on: April 21, 2009, 09:09:24
After posting this last one, I thought how I might be wasting your time.  It's silly to think that such a simple and trivial adjustment to the architecture could have a remote possibility of replacing Pipes which was very well thought through by an incredibly experienced programmer prior to it's release.

The problem with plumbing Module A to Module B is that Module B may or may not exist in every case.  Also, any 2 combinations of 5 total modules are active at any given time and the only common denominator is the shell.  The shell has the responsibility of loading and destroying the modules so the safest approach was to route everything through the shell.

Besides, Module to Module plumbing wasn't in the examples and Pipes are the damnedest thing to catch on to when you have a hard and fast deadline.
5  PureMVC Manifold / MultiCore Version / Re: Pipes vs. Notifications: I'm Confused on: April 21, 2009, 08:49:22
Truth be told, I started as a self taught hobbyist and have only been working professionally for less than a year.  I'd like to think I have a pretty good grasp on OOP and Flex for that matter but I love being reminded daily that there are people out there that can run circles around me. 

Just to clarify, by 'promote' I mean compiling them directly at the shell level versus loading them externally.  To me a true module is compiled separately, loaded externally and then instantiated.

 I like your idea of a command module that acts as a hub of sorts, hit the reset and the active connections are severed.  The delegation of tasks to dev's on a particular module is the moneyshot.  All they have to know is the UX/UI, the data it should consume and the data it should spit out, the rest is irrelevant. 

I'd like to get a download from you on this idea in a little greater detail sometime.  I have a project that is just starting that can benefit from your technique.
6  PureMVC Manifold / MultiCore Version / Re: Pipes, Fabrication - Excessive? on: April 21, 2009, 10:09:22
The main reason I took a closer look at Pipes and an alternative was because I found myself writing huge ShellJunctionMediators and ShellMediators just to handle the volume of notifications that needed to be redistributed to each of the loaded modules.  Often times the shell could care less about the notification or message since the bulk of the logic is in the modules.

The chain of events seemed excessive; from the module, an event was dispatched by a control, picked up by the module's mediator, converted to a notification that was picked up on its JunctionMediator, a pipe message was sent from there and picked up on the shell's JunctionMediator, then in went round again to each module as a pipe message where it had to be converted to a notification which was picked up on the mediator and finally acted upon as necessary.

Profiling the execution times gave me values at 50-150ms for Notifications to reach their destinations and longer if I factored the PipeMessages into the equation.  Lots of array iterations and switch cases to go through.  Cumulative array instances from listNotificationInterests where in the thousands after just 5 minutes of usage in this particular test.

Type checking can/should be done at the receiving end anyway for notifications, module or not.  Here is a thought, notification names are registered to the Controller via registerCommand(), why not register the notification body type in a similar manor?  e.g. registerNotificationType(notificationName, typeClassName).  Notification names must exist in the registry with an associated type before they are valid.  Sending a notification with a mismatched body type results in a failure prior to the creation of the Notification Object.  This seems like it would solve that problem with a lot less work and remove the ambiguity from notification body in all instances, multiCore or not.

What are your thoughts?

7  PureMVC Manifold / MultiCore Version / Re: Pipes vs. Notifications: I'm Confused on: April 21, 2009, 08:15:54
Very true.  Development planning usually involves some level of cost/benefit analysis for module candidates here. As a result, very little duplication will exist between modules and the shell.  If the candidate does not or will not reduce download or execution time significantly, I'd just assume promote it to the shell and call it good.

Since an empty module has a ~28k overhead by default, I use its compiled size as one way to gauge how much or how little the benefit is for module use.  If the module is 30k, I know the differential is ~2k and the shell will only increase by this amount if it were promoted.  This is probably not a good module candidate.
8  PureMVC Manifold / MultiCore Version / Re: Pipes vs. Notifications: I'm Confused on: April 20, 2009, 02:17:44

...And finally, don't expect that modules are going to reduce your main program size. It would seem so, but it generally isn't the case. This is not due to PureMVC, but Flex....

Modules took our app from 2.6 megs to less than 1 with 5 modules.  Hands down, the trick was to use interfaces exclusively on the shell anytime the module was cast, referenced or declared.  It seems that Flex likes to 'promote' the module and any class contained within the module to the shell if it is cast or referenced directly, thus increasing the filesize of the shell and decreasing the filesize of the module.

do this: protected var myModule : IMyModule, not this: protected var myModule : MyModule.
do this: protected function getMyModule() : IMyModule, not this: protected function getMyModule() : MyModule.

Also, any child or class that is exposed to the shell in any way should not reference, cast or declare the module either, this goes for commands, proxies or mediators that may be registered to the ApplicationFacade on the shell.  Use interfaces instead.

You get the idea.  Modules, always reduce filesize of the shell when structured correctly.
9  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);
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.

10  PureMVC Manifold / Demos and Utils / Re: BasicDemo - A PureMVC / PHP Demo on: April 18, 2009, 08:55:06
Brilliant Demo!  I have to say that this port and demo is inspiring.  Very well done guys!  This is a must have for all current and future PHP projects in my book.
11  PureMVC Manifold / Standard Version / PureMVC use in Ajax/AMF Gateway on: April 18, 2009, 08:47:29
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.

12  Announcements and General Discussion / Architecture / Re: Handling Async Startup Data Dependencies on: April 08, 2009, 03:04:15
If you are using the Flex framework for your application, there is a nice hack you can use to "stall" the application initialization until your dependencies are locked and loaded. 

In your shell, you can override the public setter 'initialized' and insert a conditional that allows the app to initialize only when your dependencies are finished loading.  This is a technique that I use for the very reason you indicated.  The code might look like this:
* Flag that is set to true when the final dependency is loaded
protected var _dependenciesLoaded : Boolean;
* Flag that indicates whether or not we are 'waiting' for our dependencies to load
protected var _dependenciesPending : Boolean;
* Override initialized and stall the application until
* all dependencies are loaded
override public function set initialized(value : Boolean) : void

* Handles dependencies before starting up the application
protected function handleDependencies()
    if (!_dependenciesPending)
        facade.startup(this); // Allow PureMVC to start so you gain access to your proxies
        // Code to load all dependencies goes here
        _dependenciesPending = true;
    if (_dependenciesLoaded)
        super.initialized = value; // We have loaded all dependencies, allow the app to start
        callLater(handleDependencies); // Check again on the next frame

This is the setter in all UIComponents that dispatches the CREATION_COMPLETE event when set to true by the LayoutManager after all phases of instantiation have completed.  Unless this is set to true, the default Flex preloader for your application will remain on screen in the "Initializing" state preventing all user interaction.

I use this as an alternative to the CREATION_COMPLETE event when starting up Pure MVC in all cases since I want to guarantee Pure MVC is started BEFORE the CREATION_COMPLETE event is dispatched.  I found this to be a bit more reliable since I cannot always have direct control over the order of execution of handlers listening for this event especially in a multi-dev environment.
Pages: [1]