convore.json/groups/robotlegs/mediator-vs-commands/messages.json

[{"user_id": 16213, "stars": [], "topic_id": 13330, "date_created": 1300278139.6648171, "message": "How you deal with views communicating with models/services. Do you write a command to handle the communication, which leads to command folders bloated with command files containing one liners, or you handle the communication in the mediator, and potentially making your application less readable in a glance?", "group_id": 2570, "id": 364750}, {"user_id": 20237, "stars": [], "topic_id": 13330, "date_created": 1300281258.4406879, "message": "As I see it when a view/mediator dispatches a event, it is listened for by the context which runs a command. Models can dispatch events that mediators listen for", "group_id": 2570, "id": 365362}, {"user_id": 11098, "stars": [], "topic_id": 13330, "date_created": 1300357488.9939921, "message": "Brief commands are the best kind IMO, provided they're named well. UpdateCompanyContacts or RestoreLessonCheckpoint - you don't need to read the code to know what it does, the file name tells you.", "group_id": 2570, "id": 372838}, {"user_id": 16213, "stars": [], "topic_id": 13330, "date_created": 1300360658.6590519, "message": "It will not help readability if you have more then 20 commands and  events signals pairings, I found this interesting http://www.xxcoder.net/maps-maps-and-more-maps", "group_id": 2570, "id": 372951}, {"user_id": 11126, "stars": [], "topic_id": 13330, "date_created": 1300375938.281426, "message": "You can either make RemoteProxies, which are Models that wrap the Service class(es) in question, or AsynchronousCommands. The former works great in smaller projects where your Models are small and usually only wrap 1 service. For larger projects, AsyncrhonousCommands are where it's at because yes, you'll have a lot of Commands and this helps halve all the service calls AND handle the response in the same place. Additionally, as with all Commands, you know exactly who's setting your data, and how.", "group_id": 2570, "id": 374981}, {"user_id": 11098, "stars": [], "topic_id": 13330, "date_created": 1300437304.0694349, "message": "@Leon - I use bootstraps and packages to break large sets of commands into smaller groups. And modules to separate features into their own contexts. If you have 20 command/event pairings then a 'controller' approach would be just as unreadable - if not more so.", "group_id": 2570, "id": 380576}, {"user_id": 16213, "stars": [], "topic_id": 13330, "date_created": 1300445229.985472, "message": "@jesterxl can you please elaborate on RemoteProxies, how they different from Services? @Stray can you please elaborate on bootstraps.", "group_id": 2570, "id": 381073}, {"user_id": 11126, "stars": [], "topic_id": 13330, "date_created": 1300548166.1558981, "message": "@LeonGauhman They're the same thing PureMVC calls \"RemoteProxies\". You take a Model, put a Service in it, and expose a method to call the service. The pro's to this approach is that you can quickly prototype/develop your Mediators' to call a method on a Proxy to get the data it needs, and the Proxy handles all the normal Application logic of \"where it goes\", \"how it changes\". Since it's all in the same class, and the class rarely exceeds 300 lines of code, it works great and is pretty self-contained. It also works great for polling situations and makes writing caching easier.", "group_id": 2570, "id": 388601}, {"user_id": 11126, "stars": [], "topic_id": 13330, "date_created": 1300548516.8261349, "message": "@LeonGauhman The downside is that this doesn't scale very well, and the Application logic of one Model's data affecting another still requires a Command, violating the need for a self-contained Model. Additionally, Services don't really need to extend Actor if you do this, instead EventDispatcher or Signals. Mediator's making more than 1 service call becomes a code smell. While having just 1 Proxy set data on itself is great, this rarely stays this way as your code grows. Re-factoring to Commands is easy, though, so if you start this way and hate it, it's not hard to get out. What is a pain is if you don't use AsynchronousCommands, you have to re-factor your Services to Actor.", "group_id": 2570, "id": 388625}, {"user_id": 11098, "stars": [], "topic_id": 13330, "date_created": 1300613708.2772241, "message": "@LeonGauhman Bootstraps are just Commands that do your wiring, and are themselves wired in the main context to ContextEvent.STARTUP. You can have a Bootstrap per feature or per type (Models, Services, Mediators etc). There's lots about this on the robotlegs forum - best to search there if you want more detail / background.", "group_id": 2570, "id": 391590}]