Hi Devis, > If you look at the file Services.mxml I don't understand as > ServiceLocator.as the class you/he/she able does to memorize > all the RemoteObjects, don't I see containers? Can someone > explain me this file mxml??? > > <cairngorm:ServiceLocator xmlns:mx = > "http://www.macromedia.com/2003/mxml"; xmlns:cairngorm = > "com.iterationtwo.cairngorm.business. * "> > > <mx:RemoteObject id = "customerDelegate" source = > "com.iterationtwo.demo.business.CustomerDelegate" > protocol = "http" showBusyCursor = "true" > result = "event.call.resultHandler (event) " > fault = "event.call.faultHandler (event) "> > </ mx:RemoteObject> > > </ cairngorm:ServiceLocator>
So the idea of the ServiceLocator (as you'll know from j2ee) is to present an encapsulation of all service lookup; in RIAs we're talking about RemoteObject (tight java-coupling), WebService and HTTPService services. We used to advocate ServiceLocator as an ActionScript 2.0 class - it was a singleton class, with getInstance(), that encapsulated all the Flash Remoting integration that it was necessary to perform. However, Flex does *so* much more for us than plain-old Flash Remoting, so we made a decision for Cairngorm 0.9 to simplify the ServiceLocator down to an MXML file that is instantiated from your top-level Application, as a "registry" of services. By declaring all of your application services here, your business delegate can easily locate services, invoke them, and pass responses from the services back to the command classes that call them. In fact, by adding a ServiceLocator.as class with Flash Remoting logic in it (look at the ActionScript 2.0 dictionary for an example), you can use Cairngorm with Flash RIA as well -- we have done in the past (most recently for a project running in the National Space Museum in the UK !) and there are flexcoders on this list doing so as we speak. So - quite simply, declare all your services in the Services.mxml file, and then look at the business delegate class to see how the Service Locator is used to handle all the underlying invocation of services, and handling of asynchronous results. Best, Steven -- Steven Webster Technical Director iteration::two This e-mail and any associated attachments transmitted with it may contain confidential information and must not be copied, or disclosed, or used by anyone other than the intended recipient(s). If you are not the intended recipient(s) please destroy this e-mail, and any copies of it, immediately. Please also note that while software systems have been used to try to ensure that this e-mail has been swept for viruses, iteration::two do not accept responsibility for any damage or loss caused in respect of any viruses transmitted by the e-mail. Please ensure your own checks are carried out before any attachments are opened.
