OK, so this is an experiment that I have been pondering and working on for about six months now.
Its code named Domino, and its function is to enable non linear execution of commands from an external data source.

The main reason I started on this is that in previous complex projects I have had problems managing my command structures, especially those which involved chaining them up.  I wanted to be able to visualise them, so I started drawing diagrams of command processes.

anyhow what i had originally intended (while still maintaining the core idea) has become something else entirely, and the scope of the final project scares me a bit (i'm about 1/100 of the way through it).

I have all the core code functioning, and am busy writing a real world demo (a flick book application for my wife's art project), but I'd like to explain the concept and get your feed back, as I'm not sure if it is just quite an interesting experiment, or if it actually has any real world value.

I appreciate you taking the time to read it:
http://revisual.co.uk/?p=386

cheers

hi cliff

another one for your very long queue (if you like it) :)

a very simple implementation of a State Machine which I have found very useful in combination with trilec's chain utility to manage my command structures.

code on my google code svn here: http://code.google.com/p/puremvc-utilities/

and a quick tutorial on my blog, here: http://revisual.co.uk/?p=237

cheers

Hi cliff

just wondering what you thought of the idea of having some kind of top level interface package in the utilities package.
I was thinking of future proofing issues... as in you have lots of people writing some great utils, and some way of promoting loose coupling between them would be great. I mean what happens if I want to use an existing util in one that I am writing, but don't want to couple it tightly to it, so they have to be used together.  Also common interface like IFactories and IEncodeables could use the same interface throughout the utils package.

this would of course need to be standardised and mediated.

i hope this has made sense.

what do ya think?

http://revisual.co.uk/?p=169

Hi, I've been working on an assets loader, with the aim of it being a simple, stripped down framework that can easily be extended, and to be primarily used within the pureMVC framework (though it dosn't have to be)

Why do we need another "bulk loader"? Well, I think that the ones out there at the moment rely too heavily on Static data registries (no need in pureMVC, right), and have too much internal logic to "decide" what type of loader to use, and then to parse it. 

What I wanted was a loader that allowed me to treat all the many ways of loading data in the same way, yet to do so in the same way that the native classes would.

I mean that if I load an xml file, I want it to be loaded as a string, and allow me to parse it into an XML myself.

please take a look, its in an early stage at the mo, I'm happy with the architecture, but it needs proper testing. You can have a look here http://revisual.co.uk/?p=80.

In the spirit of the open source community I would like to offer this up to you guys as a pureMVC utility (if you like it), that I would be happy to develop and maintain. :~)

cheers

fleecie

Ok, I'm writing a set of utilities for pureMVC

and I wanted opinions regarding packages, and the best practice.

at the mo, my packages are name like this:

uk.co.revisual.puremvc

so all my code implemented using pureMVC is in this package. Is this acceptable, and easy to port to other peoples class libraries without too much confusion?

thought I'd share this asset loader util implimented in pureMVC that I've written.
not really ready for use yet, as its in early non tested phase, with some features still to be implimented.
at the mo its on my blog:

http://revisual.co.uk/?p=38

but I may transfer it to a googlecode page

would be interested in any comments

not that I have anything against singletons, but I know a few people who just won't touch them.

So for their sakes, and as an intellectual exercise, I have removed them all.

practically speaking there is no difference for the user except two things.

you don't have to write a static singleton factory method on the extended facade, and in the extended facade's constructor, you need to send up a reference to itself in the super:

public function ApplicationFacade():void{
   super(this)
}

find source code here
www.revisual.co.uk/uploads/singletonlessPureMVC.zip

I was wondering why you chose to have to Model, View and Controler classes as singletons??

because the facade is a singleton, and the 'best practice'  route is through the extended facade, then the facade can manage its MVC unique instances. It could also manage its concrete ApplicationFacade's unique instance, allowing access to it by the Notifier class.