Grabbing the low hanging fruit

I’ve just come out of Aral Balkan’s FOTB talk entitled as above, so I decided to take his advice – if you have an idea put it out there.

Basically, this is an idea I’ve been working on and humming and ahhing over, but now I’m going to tell you all about it, so that I don’t have the excuse not to do it.

Its a big idea, but I’m going to start it off small.

Anybody who reads my blog (LOL that’ll be [email protected], plus one or two who have wondered off the main track into strange waters) will know that I’ve been playing with pureMVC for a while now and one of the main problems that I have with managing pureMVC projects is that the controller / observer actors do so good a job at decoupling themselves.

This means that I have a real problem organising and managing my commands and notifications because I can’t find them easily. This is doubled if you are using a state machine to rewire all the commands dependant on state.

wouldn’t it be fantastic if you could fire off one notification that would
1) cause a whole string of commands to be executed in order, whether they are
2) synchronous, or
3) asynchronous,
4) make decisions along the way, including
5) user defined ones (ie alert boxes),
6) carrying with it data from the invoker,
7) and then spit out the result with another notification to be picked up by any interested parties.

well, I think it would.

What I’m taking about is encapsulating the flow of commands into a single data source (XML,JSON, whatever).

Once that has been done, we can

1) not only load it into your application to tell it how to wire itself up properly,
2) rewire your application, without recompiling
3) rewire your application at runtime depending on state
4) if the command classes are compiled into a runtime swc or swf you can also rewrite your commands without without recompiling your whole app
5) you can use other programmes to look at it, in far prettier ways than the native data format (XML ain’t that human readable)
6) you can edit it and re-organise it
7) you can even use it to create stub code.

Now, I’ve already started down this path, I’ve done a quick prototype of a data driven command sequencer, and I’m just starting to rebuild it as a more solid framework, though I really don’t have anything to show at the moment. But I shall keep you all posted here. It would be great to get some feed back as to whether the idea is good or not, maybe some one has already, or is in the process of doing this themselves.

But most of all, I’m writing this to encourage me to actually do it.

4 thoughts on “Grabbing the low hanging fruit

  1. neil, that sounds like a good plan. will you be creating a branch of puremvc – the singleton-free one NATURALLY – or is this an independent engine that can plugin if need be? or something else even?

  2. it’ll be a utility, so it will “plugin” to any puremvc project (even the standard singleton heavy one ) by extending it.

    basically it’ll be a mini frame work within the puremvc frame work, that you can extend for individual implimentation. The aim is to be able to remove all the registering of commands. All notifications will be sent to the “ChainSequencerManagerUberProxy”, which will hold the model.

    I remember Rich, that you had the problem of tracing the interested actors for a specific notification. I find it hard enough in my code, let alone looking in someone elses. This way, it’ll all be declared in a single data object.

    Once I’ve got that working and out there, I want to create a tool to make the planning editing and managing of all those danged commands. And finally to make stub code. That should keep me occupied til I’m 64.

    Thanks for the interest Rich

  3. Pingback: » Blog Archive » pureMVC Studio

  4. Pingback: Domino rides again «

Leave a Reply

Your email address will not be published. Required fields are marked *