I deplore the job of developing graphical user interfaces. You always know when a database query works or not, but when it comes to developing a front end, you have to cater to the needs of irrational people, and people always manage to find something on the UI that needs 'improving.'

However, despite how much I deplore the job of doing GUI development, I love GWT. And even more to the point, I love Smart GWT, which superseded gwt-ext. Just look at the Smart GWT showcase, and tell me you're not impressed.

Smart GWT Showcase

Look at all of the neat little widgets and gadgets they have for plugging into your Java based, web-applications. The Drag and Drop functionality has always been a big favorite of mine, but everything from the Calendar widgets to the Data Integration tools can really help you fight that battle against the endlessly unsatisfied end user.

One question I have often wondered though was whether I should be coding with Smart GWT, or just sticking with the standard Google Web Toolkit components, and only shoot over to Smart GWT when I need a feature that's missing from the standard GWT implementation? It does seem that GWT has narrowed the gap between themselves and Smart GWT. Still, when you compare the GWT and Smart GWT showcases side by side, you can see that Smart GWT still has a leg up on the competition.

GWT Showcase vs. Smart GWT Showcase

And why all the talk about Smart GWT? Well, they just released their 2.2 version, with the following features sprinkled into the mix:

• Selenium Support with intelligent fallback locator strategies
• Support for the prototype pattern to set global defaults without creating a separate hierarchy of subclasses.  This is explained in more detail in the release announcement
• DateRangeItem, MiniDateRangeItem and Relative Date support for DynamicForm
• Dropdown multi-selects
• Javadoc enhancements : Over 200 API's have an overview and relevant Showcase sample in the @see link of the API docs
• Numerous other fixes and enhancements. The complete release notes can be found here http://www.smartclient.com/smartgwt/release_notes.html#2_2

By the way, of that whole list, the thing I like the best is the Selenium support. I really like the way Smart GWT has integrated with that product.

If you really want to turbo-charge your client experience, regardless of whether you're coding in JSPs, Servlets, JSF or Wicket, you should think about throwing some Smart GWT widgets into the mix.

 
Related Reading

GWT in Practice??~ Charlie Collins
GWT in Action: Easy Ajax with the Google Web Toolkit?~ Adam Tacy
Google Web Toolkit Applications??~ Ryan Dewsbury

Of course SmartGWT. Once you need rich components you have to choose better library than basic GWT stuff. SmartGWT is my favorite library because is LGPLed.

Visual part is nice but not that important as something what is called by "smart" people 'databinding'. If you build heavy data base application you will love it. This databinding support allow you to free your hands from caching, paging, updating data in page. Everything will work out of box.

About you last paragraph, it's maybe misunderstanding but it's very difficult and expensive to add some components to existing e.g. JSF application. Better is to go with full SmartGWT and Java. It's really easy to create powerful application in minutes. Check VisualBuilder on smartclient.com .

We are using SmartGWT for our open source MDA tool - Sculptor. We are preparing new release 1.9.0. You can check here http://fornax.itemis.de/confluence/display/fornax/5.4.+SmartClient+(CSC)

>>About you last paragraph, it's maybe misunderstanding but it's very difficult and expensive to add some components to existing e.g. JSF application.

I was actually thinking more along the lines of adding in a little widget to a JSP page to do some function, as opposed to a full integration with things like the JSF validation framework or anything like that. I've found lots of places where I can shoehorn in a little self-contained GWT or SmartGWT app into an existing application. :)

You might want to take a look at Vaadin also. It's more server-oriented if you prefer that model.

http://vaadin.com/demo/

Showcase:  http://www.extjs.com/examples/#overview

Ext still have problems with license. Double check what GPL v3 means for your software. Smartclient is LGPL.

And Ext lack in features. Visual part and also databinding.

I was about to say that GWT Designer didn't support Smart GWT. But i just googled and ...

http://www.prweb.com/releases/GWTDesigner/v75/prweb4021444.htm

 

 

Smart GWT LGPL edition is crippled. The features like visual part and databinding are not available on LGPL edition. The other editions are closed source and available only under commercial license.

The price of Smart GWT Power edition is about $2,000 per developer without support. It's much higher on the Enterprise edition.

http://www.smartclient.com/product/index.jsp

 

Ext GWT is $579 per developer including support. This price is much lower than Smart GWT.

Databing is available on client side in LGPL and that is important. Server side have to be developed but it's not that difficult (or buy it). I did this for Sculptor and it's very straightforward. You can't compare price of Ext with Smartclient Enterprise edition. When you check features in best you can compare with Smartclient Pro edition. Functionality in Power and Enterprise edition is far beyond what Ext provide.

Hi Andrea,

All the visual components with the exception of OLAP / Pivot table are present in the Smart GWT LGPL edition. Additionally Smart GWT LGPL fully supports REST and the community driven GWT-RPC based databinding. The Pro / EE versions support additional Hibernate and Spring Service API based databinding along with SQL connectors but this is something over and beyond what ExtGWT supports. 

Here's a feature comparison table : http://www.smartclient.com/product/competition.jsp 

 

"Andreu Ciordia" posts the same, grossly misleading information on every SmartGWT release announcement, even though he is always patiently corrected by many people.  It is unlikely that he is a disinterested party.  Fair warning.

Ext still have problems with license. Double check what GPL v3 means for your software. Smartclient is LGPL.

And Ext lack in features. Visual part and also databinding.

--> this is misleading. That's why I want to make it clear.

Smart GWT come in four editions: LGPL edition, Professional edition, Power edition and Enterprise edition. Only Smart GWT LGPL edition is under LGPL. The rest three eitions are all proprietary and under the commercial license. http://www.smartclient.com/product/index.jsp

Ext GWT is available under GPL or commercial license. (At least they are honest and make it clear.) Even better, it's totally free to use Ext GWT if your project is open source or for internal use.

In fact, Ext GWT also supports databiding and visual design. Check their website by yourself.

@"Charles Kendrick" and SmartClient company, Don't be panic when people are telling the truth (which you might try to hide on purpose). It's not a shame to make money by commercial licensing.

BTW, from his posts, "Charles Kendrick" always says good about Smart GWT and negative things about Ext GWT and others. Is it a bias? Fair warning.

Andreu you've gone from merely misleading to just absurd.  Yes, there are 3 standard SmartGWT editions and one custom license package (Enterprise).  Likewise, for Ext, there are GPL, commercial, OEM and custom licenses for ExtGWT, and some other licenses for related tools.

The difference is, we at Isomorphic go out of our way to clearly answer every possible license question:

    http://www.smartclient.com/product/licensingFAQ.jsp

And we have made a public commitment to continue to have an LGPL version of the product:

    http://ajaxian.com/archives/smartgwt-lgpl-gwt-wrapper-on-smartclient

Whereas in contrast, Ext made a surprise LGPL to GPL license change on a minor version change, pulling the rug out from under many projects.  In addition, their stock license has an ambiguous definition of "developer" that sounds like you may have to license end users in addition to developers, unless you buy the more expensive OEM license - see the comments here:

    http://www.eweek.com/showblog/56087/REVIEW-Ext-JS-30-Eases-Web-App-Development/

There is no question whose licenses are clearer and which company is the ethical one.  Any doubts?  Google "ext license switch" and see what people are saying.

Finally, our free version is truly free - LGPL is a commercial friendly license used by eg, Hibernate and JBoss.  While companies use GPL software for standalone installations like Linux or MySQL, no large company with a competent legal department uses a GPL software *library* that is deployed alongside their proprietary code.  This means there is no meaningful free option in licensing Ext for mainstream enterprise software development - but there is for SmartGWT.  Any doubts on this?  Talk to your legal department to verify this.

I am the CTO of Isomorphic and this is a widely known fact, not a secret.  That's why I back up everything I say with a means of verifying it.  You, however, continue to hide your commercial affiliation with Ext, and you plainly are out to mislead - which is why you mention our highest public price alongside Ext's lowest, and falsely claim our product is crippled, so obviously false that everyone pounced on you for it.

So - it's a (trivial) exercise for the reader who is misleading and who is providing real information.

Andreu you've gone from merely misleading to just absurd.  Yes, there are 3 standard SmartGWT editions and one custom license package (Enterprise).  Likewise, for Ext, there are GPL, commercial, OEM and custom licenses for ExtGWT, and some other licenses for related tools.

The difference is, we at Isomorphic go out of our way to clearly answer every possible license question:

    http://www.smartclient.com/product/licensingFAQ.jsp

And we have made a public commitment to continue to have an LGPL version of the product:

    http://ajaxian.com/archives/smartgwt-lgpl-gwt-wrapper-on-smartclient

Whereas in contrast, Ext made a surprise LGPL to GPL license change on a minor version change, pulling the rug out from under many projects.  In addition, their stock license has an ambiguous definition of "developer" that sounds like you may have to license end users in addition to developers, unless you buy the more expensive OEM license - see the comments here:

    http://www.eweek.com/showblog/56087/REVIEW-Ext-JS-30-Eases-Web-App-Development/

There is no question whose licenses are clearer and which company is the ethical one.  Any doubts?  Google "ext license switch" and see what people are saying.

Finally, our free version is truly free - LGPL is a commercial friendly license used by eg, Hibernate and JBoss.  While companies use GPL software for standalone installations like Linux or MySQL, no large company with a competent legal department uses a GPL software *library* that is deployed alongside their proprietary code.  This means there is no meaningful free option in licensing Ext for mainstream enterprise software development - but there is for SmartGWT.  Any doubts on this?  Talk to your legal department to verify this.

I am the CTO of Isomorphic and this is a widely known fact, not a secret.  That's why I back up everything I say with a means of verifying it.  You, however, continue to hide your commercial affiliation with Ext, and you plainly are out to mislead - which is why you mention our highest public price alongside Ext's lowest, and falsely claim our product is crippled, so obviously false that everyone pounced on you for it.

So - it's a (trivial) exercise for the reader who is misleading and who is providing real information.

Charles, thank you for taking the effort to explain licensing options. It's very helpful.

Ext still have problems with license. Double check what GPL v3 means for your software. Smartclient is LGPL.

And Ext lack in features. Visual part and also databinding.

This is correct but GXT is a native GWT implementation where SmartGWT is a wrapper around a Javascript lib. A native lib is better in terms of development / debugging.

GXT is actually quite detached from a native GWT implementation. It has its own event model and poor code. As an example look at the use of generics. If you look at the release notes, for every new feature added, there are 20 bugs that need to be fixed.  The 2 big features for GXT 3.0 are "Implement GWT handler design for listeners" which has been in SmartGWT from day 1 (over 1.5 years back) and "Generic implementation refactoring". Both these "features" will break all existing code with nothing to show for the business users. Good luck selling that to management as a reason to pay for an upgrade.

What matters to me most is that Smart GWT is stable and extremely feature rich and does not break backward compatibilty every minor release.

As with normal GWT, with SmartGWT you can trace through your code, set breakpoints, etc.  But SmartGWT offers additional, very valuable tools that are based on it's design as a hybrid JavaScript/GWT architecture.

For example, the Developer Console allows you to dynamically inspect application state, for example, look at the dataset held by a grid, or try calling certain APIs to see if they correct the current problem.  These capabilities aren't available from normal GWT because they would require code to be compiled by the GWT compiler and "added" to the running application somehow - currently not possible.

These features are available in your *live, deployed application* where IDE-based troubleshooting features are no longer available.  This is extremely important for troubleshooting data-related or user-specific problems, which are often the most important problems to solve quickly.  With plain GWT you are stuck trying to debug generated, obfuscated JavaScript with little in the way of tool support.

In addition, SmartGWT has diagnostic logging categories that you can enable or disable dynamically.  These allow you to, for example, see a detailed log of how the current layout policies led to the component sizes you see on the screen.

So in a nutshell, it's definitely not the case that debugging is worse in SmartGWT vs GXT or plain GWT.  In many, many scenarios, there are major advantages to debugging with SmartGWT's hybrid architecture.

So in a nutshell, it's definitely not the case that debugging is worse in SmartGWT vs GXT or plain GWT.  In many, many scenarios, there are major advantages to debugging with SmartGWT's hybrid architecture.

I'm no expert in SmartGWT. I tried it out in a sample application.

The point for me is: I'm NOT able to to debug some SmartGwt related code with my IDE's debugger. (I mean functionality which is in one of the the SmartClient javascript libs). And this is definitley a disadvantage compared to UI libs like mosaic or GXT (at least from my point of view).

Maybe it is possible to compensate this disadvantage with special SmartGWT tools you mentioned.

But what I've seen:  the usage of the tools is not really intuitive (without a proper documentation ->  and I'm not sure if such a documentation is available....)

 

Your first paragraph is mostly wrong. SmartGWT is mostly javascript, with a light weight "Java" wrapper. The GWT development environment only lets you debug "Java" not "Javascript". Take a look at the SmartGWT wrapper and you will notice its awefully small and "missing" a lot when compared to the size of the accompanying javasccript files. This naturally means its just a wrapper / bridge and not a core part of the functionality. Most of the functionality including all the nasty low level browser bits in SmartGWT are in Javascript NOT java, which means you cant look, inspect,  change, watch variables in debug mode, nor do you get all the ability to look at your code or SmartGWT in a structured manner, by type, method references etc. Nope go back to "find"...

Miroslav : I recognize you from the GWT forums. I really think we need some perspective and recognize the target audience. With Smart GWT, you can absolutely debug your application code in Java with breakpoints, inspections, chance / watch variables etc. Nothing changes.. What you are referring to is the portion of the core framework code.

One of the big advantages of writing GWT based applications is that end users write their applications in Java. You absolutely still do this with Java. This is what end users building enterprise applications should really care about if they are working with a good framework and one should very rarely need to debug framework code. And if one thinks this is an absolute prerequisite then they are working under the assumption that the library is very buggy and they need to take a deep dive into, say, how cache synchronization works. This is not the case with Smart GWT which is extremely stable - there are only 27 open bugs and 14 enhancement requests in tracker : http://code.google.com/p/smartgwt/issues/list  And this is for a library that has 6000 API's and arguably one of the most feature rich RIA frameworks.  The underlying framework code is very very stable and if users do find a bug, the process is to report a bug with a testcase and the framework authors fix it mostly in a matter of days.

When I find a bug with IntelliJ or Eclipse, I really submit a ticket on their tracker and continue using the IDE.  Moreover if you are looking to understand the framework code then the entire source of SmartClient in available in readable source form and users can simple inherit the SmartGwtDebug module to use this version. And when you do so, you can very easily debug and step through the framework code using the IE / Safari / Firebug debugger.

Sight must not be lost of what Smart GWT brings to the table. You build highly sophisticated and feature rich applications (in Java) since it packs a wide array of highly configurable advanced controls / widgets right out of the box. End users don't need to worry about how to implement lazy loading, reordable grid columns, advanced filter controls and other toolkit level constructs. Some of these features can take man years to implement correctly. They get to focus on build their application and let the framework worry about adding missing features or bug fixes.

Finally, you mention the "nasty low level browser bits". There's nothing magical about GWT that makes any new widgets written by users work in a cross browser compatible way and neither does it make it magically run super fast. In the end, all that matters is how the code is written. The underlying SmartClient framework code has been developed over the past 10 years and several more man years. One cannot expect end users to start with bare metal GWT and get to this level of sophistication overnight.

Hiho Sanjiv

I only threw my 2c worth in because its important to note two important points.

• GWT only lets one debug java. Any javascript portion is effectively a blackbox.
• All JS frameworks have gotchas and its hard to solve these when you dont have the entire source available during your debugging experience.

Im not saying that pure GWT is somehow the best solution, i was just commenting to keep a few things in perspective. No doubt you yourself will have noticed that a lot of people think because GWT looks like Java that means i can do all things Java - like writing files, opening sockets etc.

I am not commenting on SmartGWT its just the source makes it easierr for everyone to take a look and see whats really happening. Many times the documentation for stuff is incomplete and does not really answer a particular use case. Naturally the definitive answer is to go to the source and try. This is where i was heading, as with SmartGWT you dont have the entire source so it might be a little different when one wishes to find out what can, or how or what can not be done.

 

 

 

Miroslav, I agree that on occasion when one runs into an issue being able to step through framework code is a desirable. However this is possible with Smart GWT because the entire core framework code is distributed with SmartGWT, full with very comprehensive docs and not locked in a blackbox. After all even with pure GWT one does need to resort to troubleshooting with other non-Java tools like Firebug every so often.

With Smart GWT, you can set your simply set a breakpoint in the application code (Java) before the method of interest is invoke and when the breakpoint is hit evaluate the expression SC.debugger(). This effectively calls the "debugger" command which triggers breakpoints in IE, Firebug and Safari and they all have very capable JS debuggers with the ability to navigate call stacks, evaluate expressions, conditional breakpoints etc. While I agree this is not as convenient as stepping through core framework Java code, its not too inconvenient either especially if we recognize that users only need to do very occasionally when they run into an issue and want to try troubleshooting the matter themselves. This should not be the starting point of evaluation of a framework with the pessimistic viewpoint that functionality is mostly broken and they would need to resort to troubleshooting core framework code all the time. I do agree with you that it would have been nice if the core framework code was in Java, but all things considered I feel this is relatively minor issue given the other advantages that the hybrid approach brings to the table and the end goal of facilitating rapid development of enterprise applications with the end user having to write minimal amount of code since the boilerplate framework level code is handled very elegantly by Smart GWT. 

 

Have a look at the MVC sample and associated source via the View Source button : http://www.smartclient.com/smartgwt/showcase/#featured_smartgwt_mvc where changes made to any databound control are automatically propagated to all other databound controls with 0 lines of end user code. 

Another example is the Pattern Reuse sample : http://www.smartclient.com/smartgwt/showcase/#featured_pattern_reuse It has a ListGrid and editable form capable of being bound to any arbitrary DataSource. The amount of meaty code involved is quite incredible - only some 15 to 20 lines of user code. Consider the amount of time and lines of code one would ordinarily need to write  (on client, and server) to produce similar functionality.

The end use expectation with Smart GWT should still be that core functionality works as documented and advertised.

I personally prefer to have less context switches if i can help it, as i am sure most people would probably agree. While SmartGWT obviously comes with source for both java and js, you cannot debug across the bridge and have it all make sense. Eg one cant see Java objects in Javascript meaningfully and vice versa. While there are ways around this it is not the same seamless experience. This level of integration is similar to that of the various scripting languages and java. They in the end play together but its fairly obvious where the boundaries and stiches are. Making sweeping statements like the one i originally replied to is not helpful if one is new to some technology, one needs some perrspective.

Miroslav, before you compare debugging in the SmartGWT hybrid architecture to debugging in a Java-only architecture, I think you should *actually try* the development tools that come with SmartGWT so that you can understand the large advantages that the hybrid architecture provides.

A very very brief overview is here:

    http://forums.smartclient.com/showthread.php?t=8159#aConsole

We plan to expand on this to address in more detail how the tools in the Developer Console help you solve problems more quickly than step-through debugging.  But what I would state in a nutshell is:

1. with SmartGWT, you can trace through your own application code normally in the debugger

2. it is almost always far more effective to use the tools in the Developer Console than to trace through framework code, which requires a much deeper knowledge to understand

Before responding again about the value you perceive in being able to step through low-level framework code, please gain some experience with the toolset we provide so you know what you are comparing against.  Thanks.

Does SmartGWT have any support for UIBinder or plans to support this?

I think UIBinder is the way to go going forward.  Doing layout for complex screens in Java is a pain, especially if you're looking at somebody else's code and trying to visualize what piece of code is responsible what that particular piece of layout. 

XML obviously isn't too great, but its much better, at least for me, to visualize layout.  Also, with the UIBinder xml, its just a matter of time before WYSIWYG tools take advantage of it.

UIBinder is currently closed, to support your own tags one must hack the right class as its not an open id -- yet.

What do u mean with closed? ... I think UIBinder is included in GWT 2.0 or 2.1 ...

GWT is the base foundation on which we can build. The default UI controls from the GWT are pretty basic, which supports a lot of customization. But if you want to use some built-in nice controls you have to use one of the widgets libraries built on top of GWT: SmartGWT, Ext GWT (GXT) or GWT-Ext (dead one).

Here's info about each one "http://ui-programming.blogspot.com/2010/01/comparation-ext-gwt-gxt-vs-gwt-ext-vs.html

 

Cheers!

Sorinel CRISTESCU
 

i choose Google coz it is more stable than yahoo

buffalo freelance website designer

I like them both..i use them both

stork club new york

Nie od chwili w dzisiejszych czasach rozumie się samo przez się o szkodliwości elektroniczne papierosy kurzenia. Jednostki, jakie ścięły nałóg tytoniowy, bąkają spośród mitręgą zupełny ten przebieg. Interesy farmaceutyczne elektroniczne papierosy osiedlają w tej chwili niejaki epoka wynalazki i artykuły wspomagające w ciskaniu przyżegania. Pojawiły się elektroniczne papierosy ergo rozliczne płaty nikotynowe, gumy aż do przeżuwania a nieelektronowe papierosy. Elektronowe pety (znamienite również w charakterze elektroniczne papierosy) to najświeższy artykuł na rynku. Stanowią one opracowane, żeby oczekiwać zaś wykonywać jak rzetelne pety. Promieniują też oszukany dym, pomimo tego w realności nie wymieniają tytoniu. Kontrahenci elektroniczne papierosy wdychają mgły nikotyny, jakie kserują kurz ogołocony podstaw rakotwórczych, które egzystują podłe na rzecz palącego oraz drugich postań.