|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 45
Messages: 45
Messages: 45
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
GWT in Action: TheServerSide Tech Brief
Robert Hanson, co-author of the book GWT in Action, tells us about the Google Web Toolkit or GWT, a compiler that generates DHTML from sources written in the Java language. GWT aims to simplify writing AJAX applications, much like OpenLaszlo does, but using a programming model that's already familiar to Java programmers. GWT frees programmers from having to worry about web browser dependencies and from addressing them manually.
(Click here to view if you can't see the video.)
Chapter 2 (PDF) and Chapter 10 (PDF) of GWT in Action are available for review. Robert and co-author Adam Tacy felt that this extract provides the most benefit to new developers trying GWT without having to buy the book. Robert also provided a mother lode of examples in his web site.
Watch other Tech Briefs
|
|
|
Message #235302
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Debugging and Maintenance is a Problem
Although I have never done any GWT before, I think there is a big problem with code generators like it. Although you can develop the software in a nice IDE with standard, well established languages like Java, you have to debug production problems by digging through generated code, Javascript in the case of GWT. Also, the fact that most logic is running on the browser makes it even harder to track down problems, especially those that are not easy to reproduce. Javascript doesn't allow any logging, so you as the developer is stuck with what the user tells you, without much visibility into what happened in the code.
|
|
|
Message #235312
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Debugging and Maintenance is a Problem
Although I have never done any GWT before, I think there is a big problem with code generators like it. Although you can develop the software in a nice IDE with standard, well established languages like Java, you have to debug production problems by digging through generated code, Javascript in the case of GWT.
The fallacy in this reasonment stems from the use of the "code generator" word: use "compiler" instead and you will understand that there's something wrong in your argument: you do not debug assembler code just because that's what executed in a JVM after the java compiler has translated java code to byte code, and after the JVM has compiled byte code to native code. The whole idea of the java to javascript compilation is freeing you to have to debug javascript.
Also, the fact that most logic is running on the browser makes it even harder to track down problems, especially those that are not easy to reproduce. Javascript doesn't allow any logging, so you as the developer is stuck with what the user tells you, without much visibility into what happened in the code.
I don't agree that "most logic" is running in the browser: user interface logic must run in the browser with GWT, and that's what you need if you want a modern ajax interface. Furthermore I don't see why javascript wouldn't allow any logging: we implemented distributed problem notification from an applet years ago: one can surely do it in javascript, too.
|
|
|
Message #235315
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
I disagree -- debugging is a big advantage
You can debug using a java debugger directly in the IDE. 99% of the time the problem is that you didn't code up what you really want and using a java debugger instead of a javascript debugger is a big advantage. Think of GWT as a compiler, not a code generator as far as it's relationship to javascript. Of course, at some level there's no real difference between a compiler and a generator, but unless you are ready to argue against compiled languages, this shows the error of your view.
If you find a situation where the gererated javascript doesn't act like the hosted mode code you are debugging, then you have found a bug in GWT itself and your best bet is simply to post the information to the GWT project and work around it by using different functionality. GWT is stable enough that this is pretty rare, and I personally haven't encountered this yet. GWT is no different here than any other framework or development tool.
|
|
|
Message #235332
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Debugging and Maintenance is a Problem
Although I have never done any GWT before, I think there is a big problem with code generators like it. Although you can develop the software in a nice IDE with standard, well established languages like Java, you have to debug production problems by digging through generated code, Javascript in the case of GWT. Also, the fact that most logic is running on the browser makes it even harder to track down problems, especially those that are not easy to reproduce. Javascript doesn't allow any logging, so you as the developer is stuck with what the user tells you, without much visibility into what happened in the code.
Well, your first statement pretty much torpedos your credibility in my view.
I am using it, an this isn't a problem. In addition, only your presentation code is compiled, not "most logic" or even close, at least how I'm using it.
I would submit that Google was more than up to the challenge of addressing what is probably the least insightful issue they would have to address with their toolkit. So far, everything is working pretty much as advertised and Friday, we demoed the front-end to a customer who was quite pleased. In addition, I would say that GWT's effort is going to have profoundly positive effects on the component market that we've all been waiting for. It is incredibly easy to create components from existing components.
In addition, I am going to fall into the compiler camp on this one. Going by the analysis and optimizations they perform on the java code, I would say that they seem to be beyond code generation.
GWT Designer. That generates code.
Now, I've written several prototypes to integrate with the back-end and it has proven pretty smooth. I'm about to try a more complicated prototype to test Spring/Hibernate integration.
We'll see how it goes...
|
|
|
Message #235337
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Debugging and Maintenance is a Problem
I don't see why javascript wouldn't allow any logging: we implemented distributed problem notification from an applet years ago: one can surely do it in javascript, too.
Ok, how would you implement error logging on the browser with Javascript? you can't even access the file system of the browser's machine. You would have to send every log messsage back to the server and likely jam up the network.
|
|
|
Message #235341
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Debugging and Maintenance is a Problem
Well, your first statement pretty much torpedos your credibility in my view.
...
Now, I've written several prototypes to integrate with the back-end and it has proven pretty smooth. I'm about to try a more complicated prototype to test Spring/Hibernate integration.
We'll see how it goes...
I never did pretent to be an expert in GWT. It may be a very good tool, but don't try to discourage others from bring up questions about a new tool. Google may be a giant with many talented people working for them, but doesn't mean GWT is flawless. I raised a question about GWT applications' maintainability. Anybody can whip up a quick prototype that are untested and has no users.
|
|
|
Message #235343
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Debugging and Maintenance is a Problem
Although I have never done any GWT before, I think there is a big problem with code generators like it. Although you can develop the software in a nice IDE with standard, well established languages like Java, you have to debug production problems by digging through generated code, Javascript in the case of GWT.reproduce.
GWT and ECHO2 are two products that allow you to debug AJAX application without digging in javaScript. You write UI code in java and debug it in with debugger of your favorite IDE.
You can write Unit Tests.
GWT generates javaScript for you.I developed several projects in GWT without writing a single line in javaScript.
Also, the fact that most logic is running on the browser makes it even harder to track down problems, especially those that are not easy to
It is up to you were to place logic.
In my applications logic of UI runs on client. Business logic runs on server.
Javascript doesn't allow any logging, so you as the developer is stuck with what the user tells you, without much visibility into what happened in the code.
With GWT you can do logging in several ways.
By the way, what do you suggest to use instead for AJAX application?
PS I suggest you to read GWT tutorial (it is quite short)
and than continue discussion here or on GWT forum if you'll have questions ;-)
|
|
|
Message #235345
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Debugging and Maintenance is a Problem
GWT and ECHO2 are two products that allow you to debug AJAX application without digging in javaScript. You write UI code in java and debug it in with debugger of your favorite IDE.
You can write Unit Tests.
GWT generates javaScript for you.I developed several projects in GWT without writing a single line in javaScript
I didn't mean debugging during development or testing. I meant debugging production problems that are reported by real users.
|
|
|
Message #235347
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Debugging and Maintenance is a Problem
GWT and ECHO2 are two products that allow you to debug AJAX application without digging in javaScript. You write UI code in java and debug it in with debugger of your favorite IDE.
You can write Unit Tests.
GWT generates javaScript for you.I developed several projects in GWT without writing a single line in javaScript
I didn't mean debugging during development or testing. I meant debugging production problems that are reported by real users.
Please explain what is the difference.
|
|
|
Message #235348
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Debugging and Maintenance is a Problem
..GWT and ECHO2 are two products that allow you to debug AJAX application without digging in javaScript.
And what exactly is the reason for avoiding writing javascript code? It's actually quite an elegant / under appreciated little language.
|
|
|
Message #235349
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Debugging and Maintenance is a Problem
GWT and ECHO2 are two products that allow you to debug AJAX application without digging in javaScript. You write UI code in java and debug it in with debugger of your favorite IDE.
You can write Unit Tests.
GWT generates javaScript for you.I developed several projects in GWT without writing a single line in javaScript
I didn't mean debugging during development or testing. I meant debugging production problems that are reported by real users.
Please explain what is the difference.
Let's say a user of an email system reports an issue where he pushes the "Send Message" button and a javascript error occurs. You can't reproduce the problem in your own environment where you have your tools set up. You can't go to the user's site which is 5,000 miles away, or ask the user to give you his/her username and password so you can try it on his/her account. The error message on the browser's window will give you line number in the generated Javascript code where the error occured. How would you trace the problem?
|
|
|
Message #235351
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Debugging and Maintenance is a Problem
..GWT and ECHO2 are two products that allow you to debug AJAX application without digging in javaScript.
And what exactly is the reason for avoiding writing javascript code? It's actually quite an elegant / under appreciated little language.
+1
|
|
|
Message #235353
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Debugging and Maintenance is a Problem
Well, your first statement pretty much torpedos your credibility in my view.
...
Now, I've written several prototypes to integrate with the back-end and it has proven pretty smooth. I'm about to try a more complicated prototype to test Spring/Hibernate integration.
We'll see how it goes...
I never did pretent to be an expert in GWT. It may be a very good tool, but don't try to discourage others from bring up questions about a new tool. Google may be a giant with many talented people working for them, but doesn't mean GWT is flawless. I raised a question about GWT applications' maintainability. Anybody can whip up a quick prototype that are untested and has no users.
No one is discouraging anything, but, IMO, you bring up a fairly uninsightful issue, without even spending 10 minutes trying the thing out. I AM using it for a app,for a customer right now. That was something you mistakenly(I'm sure) edited out.
Unlike you, I tried using it via prototyping to see if it was worthing trying on a pretty major project. My prototyping(in conjunction with research on the experiences of others), unlike your guess, proved to me that it was worth using.
If anyone can whip up a prototype, why didn't you? I read about it, prototyped it, and I'm now using it. My Spring/Hibernate testing is more to put into practice my theories on who to utilize this stuff than any real doubts about the viability. In essence, what will be the best way to use integrate them. I'll try a couple of ways than pick the one that fits what we are doing and we'll do that for the project for which I am using the thing.
In addition, the tool isn't all that new anymore. It's been out a over a year now. No one said it was flawless. So far, my use has found a few items where there could be improved, questions based on usage is better, IMO, than shallow questioning that could be answered with a few minutes of usage.
To me, this is up there with the "Is Spring slow?" Sure. That's why so many people use it.
|
|
|
Message #235354
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Debugging and Maintenance is a Problem
No one is discouraging anything, but, IMO, you bring up a fairly uninsightful issue, without even spending 10 minutes trying the thing out...
Please learn some respect in a rational discussion. You are not the only who disagreed with my first comment. I have no problems with those people because they decided to conduct a civilized discussion even when they disagreed. I don't want to waste my time with this kind of exchange. Sorry.
|
|
|
Message #235355
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Debugging and Maintenance is a Problem
GWT and ECHO2 are two products that allow you to debug AJAX application without digging in javaScript. You write UI code in java and debug it in with debugger of your favorite IDE.
You can write Unit Tests.
GWT generates javaScript for you.I developed several projects in GWT without writing a single line in javaScript
I didn't mean debugging during development or testing. I meant debugging production problems that are reported by real users.
Please explain what is the difference.
Let's say a user of an email system reports an issue where he pushes the "Send Message" button and a javascript error occurs. You can't reproduce the problem in your own environment where you have your tools set up. You can't go to the user's site which is 5,000 miles away, or ask the user to give you his/her username and password so you can try it on his/her account. The error message on the browser's window will give you line number in the generated Javascript code where the error occured. How would you trace the problem?
With GWT you can fix it in several ways.
1st do proper exception handling and log (post)the error on server.
2nd reproduce same error in Hosted Mode and debug the java code in your IDE.
There are other ways, please read the tutorial to the end ;-)
|
|
|
Message #235356
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Debugging and Maintenance is a Problem
With GWT you can fix it in several ways.
1st do proper exception handling and log (post)the error on server.
2nd reproduce same error in Hosted Mode and debug the java code in your IDE.
There are other ways, please read the tutorial to the end ;-)
The 2nd option is out. I did mention that you can't reproduce it. Many errors cannot be reproduced in your own environment.
Posting error over the internet back to the server is very expensive. If that is how errors are handled in GWT, then I have serious doubt about the technology.
The tutorials I have read don't address error handling at all. Do you have any good ones to recommend?
|
|
|
Message #235357
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Debugging and Maintenance is a Problem
By analogy, browser is like OS, JavaScript is the C language, and GWT is like JDK. C is powerful (if not elegant :-), but you still use Java with JDK because: 1) you want your code to be portable for different OSes (running in different browsers), 2) you want a set of ready to use libraries (UI components, in the case of GWT). For these two reasons alone GWT is a good alternative to using Javascript.
Another important reason is that, for many Java developers, Javascript is yet another language that they have to master (not merely learn). Thus, GWT provides a mean for them to quickly build solid AJAX applications using a familiar language.
|
|
|
Message #235358
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Debugging and Maintenance is a Problem
By analogy, browser is like OS, JavaScript is the C language, and GWT is like JDK. C is powerful (if not elegant :-), but you still use Java with JDK because: 1) you want your code to be portable for different OSes (running in different browsers), 2) you want a set of ready to use libraries (UI components, in the case of GWT). For these two reasons alone GWT is a good alternative to using Javascript.
Another important reason is that, for many Java developers, Javascript is yet another language that they have to master (not merely learn). Thus, GWT provides a mean for them to quickly build solid AJAX applications using a familiar language.
This biggest problem I have Javascript is not the language. Most Java or C++ programmers can learn it in a day. It is the DOM that it uses. Every browser has its own DOM structure. It's like Java having 10 different core class libraries.
|
|
|
Message #235360
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Debugging and Maintenance is a Problem
The 2nd option is out. I did mention that you can't reproduce it. Many errors cannot be reproduced in your own environment.
Posting error over the internet back to the server is very expensive. If that is how errors are handled in GWT, then I have serious doubt about the technology.
The tutorials I have read don't address error handling at all. Do you have any good ones to recommend?
You are seriously overestimating the cost of posting an error log back to the server. We are talking about exceptions, not tracing. The bandwidth caused by exception reporting should be barely a blip in the scheme of things, or you have some other very serious problems.
Yes, even if your application is google sized. It should still be blip in your overall bandwidth usage.
If you really think it is going to be the end of the world, you could just set a debug flag for users so you only get logs for whatever user is having the problem. But then you won't know about other exceptions.
You could also create a debug window that the application user could open in some easter-egg'ish manner (i.e. a key combo not in the user documentation). They open it up, drag it off to the side, go about their work. When the exception occurs, they copy & paste that log into an e-mail & shoot it off.
Do I actually think users would like doing that? No. But it isn't any worse than telling them send some arbitrary log file to you over e-mail.
If you think logging is the most important requirement ever, you could store logs in the sqllite db provided by Google Gears. Then request the logs from the client having the problem (next time they log in it sends them to you, for example).
But that is some serious logging overkill right there.
|
|
|
Message #235361
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Use FireBug and of course alert()
Although I have never done any GWT before, I think there is a big problem with code generators like it. Although you can develop the software in a nice IDE with standard, well established languages like Java, you have to debug production problems by digging through generated code, Javascript in the case of GWT.
The fallacy in this reasonment stems from the use of the "code generator" word: use "compiler" instead and you will understand that there's something wrong in your argument: you do not debug assembler code just because that's what executed in a JVM after the java compiler has translated java code to byte code, and after the JVM has compiled byte code to native code. The whole idea of the java to javascript compilation is freeing you to have to debug javascript.
Also, the fact that most logic is running on the browser makes it even harder to track down problems, especially those that are not easy to reproduce. Javascript doesn't allow any logging, so you as the developer is stuck with what the user tells you, without much visibility into what happened in the code.
I don't agree that "most logic" is running in the browser: user interface logic must run in the browser with GWT, and that's what you need if you want a modern ajax interface. Furthermore I don't see why javascript wouldn't allow any logging: we implemented distributed problem notification from an applet years ago: one can surely do it in javascript, too.
The use of alert() allows for System.out.println() rudimentary logging and debugging, and more tools like Firebug(FFX) allow for more sophisticated debugging and profiling, inspection, etc.. and some browsers like Mozilla have built in Javascript debuggers..
|
|
|
Message #235363
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Debugging and Maintenance is a Problem
With GWT you can fix it in several ways.
1st do proper exception handling and log (post)the error on server.
2nd reproduce same error in Hosted Mode and debug the java code in your IDE.
There are other ways, please read the tutorial to the end ;-)
The 2nd option is out. I did mention that you can't reproduce it. Many errors cannot be reproduced in your own environment.
Posting error over the internet back to the server is very expensive. If that is how errors are handled in GWT, then I have serious doubt about the technology.
The tutorials I have read don't address error handling at all. Do you have any good ones to recommend?
It's possible to post errors back to the server, but I haven't seen a case where doing so is necessary. If you clearly separate business logic from presentation logic, a good chunk of activities happens on the server side, and so do errors. You should be able to handle these problems the way you do with regular Java applications.
On the client side, if the error message you mentioned is part of the presentation logic -- i.e. it's displayed by developer - then it's been expected and the message should tell you what's going on, you shouldn't be concerned about Javascript line number.
If the error is displayed by the browser, unexpected, I doubt knowing JavaScript line number alone would be very helpful. You need to know the state of the browser at that exact moment, and in this regard GWT-generated applications are no difference than regular Javascript applications. (Something like Firebug would help, as aforementioned) The good things are: 1) such an error is usually rare; 2) it's not expected that the user can recover from the error; and 3) refreshing the browser should make it go away. If however it occurs to multiple users, or it happens persistently, then it should be detected during development and testing.
|
|
|
Message #235380
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
javascript... bleh
Seriously... elegant? Maybe in it's base form, but there are sooo many gotcha's between the different browsers the 'elegance' goes out the window as soon as start testing on different ones (and the various different versions).
It's like the article on here the other day comparing C++ to Java (the article itself was flawed but the comments were good). Yes, JavaScript can be a solution, but for the majority of things it's much nicer to stick to a strongly typed and especially relevant in this case, platform independent language like Java.
And lets not forget about future proofing: there is no assurance that code you wrote for older versions of browsers in JavaScript will work on the new ones. With the abstraction utilised in GWT, all you'd have to do is update GWT when it supported the newer browser/version and you'd be set.
JavaScript could have been a really decent language, but the differences between browsers have left it as one of those nasty little embarrassments in our history towards stable apps. GWT's biggest benefit is it makes JavaScript useful again by hiding those mistakes and allowing people to just code - but if necessary the raw JavaScript can be accessed if there is something really quirky that needs to be done, which isn't that often (usually that's related to working with other Javascript libraries).
My only concern with using GWT was building libraries for use: they have to be compiled in at the Javascript generation phase... which does make sense in terms of only sending to the client what is _absolutely_ needed, but it still feels a bit icky composing multiple bits of functionality. Still, I have developed modules and it wasn't that bad I guess.
|
|
|
Message #235381
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: javascript... bleh
Seriously... elegant? Maybe in it's base form, but there are sooo many gotcha's between the different browsers the 'elegance' goes out the window as soon as start testing on different ones (and the various different versions)....
As someone I respect summarized it best - "GWT style" programming is for cowards..
This isn't a c/java/<your abstraction here> debate. This is about self deception and the dangers of churning out factory programmers who may be happy with GWT for a while but if that ever peters out and you haven't actually learned the technologies underneath you'll be screwed....And for no good reason.
JavaScript ~is~ a good language - almost every web site on the "internet" uses it - including GWT. You probably have just been used to seeing crappy spaghetti javascript code, which is unfortunate but not a fundamental language flaw.
Talk to me when GWT is provided as a native browser level feature across all browser versions.....
|
|
|
Message #235384
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Debugging and Maintenance is a Problem
....The error message on the browser's window will give you line number in the generated Javascript code where the error occured. How would you trace the problem?
With GWT you can fix it in several ways.
1st do proper exception handling and log (post)the error on server.
2nd reproduce same error in Hosted Mode and debug the java code in your IDE.
There are other ways, please read the tutorial to the end ;-)
Question: Can we, in production environment, map that line number in Java Script to the corresponding Java code without debugging the JavaScipt?
When we are running bytecode in JVM, in case of exception it gives you the line number in Java source code (compiled with -g) not in bytecode.
|
|
|
Message #235389
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Debugging and Maintenance is a Problem
The 2nd option is out. I did mention that you can't reproduce it. Many errors cannot be reproduced in your own environment.
There are very few unreproducable errors in comparison with total number of error. IMHO less than 1%.
Posting error over the internet back to the server is very expensive.
Really, how often do errors happen in your application? ;-)
Each exception in my application (except communication with server) is logged on server.
If that is how errors are handled in GWT, then I have serious doubt about the technology.
Very interesting opinion ;-)
How do you prefer to log errors in AJAX applications?
|
|
|
Message #235397
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: javascript... bleh
Yes, javascript is quite elegant. But the lack of proper tooling makes it very difficult to debug properly. I know firebug, but firebug isn't perfect (hell, it only runs on firefox...). GWT is about using a language that is more developer-friendly, because of the tooling and community. Where are the Eclipse-like ide's for javascript? and the gazillions of tools for java stuff? and the ecosystem that java has?
If you have a typo in your custom .js, chances are you only realize if you use the code, or when it blows in production. On eclipse for instance, it doesn't compile.
Besides, browser implementations of *script and DOM are very different (heck, IE's scripting is JScript, not javascript). What GWT brings is a common starting point where you don't have to develop and account for various browsers AT THE DOM LEVEL. CSS differences has nothing to do with GWT.
Talk to me when GWT is provided as a native browser level feature across all browser versions.....
And what GWT tries is to provide a abstraction that performs equally on all browsers, kinda like what you want
|
|
|
Message #235398
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: javascript... bleh
As someone I respect summarized it best - "GWT style" programming is for cowards..
One man's coward is another man's wise person.
This isn't a c/java/<your abstraction here> debate.
Ok, I guess it isn't.
This is about self deception and the dangers of churning out factory programmers who may be happy with GWT for a while but if that ever peters out and you haven't actually learned the technologies underneath you'll be screwed
Well, yes and no. As with ORMs and SQL, users of GWT (or Echo2) should understand Javascript.
....And for no good reason.
You mean besides spending hours on figuring out where the Javascript error is? And then, because cowards can't use abstractions, repeating the same error again and again?
JavaScript ~is~ a good language - almost every web site on the "internet" uses it
I guess that means VB is good too. Look at how many people use it. And I guess cussing is good too.
Talk to me when GWT is provided as a native browser level feature across all browser versions.....
Why is that needed? All that would do is create the need for another level of abstraction.
|
|
|
Message #235401
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Data transfer Objects Anti-pattern
The biggest problem with GWT in real world applications is that, it introduces back the Data transfer Objects. Most of the server-side objects have references to other (server) objects. They are not necessarily serializable or could be of huge memory footprint. So serializing them optimally is the biggest problem with GWT. So the application invariably ends with lots of Data Transfer Objects which is often very difficult to maintain.
This is reasonably easy with AJAX enabled JSF frameworks like ICEFaces:
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4045513
|
|
|
Message #235404
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: javascript... bleh
Seriously... elegant? Maybe in it's base form, but there are sooo many gotcha's between the different browsers the 'elegance' goes out the window as soon as start testing on different ones (and the various different versions)....
As someone I respect summarized it best - "GWT style" programming is for cowards..
This isn't a c/java/<your abstraction here> debate. This is about self deception and the dangers of churning out factory programmers who may be happy with GWT for a while but if versions.....
Well, nothing new in that sentiment. C programming was cowardly because you didn't use opcodes. Java was cowardly because you didn't use pointers. Hibernate is cowardly because you didn't use SQL.
That person who wrote has a superiority complex. While he is not deceiving himself writing javascript the so-called factory developers will be churning out applications faster with more capability.
Where are all the guys who believed that C/C++ was too abstract and that people would learn the underlying technology?
I'm amazed that someone considers knowledge of javascript a good indicator of good programing skills.
|
|
|
Message #235407
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Data transfer Objects Anti-pattern
The biggest problem with GWT in real world applications is that, it introduces back the Data transfer Objects. Most of the server-side objects have references to other (server) objects. They are not necessarily serializable or could be of huge memory footprint. So serializing them optimally is the biggest problem with GWT. So the application invariably ends with lots of Data Transfer Objects which is often very difficult to maintain.
This is reasonably easy with AJAX enabled JSF frameworks like ICEFaces:
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4045513
I agree with you about the DTOs. I'm trying a few ideas to figure out how best to deal with this. It'll probably take a little time before a best practice or solid idea emerges from the community. However, I think that they are moving in the right direction. For instance, they've added Serializable in the JRE emulated library to allow one to better use existing classes instead of just IsSerializable.
|
|
|
Message #235414
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Data transfer Objects Anti-pattern
I have to agree here about DTO's, need to write tests to make sure everything stays correct. One of my few complaints about GWT. Also i don't like having to include whole packages to the GWT source build location instead of single files. Makes integrating with existing projects a little difficult and kind of forces interesting package structures.
Other than that i'm pretty impressed and loathe the idea of writing standard (jsf, struts2 etc) webapps again. And yes my module is currently in production with a fairly smooth prototype/development cycle.
Adrian
|
|
|
Message #235427
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
GWT Designer
Take a look at this eclipse plugin. I use Idea primarily, but eclipse becomes a capable gui designer for GWT with this plugin.
|
|
|
Message #235449
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: GWT in Action: TheServerSide Tech Brief
I think there are a lot of idle talks around ajax, gwt, web2.0 and others. Just look at CPU and memory usage in real GWT application, e.g. http://demo.queplix.com:8080/ (login/password demo/demo). Why do not use Swing - it is more simple and faster to develop such application. And moreover, such applications is not for public inet, just use Web start to deploy Swing application on client hosts.
Yes, javascript is a very funny thing, drag and drop, hover buttons and no more than. Also it looks like GWT is bad designed product, I posted some comments about it http://www.javalobby.org/java/forums/t97761.html.
|
|
|
Message #235453
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Debugging and Maintenance is a Problem
..GWT and ECHO2 are two products that allow you to debug AJAX application without digging in javaScript.
And what exactly is the reason for avoiding writing javascript code? It's actually quite an elegant / under appreciated little language.
+1
Each time you write in JavaScript you should think will it work on IE and FireFox and Safari...
If you want you web application work on each of mentioned browsers you often have to write 1 method in 3 different ways.
GWT does it for you. You write in java and your application works on IE,FF,Safari.
This is first reason.
Second reason you can use IDE, UnitTesting, debugger and even profiler (check gwt1.4).
Third reason you don't have to learn yet another language.
Isn't it enough? ;-)
|
|
|
Message #235461
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: GWT in Action: TheServerSide Tech Brief
Swing needs a JRE, and some of the people who invest on ajax can't afford to force the user to download a full jre. I know, Sun may release a smaller JRE, but that does not exist right now. Ajax is about the least common denominator, which is html + javascript. At the other end is Flash, but I guess there aren't any real flash sites (at least that I know of) that can compete with ajax apps like google calendar or any other ajax app, in terms of pushing the technology forward - not because flash is inferior (I believe it is much superior technology but with a somewhat different purpose) but because of visibility.
I agree some people/companies/products don't need to work for the least common denominator, but there are other reasons on why people still push that technologies. Right now ajax sells kinda like xml selled it a few years back.
|
|
|
Message #235476
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Debugging and Maintenance is a Problem
Each time you write in JavaScript you should think will it work on IE and FireFox and Safari...
If you want you web application work on each of mentioned browsers you often have to write 1 method in 3 different ways.
Actually most web developers rely on various JavaScript libraries. It's up to these libraries to support different browsers correctly. It's not so often when web developer should write 1 method in several different ways (from my experience it's rather rare situation).
Second reason you can use IDE, UnitTesting, debugger and even profiler (check gwt1.4).
That's a good reason, especially the ability to write unit tests.
Third reason you don't have to learn yet another language.
I think every web developer has to learn JavaScript (as well as (X)HTML and CSS). GWT functionality is limited and I doubt that any serious web application could be written entirely on GWT without any line of custom JavaScript.
BTW how about memory leaks in browsers? Does anyone experience them with JavaScript code produced by GWT?
|
|
|
Message #235481
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Debugging and Maintenance is a Problem
This biggest problem I have Javascript is not the language. Most Java or C++ programmers can learn it in a day. It is the DOM that it uses.
I agree, and that is why it is great to have a framework like GWT hiding the nasty stuff for you so that you concentrate on the more interesting things.
|
|
|
Message #235508
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Data transfer Objects Anti-pattern
The biggest problem with GWT in real world applications is that, it introduces back the Data transfer Objects. Most of the server-side objects have references to other (server) objects. They are not necessarily serializable or could be of huge memory footprint.
Yes, the DTO's complicate things a lot, but they're not specific to GWT as such. A GWT application with a lot of RPC-calls is in essence a client-server application. In my current project we have rich domain objects living on the server that require an active database transaction so that related objects can be loaded lazily as they are navigated (a persistence context in JPA terminology), and have dependencies on various API's. It's unlikely we can use these same objects on the clientside, hence the need for DTO's or view objects.
It's not a problem specific to GWT, it's a common problem for rich clients.
|
|
|
Message #235515
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Data transfer Objects Anti-pattern
It's unlikely we can use these same objects on the clientside, hence the need for DTO's or view objects.
It's not a problem specific to GWT, it's a common problem for rich clients.
I am doing "Rich clients" (and have for years) and it is not a problem common to what we are doing.
|
|
|
Message #235548
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Data transfer Objects Anti-pattern
"Rich client" suggests enhanced interactivity and usability for the end users. How this is acheived is an implementation detail. Technically you could implement rich client using:
1) RPC by having rich client state (using frameworks such as GWT, DWR etc)
2) UI updates without refereshing the page (using frameworks such as ICEFaces, AJAX4JSF etc)
DTO is a problem only for RPC-style frameworks. These frameworks come with another problem: There is no way to get the incremental changes to objects on the server. The entire DTO needs to be sent to the UI everytime, irrespective of the number of attribute changes. This is inefficient and also requires the AJAX applications to render the whole UI, making it merely a client side html renderer. ICEFaces handles this intellegently.
Having said that, UI update frameworks come with its own limitation: If your application is a read-mostly application, having a rich client state helps. There is no need to go to server, if you want to show some additional info on mouse-over, on focus, or drill down events. This is a problem with UI update frameworks. You have to pass additional info as hidden form/layer and display this info on drill down events. This scatters contoller code in java and javascript.
So, i think the type of application must dictate AJAX framework selection.
|
|
|
Message #235575
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Data transfer Objects Anti-pattern
"Rich client" suggests enhanced interactivity and usability for the end users. How this is acheived is an implementation detail. Technically you could implement rich client using:
1) RPC by having rich client state (using frameworks such as GWT, DWR etc)
2) UI updates without refereshing the page (using frameworks such as ICEFaces, AJAX4JSF etc)
DTO is a problem only for RPC-style frameworks. These frameworks come with another problem: There is no way to get the incremental changes to objects on the server. The entire DTO needs to be sent to the UI everytime, irrespective of the number of attribute changes. This is inefficient and also requires the AJAX applications to render the whole UI, making it merely a client side html renderer. ICEFaces handles this intellegently.
Having said that, UI update frameworks come with its own limitation: If your application is a read-mostly application, having a rich client state helps. There is no need to go to server, if you want to show some additional info on mouse-over, on focus, or drill down events. This is a problem with UI update frameworks. You have to pass additional info as hidden form/layer and display this info on drill down events. This scatters contoller code in java and javascript.
So, i think the type of application must dictate AJAX framework selection.
I'm not sure if I agree with your assessment about having to send all data for RPC style frameworks. Let's say I have 10 fields and change 2. I control what is sent back in the RPC call. I only have to send the two. In my GWT service, I can pull my object, out of session and change just the two. In addition, I can send just the one String or int from the back-end if I so desire.
|
|
|
Message #235580
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Data transfer Objects Anti-pattern
David,
This was discussed in earlier link, i posted:
"The potential areas of change in my case is not completely static (not known when i define the UI). Only at runtime, after executing the controller action would i know the areas of change. (depending on data entered in a widget, the logic determines what parameters should be modified). So currently if i have to define it statically it would be the union of all the potential areas of change (which becomes almost the entire object graph itself.)"
"There could be output components anywhere on the page affected by the input. When the user presses the different buttons, different application logic should invoked by the action methods, but standard JSF would render the entire page. All the outputs on the page should be able to derive themselves correctly from the complete model, it's just that the model is updated differently by the different buttons. This preserves the declarative aspect of page design.
It's true that rendering a specific subtree on a page could be a useful optimization, but it should only be an optimization, not the primary way to add Ajax functionality."
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4045513
You could do this in GWT as well. But you might need some server-side support to generically do this in GWT:
http://www.theserverside.com/news/thread.tss?thread_id=45173#231952
cheers,
mani
|
|
|
Message #235705
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Is GWT compatible with other java based frameworks?
hi can GWT be embedded with web frameworks such as Struts or Spring MVC? If so, how so? Will GWT just be used for widgets and Ajax? or much more...thanks
|
|
|
Message #235775
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
less powerful (java) being transformed to more powerful (js)
Interesting interview with the creator of Dojo where he makes a comment about Gwt saying the concept of gwt is about transforming a less powerful language into a more powerful one. I tend to agree. It is after all client side javascript so why tie yourself to the server for client side code generation when its not necessary with a sophisticated client side library like dojo which encapsulates away the browser differences for you anyway.
Dojo interview is here...
http://blogs.pathf.com/agileajax/dojo/index.html
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources.
(May 19, Tech Talk)
Download the entire book of Jakarta-Struts Live and learn about Struts MVC, Tiles, the Validator, DynaActionForms, plug-ins, internationalization, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
