Hi Chris, it's hard to say in general. But one thing I think is very important, is the question which events are independent from each other, and which are not. Can they be processed simultaneously? Do some of them require a certain ordering? Is it easier to analyze (and later debug) what will happen, by having some central algorithm coordinating the actions (which can be achieved easier with a command pattern)? Or is a very loose coupling more important (if you will have to add listeners you know nothing about yet, and which no central algorithm should be aware of - like in the case of plugins)? Such flexibility comes at a cost - it increases complexity, and makes program flow less controllable. So I think, it's a good idea, that you have (as you mention in point 3.) something on your server side, that distributes the events. I'm not sure, if the client would need a bit of control, too - this depends, on what the server side knows about the application state. It may mean, that you have to group several events on the client first, before you know, what to send to the server.
Also: Is it good, necessary or bad to wait for all of the threads to finish before something can be sent back to the client? There are certainly a lot of factors involved, these are just some things I was thinking about when reading your post. hth Chris BTW, in a way, events are commands. They just usually don't contain any code. The opposite of the command pattern would be a lot of individual service methods. On Mar 4, 8:40 pm, Chris <[email protected]> wrote: > Hey All > > Does anyone see some flaws with the following kind of framework? The > idea is to remove the need for a command pattern for UI-server > communication and have just events flying around. I believe I posted a > similar thread ages ago, but this is subtly different. > > 1. UI fires event to event bus. > 2. Some events are registered as server events (maybe through the > extension of a ServerEvent, or ServerClientEvent for both) > 3. The event gets sent to 1 service on the UI side > 4. The service has got event handlers registered and distributes the > events to the correct handlers (perhaps using threads for concurrency > so that all your server operations can happen simultaneously) > 5. It then waits on all threads to terminate (of course there could be > only one!) > 6. It groups all the responses together > 7. Sends responses back to the client > 8. UI fires off a response received event specific to each of the > responses received > 9. UI registers those responses and processes them -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
