Having problems with message search?
However, I wouldn't kludge up your service locator - sure make it so you can manipulate it, but I would keep focused - just a service locator and nothing more. You could split hairs about where the manipulation logic lives. I happen to like using model locators and using binding.
Hi Jeff - I can be as pragmatic as the next developer but if you're interested here's a sketch of the hair splitting version :-).
<?xml version="1.0" encoding="utf-8"?>
<business:ServiceLocator xmlns:mx="http://www.adobe.com/2006/mxml"
xmlns:business="com.adobe.cairngorm.business.*"
xmlns:messaging="mx.messaging.*">
<messaging:ChannelSet id="channels"/>
<mx:Consumer id="someConsumer" channelSet="{channels}"/>
<!-- Other services, bound to channel set as required -->
<mx:Script>
<![CDATA[
import mx.messaging.ChannelSet;
import com.adobe.cairngorm.CairngormError;
import com.adobe.cairngorm.CairngormMessageCodes;
/*
Strongly typed accessor for ChannelSets
This would be trivial if getServiceForId was protected instead of private
(there's a suggestion for next version Steve)
*/
public function getChannelSet( serviceId : String ) : ChannelSet {
if ( this[ serviceId ] == null )
{
throw new CairngormError(
CairngormMessageCodes.SERVICE_NOT_FOUND, serviceId );
}
return ChannelSet(this[ serviceId ]);
}
]]>
</mx:Script>
</business:ServiceLocator>
As you can see you can still use binding. The business delegates responsible for setting up your channels can use the accessor we've added to our subclass.
I always feel there's a particular danger that the ModelLocator can become a sort of global variable dumping ground (read Rod Johnson on why he doesn't like singletons) so as a defence I try to stick very closely to the intent of the model in MVC - that is, stuff that the view is displaying like VOs, or sources of binding for currentState. I think channel sets are internal to the business layer and it's services, and the ServiceLocator is the closest thing we have to a model for the business layer. I wouldn't stop at channel sets either - I think that the ServiceLocator is a natural place for validators and other instances of shared business services, not just remote services.
Cheers,
Robin
| ROBIN HILLIARD Chief Executive Officer robin@... RocketBoots Pty Ltd Level 11 189 Kent Street Sydney NSW 2001 Australia Phone +61 2 9323 2507 Facsimile +61 2 9323 2501 Mobile +61 418 414 341 www.rocketboots.com.au | ||
On 02/04/2008, at 9:08 PM, Jeffrey Battershall wrote:
Gareth,I'm a little late to this discussion, but I thought I through in my two cents. In your service locator you can bind the channelSet attribute to a dynamically created channelSet that is stored in your model locator. You create functions/ui to manipulate that model and the service locator, as a binding destination, will "know" about the model. However, I wouldn't kludge up your service locator - sure make it so you can manipulate it, but I would keep focused - just a service locator and nothing more. You could split hairs about where the manipulation logic lives. I happen to like using model locators and using binding.
Offline 
Send Email