Hi Alberto,
in addition to what Dan said, you could create an object similar to Business Delegates used for request/response remote calls - in applications that we have developed, we call these "Listeners". These listeners provide control and protection for your server push remote services. In here, you could implement functionality as recovery plans, disconnecting etc. In these listeners, we would typically subscribe to server-side shared objects. When we receive notification of changes to the shared object, we then convert untyped FlashComm data into VOs, before using the EventBroadcaster in our listener to broadcast events plus data. So the listener is really just another way of injecting an event into the Cairngorm architecture, other than a user-gesture. In this way, the commands are unaware as to whether the events that called them, and the data accompanying these events, was pushed from the server (via FlashComm) or generated on the client. Everything else about your Cairngorm architecture remains the same - using the ModelLocator for instance, to have your commands updating the model, and binding the view to the state of your model. Depending on the complexity of your application, we might suggest further refactorings, i.e. outsourcing functionality of listeners to other classes such as recovery plans. Best, Alex -- Alex Uhlmann Software Engineer iteration::two -----Original Message----- From: [email protected] [mailto:[EMAIL PROTECTED] Behalf Of Daniel Harfleet Sent: 30 August 2005 10:10 To: [email protected] Subject: [flexcoders] Re: Cairngorm question Alberto, this seems a fair approach to me, you may also want to include some logic to disconnect from the flash comm server when you know you are not interested in receiving updates and maybe even a 'recovery plan' for the service should the connection to the FCS be broken. rgds dan --- In [email protected], Alberto Albericio Salvador <[EMAIL PROTECTED]> wrote: > Hi all, > > The Cairngorm samples are a great resource for understanding how to best > arquitect an specific kind of applications; in this case, applications > that talk syncly with some servers that expose some services. > > Imagine now that Im building an application which implements, somewhere, > some kind of asynchronous services: a flash comm server chat , for > example. This "service" must be running, in the background, even if im > visually working in another part of the application, entering some data > for new providers or whatever. So the question is, where is the best > place to initialise these services? Or how can I place/work with these > services within this arquitecture? > > My choice would probably be to initialise evrything inside a > "initialise()" function in the model locator and then use some public > var there to control msgs and status of this "service" and then bind the > chat components to these vars. > > I hope someone can help chosing the best option. > > Thanks all in advance. > > -- > Alberto Albericio Salvador > Aura S.A. Seguros > Departamento Informática -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com YAHOO! GROUPS LINKS Visit your group "flexcoders" on the web. To unsubscribe from this group, send an email to: [EMAIL PROTECTED] Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. ------------------------ Yahoo! Groups Sponsor --------------------~--> Get Bzzzy! (real tools to help you find a job). Welcome to the Sweet Life. http://us.click.yahoo.com/A77XvD/vlQLAA/TtwFAA/nhFolB/TM --------------------------------------------------------------------~-> -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
