SmartGWT GWT client server architecture

Question

We plan to use smart GWT, GWT and related frameworks for the client side rich interface and Spring MVC which returns JSON data on the server side.

As part of the investigation to see if it fits our requirement, the following questions need some answers :

1. Building a GWT application from scratch without using any frameworks will need considerable amount of effort to follow the standard MVP pattern. But this is more flexible and unit testable, though time consuming. GWT best practise suggests using MVP design pattern for building larger applications.

SmartGWT has its own approach, where you use a widget, introduce a datasource into it and you are done. Yet to identify the best practise around building such smart GWT components in a modularised (or MVP) fashion. Any suggestions

1. Using framework GWT-platform and SmartGWT could be an option to try MVP architecture as mentioned here. Any suggestions?

2. Validation/message/exceptions display and other generic feature support of smart GWT is yet to be investigated.

3. Client server architecture: Having Spring MVC + Spring core on the server side and GWT + Smart GWT on the client side could be a good stack of open source technologies, but given that GWT by default uses RPC for client server interaction, usage of these needs to be better evaluated. (esp. authentication/session handling/security etc). Any suggestions?

Thanks

Answer 1

I am currently working on a Smart GWT / GWT application.

My opinion of Smart GWT currently is that it does save a lot of time, and it provides some good-looking, useful widgets. That said, because it's a wrapper around a JavaScript library it does have some caveats, particularly when debugging. Often it makes it much more difficult to track down an error than it would be using plain GWT (or GWT with a library that wasn't a JavaScript wrapper).

To try and comment on your questions:

1. I haven't found the Smart GWT libraries to be a problem in this respect. It's probably different to the GWT recommended way but it doesn't mean you suddenly have to abandon all best practices.

2. Can't really comment on this - haven't found the validation / message / exception libraries to be an issue

3. We use JAX-RS for the client / server communication, which Smart GWT supports natively and is pretty easy to implement. It's possibly a bit easier to debug than GWT RPC because it uses an XML format. We just use Spring Security for the security and, again, no issues there.

I think the main thing for us that would make me think twice about using Smart GWT again is the customisability: when you use their forms, for example, you can't do very much with them in terms of layout. Smart GWT has its own way of doing things, and you're pretty much locked into that way unless you want to write your own components (which isn't ideal because Smart GWT don't recommend mixing Smart GWT and plain GWT components).

If you're happy to write an application which uses the Smart GWT library and doesn't require much customisation it would be fine.

Answer 2

I nerver used SmartGWT or any other rich libraries. My opinions may be biased, but I really think that Gwt components are easy to customize and lightweight. That's something I never felt coming from SmartGwt are any other librairie of that type.

That being said, here's my answer to two of your concern:

Using framework GWT-platform and SmartGWT could be an option to try MVP architecture as mentioned here. Any suggestions?

Well, to stay MVP like in that aspect, just set the datasource from the presenter. In your view, the SmartGWT widget should be "passive" and wait for configuration coming from the presenter.

Advantage: You don't have to unit test the view, since SmartGWT widgets should already be well tested. You only have to test the presenter where you actually call the view to configure that widget and verify if you call it correctly.

Client server architecture: Having Spring MVC + Spring core on the server side and GWT + Smart GWT on the client side could be a good stack of open source technologies, but given that GWT by default uses RPC for client server interaction, usage of these needs to be better evaluated. (esp. authentication/session handling/security etc). Any suggestions?

RPC is an option, not the default communication. There's two other type of communication (and even more if you try experimental feature like DeRPC): RequestBuilder and RequestFactory.

RequestBuilder could be use to HTTP GET with JSON Response. Can't help you for the smart GWT approach.

Here's a user of Gwt-Platform that use Smart GWT, read his blog, it should enlighten you: http://uptick.com.au/blog

At the time of writing this answer, the blog was down, but it should come back soon.

Answer 3

You should first consider your goals in using MVP.

If you look over the SmartGWT samples, you'll find they already have clear and minimal code. You can't simplify or clarify any of the samples by introducing MVP, you can only add additional code and complexity.

So you should have a very specific and concrete, very compelling reason why you want to use MVP and introduce extra code: a particular design goal that cannot be met in a simpler way by using SmartGWT normally.

It's very hard to find a valid goal of this kind, because SmartGWT is very flexible and already supports testing via Selenium, and even has Selenium IDE extensions and support for Selenium RC.

A possible example of a valid reason to pursue MVP might be having two completely separate view implementations, one in SmartGWT and a simplified one in plain GWT. I know, it's not a very good example and it's hard to imagine anyone needing to do this, but that's because we have yet to have any developer come along and articulate a reason to use MVP with SmartGWT other than very vague notions of flexibility.

If you're going to take on the task of using MVP I think you should understand the situation well enough to say something like "we need to do X, and if we use SmartGWT normally that will take 6 months, if we add MVP, it will take 3". To my knowledge, no one has ever identified such a scenario.