Here's my approach when designing something like that. Any validation should happen immediately client side since that is one of the major benefits of using AJAX. Doing an RPC call every time a field loses focus is pretty inefficient - I think doing it this way is too easy to make it a crappy experience for your users (now if the validation needs to access some kind of resource that isn't available from the sandbox, that's a different story, although that doesn't seem like a validation that should happen instantly).
In fact, if you do it right, you can share most (if not all) the validation code between client side & server side. Then when the user presses save, the data is sent off to be saved at which points it gets actually validated (once) on the server. This approach has the following benefit: Lower server load - you're not making multiple RPC calls to process 1 form. Lower client load - you're not making multiple RPC calls to process 1 form Better user experience - validation happens instantly instead of requiring a round trip to the server. Also, what happens if the server happens to be down at that particular moment? Handling the failure of 1 RPC point is much easier conceptually than multiple. Remember - RPC calls cost in terms of processing power (2 times serialization & deserialization) & bandwidth. To top it all off, if this is a form that has some kind of save button anyways, you are going to double the amount of validation you need to do - once when the user enters the data & all over again when they hit save. So the architecture for your program is not taking advantage of what Javascript offers which is to offload work that the client can do. Anything & everything that can be done by the user, should be done with the server doing minimal work & being stateless. The server should, IMHO, be a dumb machine that just processes requests & responses immediately. All state goes to the client, persistance goes to the database. The validation is a small little layer of business logic that sits between the servlet & persistance layers to ensure valid data, permissions, etc. If any state information is needed for the server, then the client is responsible for supplying it (of course you need to be aware of validating this too - depending on the application, you may want to keep track of the state in the DB. In all my apps I've been able to architecture it so the state was not important for the server, but that isn't saying much). On Tue, Apr 28, 2009 at 2:44 PM, AirJ <[email protected]> wrote: > > Thanks for all the help. > > Vitali, I cannot simply disable the "save" button since our field > validation happens when field loses focus. If I disable "Save" button, > user will be confused. > > Jason, yes, I do have a similar AsyncCommand package that does the > command chaining. The problem is, our UI is driven by metadata. The > logic is prettty complicated at the client side. Even chaining > commands are making the code convoluted. > > Denly, thanks for the suggestion. I finally decided to follow your > advice and implemented our own "flush" mechanism. It works perfectly! > > On Apr 28, 7:43 am, Jason Essington <[email protected]> wrote: > > So, you click save, then each field is validated individually via an > > RPC? > > > > One trick is to chain your RPC Calls. I have an abstract Callback that > > implements Command and also has a field to hold an additional Command. > > CommandCallback the execute() method is able to Fire the RPC that is > > handled by the callback, and after onSuccess() is processed any > > command added to the callback is executed (another commandCallback for > > instance) that way you can create a whole chain of RPCs and call > > execute on the first and each will be sent in sequence. > > > > to prevent the save button from being pressed again while these RPCs > > are executing you can disable the button, and enable it again as a > > final command in the chain. > > > > Of course, if you can combine all of these RPCs into a single request > > you'll have better performance. > > > > -jason > > > > On Apr 27, 2009, at 6:33 PM, AirJ wrote: > > > > > > > > > Hi GWT gurus, > > > > > I have a generic questions regarding asynchronous calls. Basically in > > > our gwt web application, when user clicks on "save button", the > > > application launches a bunch of asynchronous calls(validation, server > > > side callbacks). > > > > > "Save" should only be invoked when all those asynchronous calls are > > > processed. > > > > > One way to do it is to call "Save" in the onCallbackSuccess() method > > > of those asynchronous calls. But it will make the code very > > > unstructured and hard to trace. > > > > > Essentially I need a method to flush all the queued asynchronous calls > > > before I make a new one. Will > > > DeferredCommand.addCommand() solve the problem? > > > > > Thanks, > > > Di > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
