My .02... To Chris's point "or if they're written in JavaScript, you won't have much lock-in"...true. But you won't exactly be using GWT to it's strength.
IMHO the advantage that GWT has over other frameworks is that it's not really a framework like YUI, Scriptaculous, jquery or whatever. Those are Javascript libraries to help you write slicker Javascript for the web client. GWT takes a different and wholly unique approach by nearly eliminating the need for developers to write Javascript in the first place. You write GWT in Java, using nearly full powered Java syntax and let the GWT compiler make the Javascript. You wouldn't be limited or locked in, any more than if you crafted your application around any of the aforementioned Javascript libraries....so that means yes. Yes you are "locked" in, just as locked in if you developed an app in YUI and decided to switch to JQuery. The big, big advantages to GWT are syntax homogeny (Java for the client, Java for the server), Java development strategies for web apps (JUnit, true Java classes and inheritance, etc...) and browser neutral coding (the GWT compiler handles the various implementations of browser quirks). Your team focuses on writing code. Again, to mirror Chris's point, GWT is a web client based product, with a limited amount of server side niceness (but I'm a huge lover of GWTRPC so that makes my statement seem odd...but I digress). So you won't see any issues with hibernate, spring and spring security, because they are server side Java "libraries". About the only issue is that you'll have to work with the GWT to Hibernate DTO...since it all ends up on client as Javascript. But what we've done is create pure Java value DTO's that are fully usable on client in GWT and fully usable on server in Hibernate...same exact classes, no cut and paste or tweeking. Try that with a Javascript client language. You mention PHP. GWT is compatible with PHP, mostly in the JSON area...because again, PHP is a server side language and GWT in this case would be your client side. I've seen that done a number of times... As for the dreaded reuse question: it is possible to take your compiled Javascript, which was created by GWT and maintain it. Sadly, I've seen it done. Once you do that, you can't go back. It's not unlike someone skilled back in the old days who would hand modify the compiled out Visual Basic project code and break what the VB IDE could do for them. But then I thought I had a good reason to do that.... The bottom line is that the resulting Javascript is fairly advanced and likely to be better than anything somebody would write on their own, but a hard core Javascript developer with mad spelunking skills and some time, could maintain the Javascript if you decided to walk away from GWT for some reason. All of the above opinions are expressly my own.... Later, Shaffer On Mar 9, 5:11 am, Chris Lercher <[email protected]> wrote: > Hi, > > I don't have an answer on the portal part of your question, but a few > thoughts on the other parts: > > > Are there limitations to using GWT, for example can you use, > > hibernate, spring, and spring security? > > GWT runs on the client (except for the parts from gwt-servlet.jar, > which run on the server if you choose to use GWTRPC). So on the > server, you can use whatever you want - this is not restricted by GWT. > You just have to make sure, that GWT can handle the objects you > transfer to the client - remember that everything used on the client > has to be compiled to JavaScript, so it needs the source code for the > entire object graph that is used. If you want to minimize these > dependencies, you're probably best advised to use DTOs and keep the > objects for the client simple. > > > Is there a danger in locking ourselves into GWT for web based > > application development that we cannot move away from it? > > This depends on how much you rely on the Java to JavaScript magic > (which won't be provided by a lot of other frameworks, I'm afraid). So > if the complex parts of your application are either executed on the > server side, or if they're written in JavaScript, you won't have much > lock-in. But if it's written in Java, and it has to be executed on the > client-side, you probably will. > > HTH > Chris > > On Mar 9, 12:44 pm, Portal Developer <[email protected]> > wrote: > > > > > Hi, > > I would like to get people's opinions around the adoption of GWT as a > > web application development platform. > > > Most of our development is carried out using java / php and we are > > looking to standardise on a new framework for developing web based > > applications. We have a mixture of portal based development and php > > applications. > > We would like to maintain our portal based development in java but how > > well does GWT integrate with portals? > > > Is there a danger in locking ourselves into GWT for web based > > application development that we cannot move away from it? > > > Are there limitations to using GWT, for example can you use, > > hibernate, spring, and spring security? > > > If we decide later that GWT isn't the way to go can we reuse what was > > developed in java for GWT, for example is is it possible to develop > > generic enough classes for GWT that can be used outside of GWT as > > well. > > > I would be grateful for thoughts and opinions, good and bad. Both > > sides of the story would be helpful. > > > Thanks, -- 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.
