Hi Steve, 1. I concur with Matt that the biggest advantage of GWT is writing AJAX client in Java instead of javascript - if you are writing a large application then this will pay off hand over fist in the long run.
2. Start up troubles depend on the direction your team come from. Java people tend to have trouble with CSS and HTML rules, whereas javascript/HTML people tend to have difficulty getting OO and Java rules. What you've got is really good toolkit but you have to learn how it works to use it well. 3. I don't think there are any major difficulties in addressing Spring from GWT RPC servlets - there are numerous resources on that around - but there is an issue with Hibernate (and any other ORM/JPA system). The problem is that ORM frameworks support lazy loading and to do that they adorn your persistent domain classes with various proxies and special collection classes which the GWT JRE Emulation Library does not support. Secondly there are things that need to be considered regarding attaching/detaching persistent objects for transfer to client during long running transactions. You will definitely want to look into this and select your optimum approach up front - there is more than one, and the best one depends on your exact situation. A good place to start is hibernate4gwt/Gilead. If you understand how that works you will have your head around the issues and be in a good position to evaluate options. Hibernate4gwt stores original Hibernate objects in HttpSession, and it would be nice not to have to do that, so quite a lot of people role their own custom RPC serializers to speed things up, but in general they have worked out in advance that it will work OK for them. Others use a DTO creator library like Dozer for the same reason, i.e. to help make server as stateless as possible. I would be careful about this lest it bite you on the backside. Search group for numerous posts on the subject. 4. I don't think the number of modules makes a whole lot of difference to compilation speed - I think it's the LOC count that really matters since it's the conversion of Java code to javascript that takes the time. There are several things you can do get to situations where developers are waiting seconds rather than minutes to run/debug their edits, for example: a) In case you don't know, if you are editing just client side code you do not have to recompile, you just hit refresh in the dev shell browser which takes seconds to respond. If you change, say, RPC sevlet code (basically anything running on the server) you do. b) If you temporarily specify a particular user-agent (i.e. browser) in the main module gwt.xml file, the compiler only creates one set of client files (instead of four) and that cuts compile time by about 50%. c) If you have a big application then splitting the client into modules is a good idea and means you can develop and test individual components separately using separate temporary/test entry points. You pay for that with extra integration work, but it will obviously significantly cut down day to day compile times so it may be worth it. regards gregor On Jan 11, 11:01 pm, medgey <[email protected]> wrote: > I don't think there is any way to make things compile much faster. I > think the real question is why you think you need hundreds of > modules. Does your website really need hundreds of small RIAs? I > cannot think of too many situations where this would be needed. > > I have used JPA and GWT in an application before without too many > problems but not Spring (the app was a standalone RIA). > > Although debugging is a nice GWT feature it is not its strongest > advantage - the organized OO-method of UI web design and AJAX > integration are by far the most important aspects of the toolkit. > > Regards, > > Matt > > On Jan 9, 5:29 pm, Steve Anthony <[email protected]> wrote: > > > Hi, > > > My engineering team took the last month to use GWT to implement new > > pages for our UI. We had a world of trouble around interactions with > > Spring & Hibernate. It was bad enough that the main GWT advantage > > (productivity increases from easier debugging) was not realized. > > > Likewise, we had some issues around compilation speed, 1-2 minutes to > > compile a single module, for example. Think hundreds of modules, and > > this isn't going to scale. > > > I'm looking to see if there are any recommendations for people who > > could provide a _focused_ training session; a few days to help us > > understand how to work the technology interactions so that we can > > improve our productivity. We know the basics; but are having trouble > > adapting the technology into our stack and making effective use of it. > > > Recommendations gratefully welcome. > > > Steve --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
