convore.json/groups/robotlegs/robotlegs-events/messages.json

[{"user_id": 11632, "stars": [], "topic_id": 42351, "date_created": 1311172103.6866341, "message": "One thing I've been wondering for a while now, and of which I don't really see the major benefit is that Robotlegs uses event to decouple application layers.\n\nFor a basic save operation you've got the following flow:\n\nmediator --> savePersonEvent --> Command --> Service call -->PersonSavedEvent\n\nImo decoupling with interfaces would be sufficient and it wouldn't make it hard to follow the application flow. The above flow could be simplified to (where the command and service call return an async token):\n\nmediator --> Command ---> Service call\n\nIn the above case the command would be injected into the mediator, and the service into the command. The command would have a ISavePersonCommand which would look like this:\n\npublic interface ISavePersonCommand {\n      function set personToSave(person:Person):void;\n}\n\nFollowing a certain usecase flow is one of the biggest disadvantages when using robotlegs (for me) because I have to search which Command is mapped to which Event, and which mediator captures which model/service event.\n\n\nWhat are your thoughts on this?", "group_id": 2570, "id": 1681247}, {"user_id": 11632, "stars": [], "topic_id": 42351, "date_created": 1311178887.3251569, "message": "One thing I forgot while writing my previous post is that every command execution should be on a new instance. So I came up with this solution:\n\nContext setup:\nmapCommand(ISavePersonCommand, DefaultSavePersonCommand);\n\nIn the mediator:\nvar savePersonCommand:ISavePersonCommand = ISavePersonCommand(createCommandAs(ISavePersonCommand));\nsavePersonCommand.personToSave = person;\nsavePersonCommand.execute();\n\nthe createCommandAs method would be some syntactic sugar in the Mediator class, which in the background would just call the injector.instantiate() method if I'm not mistaken.", "group_id": 2570, "id": 1682255}, {"user_id": 11632, "stars": [], "topic_id": 42351, "date_created": 1312140789.268688, "message": "Any ideas or remarks?", "group_id": 2570, "id": 1760081}, {"user_id": 7782, "stars": [], "topic_id": 42351, "date_created": 1312210021.8327651, "message": "another approach that people use is a Controller, or a class that carries a stack of command messages and is injectable across other actors. A Controller can also conform to an interface. Each method on the controller would simply execute a command. It gives you a bit of what you are discussing above, but without modifying or extending the core framework classes to get there.", "group_id": 2570, "id": 1766490}, {"user_id": 11632, "stars": [], "topic_id": 42351, "date_created": 1312833479.8410051, "message": "That's a great alternative to what I suggested, didn't think about that! Will have to roll my own Command class though so the execute method returns an asyncToken, but that's easy.\nSo I've got two options now, your suggestion and roll my own Command, or my suggestion and extend the Mediator class which implements the createCommandAs() method. Thanks!", "group_id": 2570, "id": 1824510}]