[Arp] Arp use cases, case studies, success stories, etc.

[Jed Wood]

> Your custom caching system sounds interesting. Would you mind  
> giving us
> more info about it?

Yeah, I sent a few questions out when I first got into ARP this  
summer about how to include it in the framework. I finally settled on  
something that works great for me, but not sure how it would be for  
anyone else. It's based on an old system that I wrote about (article:  
http://www.actionscript.com/Article/tabid/54/ArticleID/simplified- 
flash-remoting/Default.aspx ) which Aran Rhee modified, which I then  
modified again :). The basic idea is that when a call is made to the  
server, you include with it an optional "cachetime" parameter. Every  
call to the server goes through this cache delegate/manager/gateway  
class. If that cachetime parameter is set, the data returned from  
that call is saved in a Local SharedObject. Then, the next time that  
call is made, it checks the actual values of the parameters, sees if  
there is data stored for that same call, and checks if it's "fresh"  
according to the timeout parameter. If so, it returns the stored  
data. If not, off to the server it goes.

It's helpful for me particularly because I often push some decent  
sized remoting calls (large xml strings, nested arrays of  dozens of  
objects, etc) that don't change that frequently, and it's nice to  
have no lag for a user that goes to view a previously-viewed data  
object.

So for my little ARP setup, any commands that need to make a server  
call do it something like this:

public function executeOperation (evtObj)
{
	var bd:BusinessDelegate = new BusinessDelegate(this);
	bd.getDetails(evtObj.data.id);

}

And then the return comes back via:

public function onResultOperation(evtObj) {

	var ml = ModelLocator.getInstance();
	ml.details = evtObj.result;
}

As you'll note in this example, the command doesn't notify any views-  
they're already listening for updates to the Model. The command  
doesn't know or care where the data came from, and neither does the  
ModelLocator.

The BusinessDelegate has the decision of whether to make a  
"cachedCall" or not, and for how long the data should be considered  
"fresh."

It calls the method on my "RemoteManager," (hence the "rm") which  
uses a the ServiceLocator to finally determine where to send the  
call.  RemoteManager sends responses directly back to the Command  
(unless a different Responder is specified), and Command updates  
Model, which sends out events.

Whew! Did you follow that chain? Command->BusinessDelegate ->  
RemoteManager -> ServiceLocator -> backend :: -> RemoteManager ->  
Command.onResultOperation -> ModelLocator.someSetter -> broadcast to  
listener views.

I completely follow "convention over configuration" through the whole  
system, and consequently end up with Commands that are almost all the  
same as you see above, and a bunch of BusinessDelegate methods that  
are all very similar. And I'm sure it seems like way too many  
unnecessary steps. I could probably lump BusinessDelegate and  
RemoteManager and ServiceLocator into on simplified class, but I  
don't mind. Once I got it all set up, adding new commands and calls  
is a snap. Once I add a few initial lines to the BusinessDelegate and  
make a Command, I can go for a long time just working between the  
ModelLocator and the views. It's been working well for me, and still  
leaves me the flexibility of adding more logic to any specific  
command if I want to, or to the BusinessDelegate method, or whatever.

Dang. I thought that would be a short answer. sorry.

-Jed