Patterns for Boxer, II

Hey, I've been doing other things too, these past two weeks.  Still, it's been quite a struggle getting a Cairngorm framework constructed, at least one that makes sense for what I'm doing with Boxer. 

So here's a vague description of the Boxer frame-up. Actually, this is more a step-by-step showing construction of a sketch of an idea of what a Boxer implementation might look like. Not drawn to scale.

ModelLocator variables

Gripe: docs and blogs make a big deal about implementation of the Singleton pattern, neglecting an explanation of how, and in what circumstances, a model locator might be useful. And isn't there a better, cooler name for these model locator variables than "variable"? Shrug. /  Here they are:

• boxCollection box(es) and contents
  
• alphaBoxCollection top-level box(es) in the system
  

It's a nested set database where records represent things.  Things are box-like and thus may (or may not) contain other things/boxes. Etc.

Next steps

• build AList.mxml view component to present the alphaBoxCollection in a list.  The component extends List and the data provider is set by dataProvider="{model.alphaBoxCollection}".
  
• build getAlphaBoxesEvent to populate the alphaBoxCollection,
  
• which begs for an entry in BoxerController defining the Event+Command link-up, matching the getAlphaBoxesEvent to the...
  
• getAlphaBoxesCommand, the lazy assistant manager who hands off to
• getAlphaBoxesDelegate (in the /business folder) the chore of contacting the server. Of course, it in turn has
• getAlphaBoxesResponder take care of whatever comes back from the server.  The crucial code in the responder is

BoxLocator.getInstance().alphaBoxCollection = new ArrayCollection( event.result as Array );

•  ... which refills the alphaBoxCollection with whatever the server returned in event.result.

And that's the round trip, from button click that fires the getAlphaBoxesEvent to a refresh of the list view.  Not too bad once you get the hang of it.