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
