It's really a matter of opinion, but I would say there is something to be gained from an explicit distinction between client-server communication and client-only communication. In reality, both are asynchronous forms of communication, so modeling it the way you are isn't wrong. However, server calls are, by their nature, different from other client-side-only communications in that they have to travel across systems. A few implications of this are that client-server communications
1) must be serializable 2) don't have the same reliability as client-only communication (though I suppose this could be argued/compensated for) 3) take longer 4) usually have some sort of callback (whereas client-side events usually don't) Again, this is all just conjecture and opinion. Your model certainly makes the mental bridge between the two worlds, making it easier for a developer to work in both worlds simultaneously. Distinct separation makes it easier for a developer to think about the implications above, and makes it more obvious to the person coming after them what the code is actually doing. That's my .02 On Mar 5, 2:18 am, Chris Lercher <[email protected]> wrote: > [Google groups seems to have swallowed my post, so I'm sending this > again] > > 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 more 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.
