One could argue that Javascript is transparent while using GWT. I would agree to a certain point with this, because I do not know how fast you need to touch Javascript in GWT.
Still this leaves me with 2 languages, namely Groovy and Java. While those 2 languages are very close together, this situation reminds me of a brilliant comic.
So why not use Groovy and Javascript, i.e. directly use one of the excellent Javascript frameworks? It does make more sense, since both are dynamic languages and both get more and more IDE support, namely in that one that costs some (you get the idea...).
Still: 2 languages is still one too much. Since Javascript is set on the client, this means to use, well Javascript on the server too. The guys creating the Sling framework for example do exactly this: it is up to you to use the Sling API on the client or server-side. I am not sure wether the code is 100% the same, but the general direction is given...
I still go with groovy, call me old-fashioned...
update:
Maybe the strangest thing in GWT/Grails combination is the fact that everything sent to the client has to be IsSerializable. And has to be retrieved via a Service.
Contrasting this with the direct use of a JSON builder which creates a format directly consumable by all Javascript libraries. Nothing beats
update 2:
render DomainClass.list as JSON
The last "update" is of course complete crap, see the comments! I was still in a kind of prehistoric knowledge level, GWT-wise.
4 Kommentare:
Sorry, but you have no idea about what you are talking about.
1) see the GWT- JSON example app to build GWT widgets based on JSON data
2) iSerializable is GWT 1.3! GWT 1.4 supports Serializable and GWT 1.5 (currently milestone release stage) even supports java 5 language constructs to make it even easiert to send classes to your client widgets by GWT-RPC.
Your opinion is based on a lack of understanding of documentation and the overall technology. Please dont make such statements if you dont know what you are talking about.
Hi Daniel
You of course are right, my poor knowledge is based on GWT 1.3. IsSerializable is gone for good? That is very nice to hear. And the argument with JSON is also a valid one. I will update my post.
But this was not the point of my post. The point is that the combined use of 2 great frameworks might not make sense for certain situations, especially regarding this very combination.
Cheers
Hi,
sorry for such harsh words, I did not mean to talk in such a rude way. I must have been quite annoyed that day.
IsSerializable is dead. I have some thousand lines of GWT code (1.5 RC1) with Grails and I have no use for that interface ;)
I agree that a lot of the Grails stuff is getting bypassed by using GWT. You end up calling services, not controllers, most of the time. You rarely need any flow between GSP files, because most of the stuff is inside your GWT module.
On the other hand, there is no such framework in the java land that makes it sooooooo super easy to get started with an application and provides an awesome build/plugin mechanism for dozens of great open source java projects that would have to be manually integrated. So much work is done for you, it is hard to deny that advantage.
At the end it is all about getting things done fast and in the right quality. And I think that Grails and GWT can help with that a lot.
Another approach: use Grails with SmartGWT. Instead of GWT-RPC (too complex, doesn't fit that well with Grails) use REST-based integration, since Grails has great support for serializing to XML or JSON and SmartGWT has built-in REST support. Take a look at this blog showing sample source - it's ridiculously easy to build a reusable master-detail screen for any Grails object.
http://josip-dev.blogspot.com/2010/06/grails-smart-gwt.html
Kommentar veröffentlichen