1) A delegate can contain many methods pertaining to a particuliar section of your app. So many command will use the same delegate. 2) No. 3) Why exactly are u looking to do? 4) If I eliminate it... then where is the sample :) IF you have view, then it will dispatch various commands to do the associate work of getList, create, load, save and delete... this is pretty typical. Dimitrios Gianninas RIA Developer Optimal Payments Inc.
________________________________ From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Jamie O Sent: Thursday, January 04, 2007 5:04 PM To: [email protected] Subject: [flexcoders] Cairngorm / MVC Best Practice It's Thursday afternoon, which means my bi-weekly "question everything I've just coded and contemplate serious internal changes on the project". This week the insanity relates to Cairngorm or perhaps Model View Controller design pattern in general, and the best practices of it's implementation. Short Questions: 1) How do you break up your commands / delegates? 2) Is there a way - similar to how a delegate can have a series of functionname_onResult, functionname_onFault - that you can have one command deal with multiple onResult scenarios? 3) Are there any examples out there which deal with these situations specifically? My googles have not lead to good details, but perhaps I'm just querying for the wrong terminology at this point.... 4) If you're delegate(s) are so simplistic to just act as a gateway, what would a sample look like where you eliminte it? Example Context: You have a screen (view) in which a user can display a list of tasks, select one to display, select one to edit, select one to delete, or add a new one. You'll also have a host of other functions with similar scope (Add staff, Add materials, etc) for arguments sake. Long Thoughts: My initial thoughts built up from Jesse's Amazon Web Service example -Create one custom event (Task) that has a sub-event type for each activity (list, display, add, edit, delete) as a series of constants defined in the event itself. -The execute function in the command (also a responder) would be a giant switch statement that passes off the different pieces of data from the event to the appropriate function within the command. -Each of these calls a delegate to hit a back-end service to get what is required of it and return the results to the command to update the model and the view responds accordingly. This breaks down when I have more than one function returning results from a delegate because I can only have one 'onResult' function within the command. How to code for the differences of if it was a delete action to return the view back to the list of task state versus an edit action to return to the display state for that updated task. My second intention is to create a specific command for each activity (TaskAddCommand, TaskEditCommand, TaskDeleteCommand) and keep the event as described above. But is doing the following in the controller adviseable: addCommand(TaskEvent.ADDTASK, TaskAddCommand); addCommand(TaskEvent.EDITTASK, TaskEditCommand); addCommand(TaskEvent.DELETETASK, TaskDeleteCommand); This is still plagued by the delegate having a huge amount of code just acting as passthru service, but would still be something that coding conflicts would arise on. If you're delegate(s) are so simplistic of just acting as a gateway, what would a sample look like where you eliminte it? Then I could stick with one event type with sub-types, each sub-type references a specific command which does it's own service call / response. Thx, Jamie -- WARNING ------- This electronic message and its attachments may contain confidential, proprietary or legally privileged information, which is solely for the use of the intended recipient. No privilege or other rights are waived by any unintended transmission or unauthorized retransmission of this message. If you are not the intended recipient of this message, or if you have received it in error, you should immediately stop reading this message and delete it and all attachments from your system. The reading, distribution, copying or other use of this message or its attachments by unintended recipients is unauthorized and may be unlawful. If you have received this e-mail in error, please notify the sender. AVIS IMPORTANT -------------- Ce message électronique et ses pièces jointes peuvent contenir des renseignements confidentiels, exclusifs ou légalement privilégiés destinés au seul usage du destinataire visé. L'expéditeur original ne renonce à aucun privilège ou à aucun autre droit si le présent message a été transmis involontairement ou s'il est retransmis sans son autorisation. Si vous n'êtes pas le destinataire visé du présent message ou si vous l'avez reçu par erreur, veuillez cesser immédiatement de le lire et le supprimer, ainsi que toutes ses pièces jointes, de votre système. La lecture, la distribution, la copie ou tout autre usage du présent message ou de ses pièces jointes par des personnes autres que le destinataire visé ne sont pas autorisés et pourraient être illégaux. Si vous avez reçu ce courrier électronique par erreur, veuillez en aviser l'expéditeur.
