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
PureMVC Architects Lounge
Port to PHP
Topic: Registering Commands (Read 11829 times)
October 21, 2009, 02:54:01 »
So I've gotten a bit further in my work in php pureMVC, and I've run into another - "Am I crazy to do this?" type question.
From what I've seen, the Facade seems to be the recommended place to register commands. But in the stateless world of web apps, it doesn't make a lot of sense to register a whole lot of commands until you've done a bit of bootstrapping and have an idea of what is being requested of the application (and therefore which commands to register and execute).
So where I got in my app building:
* register a macro command to handle startup (bootstrapping)
* start the app by sending a notification which is handled by that command
* In that command load db configuration information from an .ini file
* set those defaults in my db_connection class which will be available to any proxies that care to make use of it
At this point I'm ready to sort out what is being requested - to do this I want to make use of a router/dispatcher that will take action based on the URL.
I figured the best way to do that would be to execute a 'router' sub command that parses the URL and in turn registers an appropriate command to handle what is being requested. Then the only thing left to do would be to send notifications to those newly registered commands (passing along arguments from the URL).
So, does that sound crazy? i.e. having commands registering commands. I can already foresee situations when newly registered commands would still in turn register yet more commands.
Crazy or not, I can't think of any other way to lazy load what I need.
Re: Registering Commands
Reply #1 on:
October 21, 2009, 09:46:44 »
This is certainly a valid path.
However, registering all the commands in the system in one whack should not be taxing on the server, since new Command class instances are only created at execution time. You're really just loading up an associative array with a bunch of key/value pairs.
The value in this is that the registrations all happen in one place, so you never find yourself in a situation where a command needs to fire a notification to trigger a command that might not yet be registered, causing a silent fail that may be hard to debug. You are always absolutely sure that all the commands are registered and will respond to their mapped notifications.
Also having the Commands know each other in order to do the registrations is more tightly coupled than one would really want.
Last Edit: October 21, 2009, 09:48:42 by puremvc
Powered by SMF 2.0.15
SMF © 2006-2007, Simple Machines LLC
Content © 2006-2018, Futurescale, Inc.