Google Web Toolkit

Home

News: Google Web Toolkit

  1. Google Web Toolkit (61 messages)

    Google Web Toolkit (GWT) is a Java software development framework for writing AJAX applications like Google Maps and Gmail. JavaScript's lack of modularity makes sharing, testing, and reusing AJAX components difficult and fragile. GWT claims to avoid this while offering users the same dynamic, standards-compliant experience. You write your front end in the Java programming language, and the GWT compiler converts your Java classes to browser-compliant JavaScript and HTML. What do you think of Google Web Toolkit? Message was edited by: rlynch@techtarget.com

    Threaded Messages (61)

  2. Re: Google Web Toolkit[ Go to top ]

    Few weeks ago, we choosed OpenLazslo for our "next generation" web applications... we were quite happy. But I tried gwt and I must say I quite love it :( My god... it's getting hard to choose
  3. Re: Google Web Toolkit[ Go to top ]

    OpenLazslo appears to have a DHTML+Ajax version coming out in the near future.
  4. We haven't quite seen enough so let's have more. You wascals you!
  5. Re: Google Web Toolkit[ Go to top ]

    I think it is cool. I can think of many reasons why it wouldn't be my choice right now, but imo it is great to see a web framework facilitating just object oriented Java programming for a change. If you want to go ajax all the way, it looks like it is a good choice to keep things maintainable. Very nice Google open sourced it, even if it is just partially. -- Eelco
  6. Yes, but[ Go to top ]

    ...how well will it integrate with Wicket?
  7. Re: Yes, but[ Go to top ]

    ...how well will it integrate with Wicket?
    :) I have no idea. Investigating and waiting on comments from users. I'm not even sure whether it has to. But as both frameworks are Java based without too much bloat around it, I'm sure some level of integration is doable if the demand for it is high enough.
  8. Re: Yes, but[ Go to top ]

    Google's API isn't just a set of AJAX components. It is a web framework in its own right. Looks like a darn nice one too. The closest corellary to GWT (which is a play of SWT btw) in the Java community right now is Echo 2.
  9. Re: Google Web Toolkit[ Go to top ]

    imo it is great to see a web framework facilitating just object oriented Java programming for a change.
    @see http://wicket.sourceforge.net/ @see http://www.nextapp.com/platform/echo2/echo/
  10. See this too ;-)[ Go to top ]

    http://click.sourceforge.net/
  11. Just a few days ago, I attended a talk at Google's NYC office and asked: "Does google see itself as a software API/platform provider for the massses? Google obviously has developed a very productive AJAX framework. Can we have it?" I almost jumped off my seat when I read this post... Keep it coming.
  12. Gorgeous![ Go to top ]

    This is super damn awesome!.. Looks like Google is responding to Yahoo's AJAX Toolkit. When is Microsoft going to open source ATLAS? Duh..
  13. Re: Gorgeous![ Go to top ]

    and what do you mean under "Yahoo's AJAX Toolkit"? I know a good JavaScript library from Yahoo. Marina http://www.servletsuite.com/jsp.htm#ajax
  14. Yahoo's AJAX Toolkit[ Go to top ]

    and what do you mean under "Yahoo's AJAX Toolkit"?
    Probably: http://developer.yahoo.com/yui/
  15. This sure is a framework in it own right. I envision an eclipse plugin that just drags and drops MenuItems, Buttons, etc.. on a pane and than you have VB style WebApps development. whithin a year every body is doing it. Remember, this is just like AWT, SWT. It is exactly the same. It's easy too. It's pure Java and debuggable. Just great. JSF looks so akward all of a sudden. JSF is suppost to be toolable... well GWT is for sure toolable. I have seen a lot of frameworks lately... DWR, Dojo etc... all very nice, but GWT is different. I really really like it. Thanks Google!!!
  16. I suppose you have to weight up the benefit of a toolkit such as this against losing the JSP-type approach where you're just putting together an HTML page with some flashy bits and pieces thrown in. Rightly or wrongly folks seems keen to have designers work on page design and layout and leave the dynamic client and server side programming to others. With this toolkit you can of course still have your designers work-up the stylesheets and specify page layout - might well be enough to keep them busy.
  17. Re: Google Web Toolkit[ Go to top ]

    tjeeh , if i see all the positive reactions about this i think some jsf eg members are pretty wrong about there assumptions that nobody wants to program in java. It is about time they put there heads out of eachothers behind and start looking over the fence.
  18. We already used yahoo toolkit and would be interested to see a comparisoon with google's one
  19. Yahoo vs Google[ Go to top ]

    it seems to me that yahoos offering is a JavaScript-only library, whereas Google offers a Java-based framework solution that generates JavaScript under the covers. That would mean that Google offers much better integration with server-side programming, while Yahoo can be used more flexibly christian
  20. Re: Yahoo vs Google[ Go to top ]

    Hi, Can you be more specific, regarding the yahoo offered package? Thank you.
  21. Re: Google Web Toolkit[ Go to top ]

    Thats great, But what about security. I dont want to compromise with security of my application. Will AJAX, promise me the security? Thank you.
  22. Re: Google Web Toolkit[ Go to top ]

    So long as you are careful in your programming, yes, it can be secure. Running a site under SSL should require no code modification (just Tomcat/Jetty/Whatever configuration). And you should never, ever store any passwords in code that will run on the client. Can be every bit as secure as any other website so long as you understand and properly gate all the access points.
  23. Issues I see[ Go to top ]

    Looks like GWT has quite nice idea hovewer do not think it solves all Web application related issues. Here I've provided a list of the issues I see. (Hovewer I had a very breaf look at GWT and my assumptions can be wrong). 1. Custom component creation. The GWT does not provide an easy solution for creating own non-standard components. Anyway you end up with manual JavaScript writing for different browsers 2. JavaScript is generated. Do not consider this feature as fully positive. Imagine you have a large complicated application that consists from generated JavaScripts. You will have big problems in cases where JavaScript has own pecularities that are not reproducable in Hosted mode. Debugging of generated JavaScript code may become a nightmare. I'm for 100% sure that such cases will arise in big projects. Code generation sometimes become a big evil! 3. It is not 100% Java. GWT really gives the possibility to write all code in Java only. Hovewer take into account that you are limited only to Java API supported by GWT: java.lang, java.utils and gwt classes. You won't be able to use a huge amount of libraries porvided by open source Java community e.g. logging, xml parsing, Hibernate etc. Here I mean that they can not be translated to JavaScript running on the client side. Additionally you can not use such simple feature like create own thread on the client side that is quite trivial when creating Java applets. Anyway I consider that GWT guys did a good job and they have really original idea that does not appear in any other frameworks I know hovewer time will show which approach is more effective GWT, OpenLazslo, JSF or some other.
  24. Non issues[ Go to top ]

    1.Custom component creation Quote: public class Composite extends Widget // Superclass of TabPanel, TabBar A type of widget that can wrap another widget, hiding the wrapped widget's methods. When added to a panel, a composite behaves exactly as if the widget it wraps had been added. The composite is useful for creating a single widget out of an aggregate of multiple other widgets contained in a single panel. 2. JavaScript is generated. true, use GWT with new projects for now. 3. Why should u want to use logging, hibernate etc.. on the client-side anyway? U can make u're own valueobject classes serializable. and it will work. Remember it is a presentation layer technology. In the evolution of Struts, JSF, GWT kinda way..
  25. Re: Non issues[ Go to top ]

    Can't agree with you more.
  26. Re: Issues I see[ Go to top ]

    Hello Maxim, I agree with what you have said except one last point. . It is not 100% Java. GWT really gives the possibility to write all code in Java only. Hovewer take into account that you are limited only to Java API supported by GWT: java.lang, java.utils and gwt classes. You won't be able to use a huge amount of libraries porvided by open source Java community e.g. logging, xml parsing, Hibernate etc. Here I mean that they can not be translated to JavaScript running on the client side. Additionally you can not use such simple feature like create own thread on the client side that is quite trivial when creating Java applets. I believe that GWT is for presentation layer only and that's where you would want to use it. If you need to do other stuff in your application, you should be free to do that, especially when they are outside the presentation layer. If GWT does not allow us to interface with independent back end; i,e. calling other services then it is deemed to fail. I just perused very quickly their documentation and honestly speaking it looks very promising. But there must be a way to call business layer's services where you can apply other wonderful open source services i.e. hibernate, JBOSS,XML parser etc.
  27. Re: Issues I see[ Go to top ]

    I think GWT is a great idea and provides good framework for rapid Ajax development. There has been lot of open source libraries available, we saw openAjax project but till now we didn't see any framework like GWT which is self contained in itself. Extending GWT APIs should not be a problem, but what I see as a problem is the Javascripts generated. Had a look at some of them and it looks horrible. So if we require to do any customization apart from the one generated by GWT, its going to be nightmare !!! @S http://www.pcmspace.com
  28. Re: Issues I see[ Go to top ]

    By default, the javascript is generated to be obfuscated, use -style pretty to get nice looking java script
  29. Re: Issues I see[ Go to top ]

    Can't agree more.
  30. Port 8888[ Go to top ]

    Does anybody know how to change GWT Hosted Web Browser port?
  31. Check Out Echo 2[ Go to top ]

    Check out Echo 2: http://www.nextapp.com/platform/echo2/echo/demo/
  32. Re: Google Web Toolkit[ Go to top ]

    Any ideas on what the style control is like? Is it strictly via CSS, and if so, do you still have a fine level of look and feel control? I can't tell from a cursory read through the docs. One concern I have is that all applications would look somewhat like Gmail. I think the Gmail interface is fine for what it is, but other people (clients!) might want their own custom designed look and feel.
  33. style in GWT[ Go to top ]

    http://code.google.com/webtoolkit/documentation/com.google.gwt.doc.DeveloperGuide.UserInterface.StyleSheets.html
  34. Accessibility[ Go to top ]

    This is a very nice toolkit, but for one thing. Like every other set of javascript widgets out there, you are forced to use a mouse to operate the widgets (Menu, TabPanel etc.). In this respect it is still way behind AWT, MFC, and even plain old HTML. I cannot use GWT because I am required to provide a UI that can be driven using only a keyboard. And if you were a person whose only means of using a computer was via a keyboard then you might think that Google have done quite an evil thing... Don't get me wrong, this is a terrific offering. I just wish that javascript programmers would occasionaly consider keyboard navigation.
  35. Re: Accessibility[ Go to top ]

    I take back what I said. They've provided a neat little item called FocusPanel that you can embed any other widget in and use it to catch keyboard events. You still have to do your own key handling and focus management but it's better that nothing. I'm beginning to really like GWT. :)
  36. I can see so many problems; I don’t even know where to begin Do you want your business logic translated to JavaScript and exported to the Browser and executed in the browser? It supports only parts java.lang and java.util, so you need to forget most of Java programming skills. No EJBs, no JDBC and forget about your CMS. After all the sacrifices, do you really think, you can avoid JavaScript, think again. If you need to implement GUI Widget for a large custom DHTML component such as, Hierarchical menu of your own or Scroll for components (please see web page for an example), according to documentation on Google’s custom Widget implementation, you cannot avoid writing JavaScript code. http://cbsdf.com/technologies/DHTML-Widgets/Widget-samples.htm If you wish to implement a GUI Widget for a custom Ajax/DHTML component, you need intimate knowledge of the HTML elements, tags and even model. Therefore, you must have experience in both Java and JavaScript/DHTML programming. Isn’t it the problem in the first place: to have clear separation between the Java developers (business logic) and JavaScript developers (presentation logic)? To create an ideal solution, we need a model that let each work independently. The process must provide separation and let each individual work independently in a manner appropriate to their specific skills and consistent with their roles, in a manner that reduces the interference between them. Web designers are great at creating great GUI components. We (java developers) must let them create great GUI Component with out any incumbarances, and once they have done that, we can create a GUI Class wrapper around it in an hour or two. This colabaration between Java and JavaScript developers must not be avoided, but can be made pleasunt by limiting to the functional requirements to just high level description of the couple of simple service the web component need to offer. This problem is not going to go away, but will become even bigger as next generation web platforms such as SVG, XAML and MXML emerge. How do you create an Airplane to simulate near real-time air traffic in the skies? http://cbsdf.com/misc_docs/gui-api-brief.htm http://cbsdf.com/technologies/GUI-Class3.htm (You need Adobe’s SVG Viewer) These are just only few and many other obvious issues such as loosing the convince of JSP model etc. There you have it. I just said the emperor have no cloths. No I should head for mountains, before flames head in my way. Best Regards, Raju
  37. Please don’t miss understand my post. I think, Google is a great company and they have great at creating web applications (mostly consumer oriented), but looks like they have miss understood the needs of enterprise application developers. Also they should know future technologies, such as, SVG+XUL, MAXL. They already using Flash for Google financial charts. How can they support Java API to build GUI Widgets for such chart component? http://cbsdf.com/technologies/misc-docs/CF-Goog-Charts.htm It looks to me like it is designed by Web developers to solve java developers’ problems. It end up some kind of mapping between Java and JavaScript. You know what will happen, when you do that: you end up with feature set that is common to both, which are good for small projects in the beginning. But in the long them, it will end up a maintenance nightmare, if the project scope is expanded. Thanks! Raju
  38. no EJBs in JavaScript[ Go to top ]

    I really dobnt understand these complaints about not being able to use any ols Java API on the client side. I think this is a totally obvious restriction that simply means that you will have to design your thin/rich-client application somewhat more intelligently than a plain fat client or a web app with a HTML-only front end. No magic can make this go away. And yes, of course you will have to code JavaScript if you want to create custom widgets. As much as you have to learn the underlying OS widget API if you want to extend SWT. In any case I dont think you will want to leave this to a "web designer" (at least not the ones I know), as a widget usually involves some fairly complex logic.
  39. Re: no EJBs in JavaScript[ Go to top ]

    I am not talking about client side. How do Java-to-JavaScript translator translate that code and other data access logic? If I need to deal with low level JavaScript to build a custom DHTML component, I would rather deal with it directly and not do it indirectly using some Java/JavaScript mapping. When I said web designer, I meant expert JavaScript developers. Here mileage may vary; I am poor selector of colors and usability features (even I feel my choice of colors awkward), while I know web designers who can do great job at it.
  40. Re: no EJBs in JavaScript[ Go to top ]

    you should really give yourself some time to read up on the concepts of GWT. Noone intends to translate data access logic into JavaScript. I dont want to repeat the words of the guy over at JavaLobby.
  41. You may be taking about the following post at JavaLobby: ====== BEGIN: Copied from JavaLobby==== Have you got any experience in developing Rich Client stuff? If you indeed have, then why you do not understand what I'm saying is beyond me. The Rich Client model is many times more productive than the ugly mixture of Java, JSP, HTML, JS, due to the use of single , statically typed , OOP language for the server as well as for the client - Java . And also because working with the even-driven paradigm is easier than working with the request-response paradigm. ====== END: Copied from JavaLobby==== I agree with the statement. But, does it really solving the “request-response paradigm” problem? No we need to create multiple Servlet files, one for each Ajax component. The Ajax component makes a asynchronous request and Servlet file responds with the data. Now the JavaScript unpacks the data and populates various fields in the web component, for example an HTML table. Now we end up with multiple Servlet files and lot of other code to pack the data at the server and code to unpack the code at client. Maintenance nightmares written all over it. Also, I have done lot of work on Asynchronous request response loops. They are not reliable, so one will end up with whole bunch of new problems. Some of the responses do not reach properly, and other responses arrive in out of order. How do you handle these scenarios in the Java. For example, in case of Google maps, you end up with some missing squares occasionally in the map. That shows the Ajax request is not successful. I don’t want to discuss again here, but it was discussed at “Billy Newport on the hidden costs of AJAX”: http://www.theserverside.com/blogs/thread.tss?thread_id=40008. Some cases lost requests are OK, but other cases it is fatal. I am not disagreeing with your statements, but let us do it right. That is exactly what I have been researching for several years. I am not saying I am right, but lets put the issues in the open to find better solutions. Sorry my observations look like arguments. Just like to point out potential issues. Please also understand, if the application is not data driven, this is not an issue, but enterprise applications require numerous pieces of data from different database and sources, which are more convent to access from local web application server (rather than from out side of the fire walls). I don’t even talk about, security issue with so many small pipes into the corporate databases. It is a nightmare again to policing all the small Ajax pipes. What about error handling, if one of the database request fails. In the single JSP file for the web page case, we just don’t send the web page, but here the web page is already loaded. We may end up trading one set of simple problems with completely new set of problems. Thanks, Raju
  42. We may end up trading one set of simple problems with completely new set of problems.

    Thanks,
    Raju
    Isn't it obvious? With every new technology comes a new set of problems and possible solutions, and we will alway need to balance the cost versus the benefits. With Ajax we get better UI, better response, but we also get the problems you mentioned. Would we get some of these problems if we went for Swing client instead of Ajax? Probably yes, and we'd get other problems also (deployment, app update, etc.), but other niceties too, so it always ends up being a cost/benefit decision. Or at least it should be decided on that, not on hype... ;) Given the rate of adoption of Ajax, I think people are finding out the cost/benefit balance of this "new technological solution" to be acceptable.
  43. <blockquoteGiven the rate of adoption of Ajax, I think people are finding out the cost/benefit balance of this "new technological solution" to be acceptable. I am not against Ajax and I am heavily investing on Ajax. I am just worried about the specific solution of building HTML/JavaScript file using pure java (minus business logic). If one needs to aware of HTML and JavaScript event models, the benefits are minimized (especially considering HTML can only support only basic GUI components compared to Java/Swing). In my opinion Java is great at business logic and although imperfect we have mature models and tools to handle DHTML and other emerging presentation technologies such as SVG+XUL, XAML, X3D or MXML/Flex. I think it is possible to build frameworks, which let us get those benefits with out compromising or trade-offs. I have been working on creating such framework and only time will tell, if I will be successful or not. Mr. McCoy said: Again, no tool can protect a user from bad design. I think, world is imperfect and a good framework must recognize that and protect us from our imperfections or from our own mistakes. It should help us minimize mistakes and when mistakes happen, it should minimize the costs and consequences. I think, an Ideal “loosely coupled” component based software development paradigm can do that. I have been working on that framework and I hope I will be successful (but there are no guaranties in life). Google is a great company and they are doing wonderful work in Ajax. But, this proves that even Google builds not so perfect products. On the other hand, it may be a great tool for some set of developers or for certain type of problems. Thanks, Raju
  44. <blockquoteGiven the rate of adoption of Ajax, I think people are finding out the cost/benefit balance of this "new technological solution" to be acceptable.>


    I am not against Ajax and I am heavily investing on Ajax. I am just worried about the specific solution of building HTML/JavaScript file using pure java (minus business logic). If one needs to aware of HTML and JavaScript event models, the benefits are minimized (especially considering HTML can only support only basic GUI components compared to Java/Swing).

    In my opinion Java is great at business logic and although imperfect we have mature models and tools to handle DHTML and other emerging presentation technologies such as SVG+XUL, XAML, X3D or MXML/Flex.

    I think it is possible to build frameworks, which let us get those benefits with out compromising or trade-offs. I have been working on creating such framework and only time will tell, if I will be successful or not.

    Mr. McCoy said:
    Again, no tool can protect a user from bad design.

    I think, world is imperfect and a good framework must recognize that and protect us from our imperfections or from our own mistakes. It should help us minimize mistakes and when mistakes happen, it should minimize the costs and consequences.
    be a great tool for some set of developers or for certain type of problems.

    Thanks,
    Raju Then you should be happy! :-). As you said, how can you generate Javascript from ejbs and data access code? You cannot. The framework doesn't allow you to do this, so it "kinda" forces you to do the right thing, eh? :-)
  45. Whats really funny about your rant is despite your half assed knolewdge of Java , complete lack or archiechture concepts and absolutely zero knowledge of this subject , you still feel confident posting your rants several times over. To summarize : a you are not supposed to code business logic in the UI tier. b GWT is meant for UI tier alone. c. This tool kit has APIs to allow you to integrate with your whiz bang Javascript widgets d Raju -- servlets are so 1999. Stop thinking you need a servlet for every Ajax call. Finally Raju -- stop building your own " Ideal “loosely coupled” component based software development paradigm " whatever. That giver away the motivation behind the rant !! Cheers!!
  46. a you are not supposed to code business logic in the UI tier.
    Thanks for the hint! I am under the impression that business applications need data also.
    This tool kit has APIs to allow you to integrate with your whiz bang Javascript widgets
    So they handle all the data access exceptions and security? Where did Google say that? Any URL?
    Raju -- servlets are so 1999. Stop thinking you need a servlet for every Ajax call.
    He meant Sevlets/JSP/JSF/CGI/.NET whatever or did you invent any magic way to get data to the client? Search for “ATRB Pioneer soft”, you would know the project is one of the top research projects being evaluated by Advance Technology Review Board of US Navy. All other qualified participants are multi billion dollar defense contractors. Sound bytes and using anonymous name shows that which is rant. Cheers!!!
  47. So they handle all the data access exceptions and security? Where did Google say that? Any URL?

    LoL -- so now you want Google to teach you how to handle data and security exceptions ?
    He meant Sevlets/JSP/JSF/CGI/.NET whatever or did you invent any magic way to get data to the client?
    They do require that you make the objects serializable. The framework handles the rest.
    Search for “ATRB Pioneer soft”, you would know the project is one of the top research projects being evaluated by Advance Technology Review Board of US Navy. All other qualified participants are multi billion dollar defense contractors.
    Good for him and you but how is it pertinent to this discussion ?. When they open source it, I will be sure to look it up. Until then , it is snake oil as far as this topic is concerned. Dude, download the toolkit and start trying it out as I have done. It is pretty sweet stuff!! I apoligize that my initial response to Raju's comments were not so polite; that dude has barely read up on this toolkit, leave alone trying it out.
  48. Raju, take a look at http://code.google.com/webtoolkit/documentation/com.google.gwt.doc.DeveloperGuide.Fundamentals.ServerSide.html
  49. Re: no EJBs in JavaScript[ Go to top ]

    I am not talking about client side. How do Java-to-JavaScript translator translate that code and other data access logic?

    If I need to deal with low level JavaScript to build a custom DHTML component, I would rather deal with it directly and not do it indirectly using some Java/JavaScript mapping.

    When I said web designer, I meant expert JavaScript developers. Here mileage may vary; I am poor selector of colors and usability features (even I feel my choice of colors awkward), while I know web designers who can do great job at it.
    Simply. It wouldn't. You would not put data access code in the GWT. If that wasn't obvious, Google says as much on their website. Again, no tool can protect a user from bad design.
  50. I can see so many problems; I don’t even know where to begin. Do you want your business logic translated to JavaScript and exported to the Browser and executed in the browser? It supports only parts java.lang and java.util, so you need to forget most of Java programming skills. No EJBs, no JDBC and forget about your CMS.
    AFAICS, the purpose of GWT is not to bring all your application logic to the browser. You can do with GWT what you have done with JS and HTML. Instead of directly writing in JS and HTML you use Java which is translated to browser-aware JS and HTML by a 'compiler'.
  51. i didnt find UI wedget for 'Editable Combobox' ;) i mean with auto complete feature.
  52. Spring integration[ Go to top ]

    The only thing I see missing is spring integration. I cannot live happily without it.
  53. Re: Spring integration[ Go to top ]

    The only thing I see missing is spring integration. I cannot live happily without it.
    LoL!
  54. (From my blog and article on this subject after interviewing Bret, the Product Manager for GWT...) Time will tell, but the announcement yesterday by Google may change the faces of AJAX development, strike that, Google's announcement may change web development for evermore. This cynic heard an announcement yesterday that could change his viewpoint and beliefs on the future of web development. Certainly, in the recent past, the chances of doing an entire application in AJAX seemed remote for the vast sea of developers. The thought of writing a rich application in JavaScript, for most developers, is total anathema - akin to having one's body shaved and thrust into a pool of warm alcohol. Please don't write and plead for a change in my aversion to writing metric tons of JavaScript, for my heart isn't in it - as most developers' hearts aren't in it. It is not so much the writing of JavaScript as it is the lack for tools...and the horror of debugging it. Sure tools exist but they are a far cry from what you get in the Java world. Writing JavaScript is like changing a baby's diaper: you don't like to do it, but you love your child and you do it anyway. You may not like to write JavaScript, but you want to deliver richer applications for your end users so you may do it anyway. Dare I say the best developers are the ones that love their end-users? Thus the missing ingredient is the ability for Java developers to develop AJAX applications in Java instead of JavaScript, i.e., to take the smell and rank out of it. This would allow a vast community of developers to develop rich web applications where before a select few script-heads would dare go. Enter stage left the contender for changing the way, once and for all, the world uses the web: Google! Google just introduced the Google Web Toolkit (GWT), a free, publicly available Java development framework. This framework allows developers to develop and debug applications in Java and deploy them in AJAX. The Google approach to AJAX development is to avoid JavaScript (for most developers anyway). You can write all of your AJAX code in plain old Java. You can debug it. Use breakpoints. ... continued at: http://jroller.com/page/RickHigh?entry=javaone_2006_google_s_gwt
  55. Re: Google Web Toolkit[ Go to top ]

    This is only positive - I'm not sure why some on this board are chomping at the bit to put down GWT. My guess is that it is easier to play devil's advocate than to actually understand the technology and how it should/could be applied. Google has obviously found some decent business cases for developing and using this toolkit. They are being generous by releasing it to the general public. Like any other tool/framework: 1. evaluate if it is right for your project/circumstances/team 2. use it if it is 3. don't freak out and say it's crap if it isn't 4. do share an intelligent commentary on why the technology did or did not work for your situation to help others decide 5. live long and prosper
  56. Re: Google Web Toolkit[ Go to top ]

    GWT has a chance to obviate JSF, Tapestry, and other server-side content models. I like some ideas behind JSF and the like, but most of these share a common bit of nonsense -- replicating the entire client widget model on the server. This limits scalability and seems like an utter waste of time. That's been the best approach in many respects all the same to date. Now GWT offers the ability for the client to maintain all of that and talk to the server as *it* needs to. This is dramatically simpler than trying to replicate the state across client and server. It allows better server scalability. If GWT does not succeed in doing so it at least points out a way to do away with the client/server state replication mess that we have today.
  57. Re: Google Web Toolkit[ Go to top ]

    GWT has a chance to obviate JSF, Tapestry, and other server-side content models.

    I like some ideas behind JSF and the like, but most of these share a common bit of nonsense -- replicating the entire client widget model on the server. This limits scalability and seems like an utter waste of time.

    That's been the best approach in many respects all the same to date. Now GWT offers the ability for the client to maintain all of that and talk to the server as *it* needs to. This is dramatically simpler than trying to replicate the state across client and server. It allows better server scalability.

    If GWT does not succeed in doing so it at least points out a way to do away with the client/server state replication mess that we have today.
    I actually agree for the most part that GWT is really fantastic, but I doubt it will displace JSF on the market. Looking at the spectrum of rich JS components, the fact that GWT requires a compilation step and lack of simple collaboration does actually hurt the framework right now. I attended a few swing presentations and people are looking for jsf-ish databinding capabilities and the web guys are looking for swing-ish capabilities on the client. Maybe the route that the myfaces guys are pushing around enhancing dojo with jsf components for contextual management/databinding will be the popular route--
  58. Re: Google Web Toolkit[ Go to top ]

    I like some ideas behind JSF and the like, but most of these share a common bit of nonsense -- replicating the entire client widget model on the server. This limits scalability and seems like an utter waste of time.
    +1
  59. Re: Google Web Toolkit[ Go to top ]

    but most of these share a common bit of nonsense -- replicating the entire client widget model on the server. This limits scalability and seems like an utter waste of time.
    Oh please. Every technology has it's own pros and cons. 'Limiting scalability' is such a generic remark. In what sense? Following what scalability approach? Even GWT can have lousy scalability characteristics in the wrong hands. I think it is a great idea to have stateful components on the client - not new, but now the big name of Google is behind it -, certainly good for most scalabitly approaches, but the tradeoff here, compared to some other frameworks, is that you have to do more work when you do things like integrating databases etc. Especially true in the case of GWT as you are rather limited in the kind of Java classes you can use in the client widgets. And how is it nonsense and an utter waste of time to 'replicate the entire client widget model' when it is done transparently for you? Does premature optimization mean anything to you? This reply is not an attack at GWT, because I think it looks great - though certainly not perfect considering things like good i18n support seem to be absent - but I wish people would stop looking at frameworks/ APIs like there has to be one ultimate winner, but instead look at the pros and cons and decide which one suits their current needs best. Next project, next evaluation.
  60. Does GWT support GBK?[ Go to top ]

    hi! I puted an gbk String in Label's Constructor and the Hello samples app didn't start,why?
  61. Very neat but ..[ Go to top ]

    I just discovered GWT, and I think the idea of doing UI Ajax in Java is amazing. I like the idea of being able to unit test and debug UI javascript with my favorite IDE, even if the extra generation step could of course add some artefacts and tricky bugs to fix. What I dislike about GWT for now, is the lack of integration with other more mature technologies. From what I understood, GWT seems to be very basic on the server-side compared to other framework like Spring for exemple. It will be nice not to have a servlet by AJAX service, and not to have to herit from a specific class from the API. It will also be nice to have IOC to inject the backend services in the servlet. I also think that on the client side, I should be able to include my Ajax component in other view technologies like JSP for exemple. I don't think 100% Ajax application is currently the good way to go, but a mix between JSP and Ajax, would be better. I can't wait for GWT to be open, so that we can improve the integration part. As far as Exception handling is concern, they seem to provide CallBackHandler that do the job. http://code.google.com/webtoolkit/documentation/com.google.gwt.doc.DeveloperGuide.RemoteProcedureCalls.HandlingExceptions.html
  62. There's a big problem using EJB3 entities in GWT, since GWT (a) doesn't recognize annotations since it's based on JDK 1.4, and (b) isn't pluggable with JARs or anything which extends the subset they support. It's not that it ignores it, it just fails to compile. The solution to this is to write simple(r) value objects and pass them to GWT, but this reminds me of EJB2.1 (which can't be a good thing...).