Development time for GWT apps versus 'traditional' MVC with JSP

[Julius]

Hi,

What are your experiences regarding development time for rich internet
applications using GWT compared to the more traditional approach with
JSP and an MVC pattern?

I am currently developing a RIA with GWT using the MVP pattern
illustrated in this article from Google:
http://code.google.com/webtoolkit/articles/mvp-architecture.html

It took me some time to become familiar with the pattern, with the use
of UI Binder and with the general concept of sending back and forth
data between the client and the server through RPC.

Some of the questions that needed answering in our project so far and
that have cost us more time than initially planned are

Security:
- How to secure services that modify or delete data? Since these
services can be called directly from the client they need to be
properly secured. For each call we have to verify that the calling
user is registered in the database and has the rights to call the
service. In order to do this we changed the interface of important
services by requiring a valid session key as a parameter.

- We now use a servlet filter and go through this process for each
view that is loaded on the screen which causes quite a number of
requests. Ideally we'd do this only in the outermost view and pass
security parameters from the outer most presenter into the constructor
of inner presenters.

Retrieving text:
- When are we going to retrieve texts? Are we going to make a separate
call to the database for each presenter/view to load the texts for
that presenter/view? Or do we need a mechanism that loads the texts of
the entire screen in the outer most presenter, in our case the
presenter that belongs to the main grid that is the basis of each
screen.

Serializing data
- We use Hibernate for persistence and had to find a solution for the
fact that Hibernate proxy objects are not serializable and have to be
converted to serializable POJO's. This was one of the smaller issues.

At this moment developing our GWT application is taking us a lot of
time. Certainly a lot more than with a traditional JSP approach. I
understand that building an application with JSP results in a
traditional website, which is different from building a GWT
application, which is comparable to creating a desktop application
that runs in a browser. It is however taking us about twice as much
time to build the same functionality with GWT.

What are your experiences? Do you find it more time consuming to build
the same functionality with GWT compared to building it with JSP/PHP/
etc and a MVC pattern? We might just be struggling with the new
technology and I hope development spedd will pick up as the project
progresses, but right now, I am a bit disappointed about the larhe
number of hours we're burning answering all sorts of questions and
solving all sorts of problems we hadn't seen coming when we started.

[Subhrajyoti Moitra]

i am currently "migrating" a Swing desktop app to a web application- GWT is the chosen framework. I cant imagine how i could have pulled this off, without GWT.

Most time consuming part for our team(2 currently) is the UI obviously. If you are not using one of those WYSIWYG tools for GWT, it can take a lot of time to put the right UI in place. We also dont have a CSS/HTML expert in our team, so its just trial and error.

GWT-RPC mechanism is the coolest RPC mechanism i have used to date.

".. these services can be called directly from the client they need to be properly secured."- i secure it at the server. Depending on some security principle, i do some basic checks on the client. The server does the bulk of the validation, before fulfilling a request.

"For each call we have to verify that the calling
user is registered in the database and has the rights to call the

service."- Yes. We use serverside cache (ehcache) to cache in the "logged" in users profile info.

Traditional JSP is "page" based approach, wherein markup as well as data has to be sent from the server. Though u can use JS libs to have a single JSP page do all your stuff. GWT is generally good for these single page apps.

It took us a while to come up to speed with this framework and its nuances. But frameworks like gwt-incubator/bikeshed examples/mvp4g/gwtpresenter/gwtdispatch will ease a lot of your "glue" code troubles as well as give u lots of examples of doing stuff in GWT.

HTH.



Thanks,
Subhro.

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

[Sebastian Rothbucher]

Hi Julius,

I'd believe that speed takes up as you probably run over many problems
due to a paradigm shift: GWT programming is much like desktop app
programming (like in AWT) and much less like web application
programming.
Concerning security, I think you are right: you have to implement
checks before each method and limit the method to change the desired
data as soon as you have more than one user group. An alternative to a
check could be a security configuration in the web.xml for one service
servlet, but the effect is the same.
Concerning data binding / presenters I have to admit that I never used
the MVC approach suggested by google but rather subclassed Panels to
be data holders for a certain domain object, i.e. get/setPerson() on
the panel becomes feasible. With read/save methods cascading along
panels, quite a lot of flexibility can come in. Certainly, this goes
in the same direction as google's approach - and generally, you can
load and set data (in whole or in parts) at any time using the object
model.

Maybe it helps to just see the development efforts as desktop app
development; and to cut down on the patterns and frameworks used for
the first app...

Good luck and best Regards
Sebastian Rothbucher

[Julius]

I think speed will pick up as we move along, because we are both more
webapp developers than desktop app developers and certainly for me it
took some time to grasp the concept of the event bus, and registering
and catching events. So, as Sebastian suggested, the paradigm shift
took some time and effort.

Secondly, it took time to think about and implement security and to
become familiar with UIBinder.

We're on a pretty tight schedule and in my view we haven't reserved
enough time to get to know the new technology and to learn about third
party solutions that can ease development. I don't know any of the
solutions (incubatir, bikeshed) Subro mentions.

Thanks for sharing your thoughts,

J