Google Web Toolkit introductory article on XML.com

Discussions

News: Google Web Toolkit introductory article on XML.com

  1. Bruce Perry has written "Google Web Toolkit," an article walking through a simple application using the Google Web Toolkit (GWT) application. It's pretty complete, showing the whole development lifecycle. One takeaway, in particular from page 3 of the article, is that perhaps GWT isn't the magic bullet either; the advantages with GWT are in user interactivity, not necessarily development time. It's a great toolkit, and has a lot of room for growth, but it has its drawbacks as well. If you've used GWT, how have you applied it? What do you like about it, and what do you dislike?
  2. The Google Web Toolkit is a good piece of code , but there is a mistake in the article when it says 'it is available under an apache style licence'. What the Google Website says is:
    The GWT Java-to-JavaScript compiler and hosted web browser are shipped binary-only and subject to the license below.
    My reading of 'the license below' is that you are restricted in what you can do (e.g. no redistribution) with these binary components. As a developer , this would restrict my ability to develop solutions based upon the toolkit. Paul , Technology in Plain English
  3. re: licensing. If you are going to distribute your application to users, you are fine. However, you are not allowed to modify the provided code and then sell or otherwise redistribute your version of the GWT, a very reasonable stipulation IMHO. MW
  4. I like it a lot because it means no more writing HTML or Javascript, both of which I hate doing with a passion. Still have to fudge around with CSS however, and the fact that GWT does all it's layout with tables inside of tables, getting the CSS right is not easy. Also, it strikes me as a toolkit written by some C programmers still coming up to speed on Java. Writing the Java against it is like writing in Java 1.2 - ie, no 1.5 features, and use of Collection classes is very limited.
  5. While I was looking for a ajax based framework came across ZK framework http://zk1.sourceforge.net/ and it looked pretty impressive. Did anyone try this. Like the flexibility it provides and rich set of components http://www.potix.com/zkdemo/userguide/ From the development point of view since its based on markup language, I felt its much easier to code and reuse the components than writing a big java file containing all the presentation logic and compiling every time you make changes. As we are dealing with presentation logic, we can get a easy picture of what we are displaying when you look at a markup language rather than looking at a big set of java classes. Since it lets you to write everything in java and no pain of dealing with javascript, I felt it also offers one of the main advantage of GWT. Only disadvantage I see is that its not backed by big names like google or apache.
  6. ZK1 looks real good. P.S. GWT is a complete crap.
  7. ZK1 looks real good.

    P.S. GWT is a complete crap.
    What observation is this statement based on? Please explain.
  8. ZK1 looks real good.

    P.S. GWT is a complete crap.


    What observation is this statement based on? Please explain.
    It is based on the comparision of GWT with other Ajaxized frameworks like Wicket, Dojo, ZK1 even DWR and evaluating it on architecture, usability/productivity gains, browser compatibility. There is nothing nice about GWT except the first word in the abbreviated name which happens to be Google.
  9. ... except the first word in the abbreviated name which happens to be Google.
    Well said!
  10. Thats kinda funny, dojo and GWT are not apples to apples, along DWR. Gotta know how someone decides these things or you might as well just be flipping a coin, if you know what I mean...
  11. i'm not sure i'd call it "a complete crap," but i'm not sure how useful it is to most developers. don't get me wrong, obviously GWT's rather clever, but it has a few problems that i think would preclude it's usage on many projects. the main problem i see with it (and ZK looks to suffer from the same problem based on my brief look at it) is that the development model is all or nothing. it looks like if i want to use GWT then my entire UI will be a GWT UI. Same with ZK from what I can see. Is that acceptable to most people? Are many people building these 100% Ajax UIs? I know I'm not. I want an html UI that I can specify with some kind of template text. Whether that's JSP or JSF or something else, I don't want to be abstracted away from the html. And most of the time my UI is only sprinkled with Ajax. With something like DWR I can use as little or as much Ajax as I want rather easily. True, I have to resort to manual DOM manipulation, but at least this is transferable skillset, unlike learning GWT's html abstraction api or zk's markup language. If I'm looking for some sort of widget framework, a purely browser based one ala Dojo would seem more appropriate. Plus, I don't see any Ajax framework out there whose server side interaction model can compete with DWR's.
  12. The main problem i see with [GWT] (and ZK looks to suffer from the same problem based on my brief look at it) is that the development model is all or nothing. it looks like if i want to use GWT then my entire UI will be a GWT UI.
    This is not true.
  13. Why all these Ajax frameworks so complex and lock to one solution. Isn't very hard to combine two or more frameworks? The following webpage argues that it is an incomplete solution best suited only for very smart people at Google: http://www.cbsdf.com/ps_blog/why-other-frameworks.htm
  14. The product you hyperlinked is too complex! Take a look at ZK. You'll see how simple it is. IMHO, the only problem is that it is not JSF-based.
  15. I am a Java developer and some of us don’t wish to master new markup languages (some people may not mind learning new methods). I like the simplicity of the two-step process. Of course, we need to refer documentation for get/set methods of each GUI Class, when we need to use it. Since, we cannot remember many things, most of us refer to documentation for the class methods. If that is the case, then compare the user documentation: Ajax GUI-API-Guide: http://www.cbsdf.com/ps_blog/why-other-frameworks.htm ZK- Developer-Guide: http://zk1.sourceforge.net/wp/ZK-devguide.pdf (179 pages) At most 5 pages (including 5 large figures) compared to 179 pages for ZK. The emphasis in my earlier post is not “simplicity” but like to see a “complete” solution (comparable to desktop GUI solutions). The stated objective for Ajax GUI-API is to build complete solution (which is better than desktop GUI-API) and waiting for XAML/WPF/E and XUL+SVG. Being a small company, they said in one of the posts, they are not willing to risk limited resources in building DHTML solutions. They say DHTML cannot offer complete solution, which is explained at: http://www.cbsdf.com/misc_docs/gui-api-brief.htm The Ajax GUI-API clearly explained a simple method to create custom GUI Classes, which is needed for many applications, especially our application need custom GUI components and also we need to use other frameworks as well for other parts in the application.
  16. Raju's component paradigm!! thanks for the link, quite an hilarious site