At the time of writing the following are available:
GWT v2.0
and.....
SmartGWT v2.0 (http://code.google.com/p/smartgwt/ under Apache
License)
Ext GWT v2.1.0 (http://www.extjs.com/products/gxt/ under weird LGPL
License)
I don't want to discuss Ext GWT's weird license. It's weird, there's
no updates... e.t.c. e.t.c. The question is, if why would you purchase
it over SmartGWT? I am looking for technical reasons such as features,
performance, jsni wrap vs pure compiled gwt, or especially full GWT
2.0 compatibility e.t.c.
Help would be great as there are so many re-packed versions of these
things floating around as well as the fact a lot of information is out
of date (and so will this thread be in the not so distant future).
Thanks heaps in advance :)
On 29 Jan., 01:16, ahhughes <ahhug...@gmail.com> wrote:
> For future reference....
>
> At the time of writing the following are available:
> GWT v2.0
> and.....
> SmartGWT v2.0 (http://code.google.com/p/smartgwt/under Apache
> License)
> Ext GWT v2.1.0 (http://www.extjs.com/products/gxt/under weird LGPL
Just a tour through the SmartGWT and SmartGWT Pro/EE showcases should
be enough to identify a number of feature advantages which may matter
for your application.
http://www.smartclient.com/smartgwt/showcase/
http://www.smartclient.com/smartgwtee/showcase/
On Jan 29, 4:58 am, Siegfried Bolz <siegfried.b...@googlemail.com>
wrote:
> I am currently using GXT 2.1.0 on a big customer project and my
> experience is, that it is a great framework to
> produce fast results. There are some bugs in each release but you have
> the possibility to override the methods
> to fix the bug by yourself. If you want to extend a widget, it is
> possible.
> One reason where i think this could be a problem in the future, is
> that GXT use Listeners instead of Handlers.
> With release 3, i think there could be a big API change coming.
>
> On 29 Jan., 01:16, ahhughes <ahhug...@gmail.com> wrote:
>
> > For future reference....
>
> > At the time of writing the following are available:
> > GWT v2.0
> > and.....
> > SmartGWT v2.0 (http://code.google.com/p/smartgwt/underApache
> > License)
> > Ext GWT v2.1.0 (http://www.extjs.com/products/gxt/underweird LGPL
http://ui-programming.blogspot.com/2010/01/comparation-ext-gwt-gxt-vs-gwt-ext-vs.html
you can find more info about the same topic.
Cheers!
--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
- Both GXT and Smart GWT are pure gwt (no underlying native JS library, so expect equivalent speed/performance from the GWT compiler).
Additionally: both have WEIRD commercial licenses! I didn't want to talk about them... but they're probably the deciding factor here now anyway.
- GXT's commercial license is "all features" but you only get the incremental X.* updates (i.e. 2.1, 2.2, 2.3 but not 3.0).
- SmartGWT's commercial licensing appears to be limited on feature set. How useful SmartGWT's widgets are without the complete featureset (i.e. databindings e.t.c) remains a mystery and therefor a risk.
Nope, SmartGWT is a wrapper to SmartClient JS Library.
ckendrick and I have different understandings about override ... :-P
We already discussed this some time ago ...
SmartGWT you can't override it's functionality, just it's behavior.
SmartGWT is more feature rich than GXT, but I don't like their
licensing terms, I prefer GXT one, not only because the price, but the
features, we just need a UI framework, the server we already have one.
Regards.
If you are interested in how I solved this problem for QxWT you should
take a look at this series of posts.
[1]http://tomsondev.bestsolution.at/2010/01/05/background-to-qxwt-and-gwt-generator-integration/
[2]http://tomsondev.bestsolution.at/2010/01/10/qxwt-explained-part-2/
[3]http://tomsondev.bestsolution.at/2010/01/12/qxwt-explained-part-3/
[4]http://tomsondev.bestsolution.at/2010/01/15/qxwt-explained-part-4/
The overloading/overwriting use case is discussed in [3]. I have no
deeper insights in SmartGWT but I guess writing something like this is
possible for their set of widgets as well (Probably one can extract
the code I've written for QxWT and make it useable to any JSNI-Wrapper
and even improve the functionality e.g. calling back to JavaScript
without writing any line of code, ... a rather advanced example can be
found here [5]).
BTW QxWT is completely free - everything is dual licensed under EPL and LGPL.
Tom
http://www.smartclient.com/smartgwt/showcase/#grid_appearance_hilite_add
As far SmartGWT's free vs commercial breakdown is exceeding the
simple: the commercial versions include Java Server functionality.
It's explained clearly here:
http://www.smartclient.com/product/
We also make a nice clean, clear distinction in the showcases.
Everything in this one is free:
http://www.smartclient.com/smartgwt/showcase/
This one has commercial functionality:
http://www.smartclient.com/smartgwtee/showcase/
There is no "mystery" or "risk" regarding what is free and what is
not, or whether it's useful.
Some other mis-statements in this thread:
1. the free version of SmartGWT supports databinding as well.
Approaches are covered here:
http://www.smartclient.com/smartgwtee/javadoc/com/smartgwt/client/docs/ClientDataIntegration.html
2. someone mentioned "already having" a server. SmartGWT's server-
side functionality integrates with any pre-existing server-side
functionality and provides features that don't exist in any server-
side library, so it applies regardless of whether you have a server or
not. Two examples:
Client and server-side validation driven from a single definition, so
you don't have to set up validation logic in both places:
http://www.smartclient.com/smartgwtee/showcase/#data_integration_form_validation
Automated aggregation of client-side requests into a compound request
to make transaction handling easier, cut down on HTTP requests and
simplify the re-use of data services:
http://www.smartclient.com/smartgwtee/showcase/#row_drag_save
And a deeper explanation of how SmartGWT's server-side features apply
even if you have a pre-existing persistence system and business logic:
OK, that's it from the misconception police for today :)
On Feb 1, 6:24 am, Tom Schindl <tomson...@gmail.com> wrote:
> Though many people think that Overloading/Overwriting and JSNI don't
> really fit together.
> I think they do if you are a bit creative.
>
> If you are interested in how I solved this problem for QxWT you should
> take a look at this series of posts.
>
> [1]http://tomsondev.bestsolution.at/2010/01/05/background-to-qxwt-and-gw...
> [2]http://tomsondev.bestsolution.at/2010/01/10/qxwt-explained-part-2/
> [3]http://tomsondev.bestsolution.at/2010/01/12/qxwt-explained-part-3/
> [4]http://tomsondev.bestsolution.at/2010/01/15/qxwt-explained-part-4/
>
> The overloading/overwriting use case is discussed in [3]. I have no
> deeper insights in SmartGWT but I guess writing something like this is
> possible for their set of widgets as well (Probably one can extract
> the code I've written for QxWT and make it useable to any JSNI-Wrapper
> and even improve the functionality e.g. calling back to JavaScript
> without writing any line of code, ... a rather advanced example can be
> found here [5]).
>
> BTW QxWT is completely free - everything is dual licensed under EPL and LGPL.
>
> Tom
>
> [5]https://svn.tomsondev.com/svn/ufacekit/qx/org.ufacekit.qx.viewers/src...
I like a GXT and wrote a form generation library for it that you might
consider.
http://gxtforms.googlecode.com/
There's an appengine demo linked to from the project pages.
The basic is idea to annotate Model classes and get forms with
data-binding fairly easily. For the next release, I'm working to make
the field types and rendering more easily extensible. If anyone is
interested in contributing to this project, please let me know.
-Dave
I have no ties with Ext whatsoever, but we're using GXT now because
it's built on top of GWT (not a wrapper of some JS library).
Customization is much easier and whenever a problem arises, you can
always trace down to the very bottom because they're all written in
Java. The same cannot be said about SmartGWT. Having said that, GXT
has quite a few quirks as well. Seems they've been abusing generics
and the event system is terrible to work with.
If you have the time and resource, I'd say writing in pure GWT is the
way to go.
Those are my subjective opinion. I've no intention of trolling.
On Feb 2, 12:28 pm, mariyan nenchev <nenchev.mari...@gmail.com> wrote:
> Thanks i look at it, but i prefer to use pure gwt&incubator. Advanced
> components also seems good.
> On Tue, Feb 2, 2010 at 7:19 PM, David Durham <david.durham...@gmail.com>wrote:
>
>
>
> > On Thu, Jan 28, 2010 at 6:16 PM, ahhughes <ahhug...@gmail.com> wrote:
> > > For future reference....
>
> > > At the time of writing the following are available:
> > > GWT v2.0
> > > and.....
> > > SmartGWT v2.0 (http://code.google.com/p/smartgwt/under Apache
> > > License)
> > > Ext GWT v2.1.0 (http://www.extjs.com/products/gxt/under weird LGPL
> > > License)
>
> > > I don't want to discuss Ext GWT's weird license. It's weird, there's
> > > no updates... e.t.c. e.t.c. The question is, if why would you purchase
> > > it over SmartGWT? I am looking for technical reasons such as features,
> > > performance, jsni wrap vs pure compiled gwt, or especially full GWT
> > > 2.0 compatibility e.t.c.
>
> > > Help would be great as there are so many re-packed versions of these
> > > things floating around as well as the fact a lot of information is out
> > > of date (and so will this thread be in the not so distant future).
>
> > I like a GXT and wrote a form generation library for it that you might
> > consider.
>
> > http://gxtforms.googlecode.com/
>
> > There's an appengine demo linked to from the project pages.
>
> > The basic is idea to annotate Model classes and get forms with
> > data-binding fairly easily. For the next release, I'm working to make
> > the field types and rendering more easily extensible. If anyone is
> > interested in contributing to this project, please let me know.
>
> > -Dave
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Google Web Toolkit" group.
> > To post to this group, send email to google-we...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > google-web-tool...@googlegroups.com<google-web-toolkit%2Bunsubscr...@googlegroups.com>
http://groups.google.com/group/google-web-toolkit/msg/693cacbce437d08a
GXT's layout system is alien to GWT, the documentation is nonexistant,
the appearance is highly inflexible, and the attitude of the support
team sucks (even for customers that pay for support). Consider, for a
moment, that there is nobody at Ext commenting on the GXT-related
threads that show up in this forum. Totally out to lunch.
Unless you specifically need an advanced grid control, you're better
off rolling your own UI in vanilla GWT. Do not think "GXT will be
just like GWT, only prettier" - it is an entirely different creature
with a wholly incompatible (and irritatingly inconsistent) widget
library.
Jeff
> To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
Yes, it is.
> I do not know what are the changes in 2.0, i used 1.2, but i am not will never try it again.
Yes. And nobody here likes resource management. And Smart GWT is very
buggy. Yes, it is horrible, yes it is painful, but I am not really
sure what else exists that would work on older browsers, while having
same set of functionality. Maybe one day I have to play with
http://vaadin.com/ a little, but currently I stick to SmartGWT: works
for me, though I have to roll my eyes and sight deeply at least twice
per hour, while implementing things.
--
BM
Sanjiv, I remember all that ugly story with you and Ext stuff. And
really appreciate the thing you do. But still, what's wrong with a
constrictive criticism? I am using SmartGWT as the only lib so far in
many projects (although free version :-). So at least I have a right
to "smoke my cigarette" and share with others that the lib is not very
brilliant BUT usable, so no need to run elsewhere, but TRY to improve
it (that's what I said between the lines, BTW). And you also have a
right to listen my stupid feedback and make your own conclusions. :-)
Besides, as a little example among dozen of others, folks (including
myself) were sending multiple complains to the forum about calendar
dialogs that are not customizable, that they are literally fugly:
because who would need ridiculously big dialog while editing an event,
but widgets are very small and grouped at left/top corner? — all the
rest space is for banners and ads or something?.. How to nicely
replace that dialog with my own and why this is so obvious thing
simply hard-coded? etc. Or I am missing something and this is changed
already? So far I've simply either got ignored or being told "we won't
change that".
Hence, if you, guys, "won't change that because we said so", then I
doubt anyone would waste their time writing any feedback or bugreport
knowing it will be rejected/ignored anyway...
--
bm
"GXT's layout system is alien to GWT, the documentation is
nonexistant,
the appearance is highly inflexible, and the attitude of the support
team sucks (even for customers that pay for support). Consider, for a
moment, that there is nobody at Ext commenting on the GXT-related
threads that show up in this forum. Totally out to lunch. "
is 100% accurate to my experience. I don't have the luxury of ripping
it out of my app at work, but I wouldn't use it in personal app if it
were free.
Everything you know about GWT and GWT widgets can basically be thrown
out the window. The event model is entirely different. The widgets
have a ton of properties that are set on construction that you cannot
change. Oh and when you decide on GXT know that you're probably going
to be locked into that version and will not be able to upgrade to any
new versions of the software.
I would recommend not using GXT.
> On Tue, Feb 2, 2010 at 11:03 PM, Bogdan Maryniuck <b.maryni...@gmail.com>wrote:
>
> > On Wed, Feb 3, 2010 at 12:31 PM, Sanjiv Jivan <sanjiv.ji...@gmail.com>
> > google-web-tool...@googlegroups.com<google-web-toolkit%2Bunsu...@googlegroups.com>
I think that this criticism is good for every one.
SmartGWT is very good in Server-side integration, with a lot UI
widgets, but it's a wrapper to JS and you can't override the way it
work internally(Yes, some will disagree), you can just override some
PROPERTY methods, and I think that this discussion is over.
GXT has no Server-side integration, they have far less widgets than
SmartGWT, but, it's pure Java, you can change it completely just
overriding some methods or classes and yes, NO documentation at all,
theirs JavaDoc just SUCKS.
But.... I'd prefer GXT instead SmartGWT. My experience with SmartGWT
isn't that good, the way the data is managed in the UI is a little bit
weird to me.
I'd recommend to use GXT.
> > > google-web-tool...@googlegroups.com<google-web-toolkit%2Bunsubs cr...@googlegroups.com>
How do GXT apps work when surfed to by an iPhone?
SmartGWT is very good in Server-side integration, with a lot UI
For example, I needed to add a rowexpander to a grid that expanded out
to show editable record details. GXT has a widget that lets you inject
arbitrary html into an expanded row out of the box. This obviously
sucks when your dealing with a complex and interactive editable row
detail. The entire point (for us) of working in this environment is to
be widget driven vs html driven. With a touch of work I was able to
expand the RowExpander class with my own version that allowed me to
put a Composite Panel in the expanded row vs plain html which let all
of my other tools and the panels sub-components do their job. Once
again, very Wicket-Like for me.
Probably totally possible and easy for SmartGWT (maybe even Out Of The
Box) but I also found it very easy with GXT.
The docs are crap though. One you get into the 'GXT Mindset' it comes
fast and easy but it takes a looooonggggg time to get into the GXT
mindset.
We will evaluate SmartGWT for a future project, the pace of
development there and the level of support can't really be denied. GXT
is falling over in this regard. Slow release process and no real
support (even Premium forums are mostly dead) is a big concern.
For now we're GXT though.
John-
I did find the layout managers a little bit lacking so I wrote my own
layout manager which is far superior. Most of our UI's are form
related and fairly complex which is where simple uni-directional
layouts like the ones in GXT are worst suited. I also borrowed some
swing/awt concepts such as invalidate/revalidate so if you change a
value in any component which will affects its bound size, it will
bubble up invalidating all components to the top layout container and
then run the layout. But after all of this, I'm not sure if the GXT
layout managers are the best approach. Performing layout via
javascript is a little sluggish - except in chrome. I'm hoping the
other browsers catch up.
If you decide to use GXT 2.0, you won't be able to use some of the
newer GWT features, like UIBinder. And for the most part, once you
start using GXT, you should avoid using any plain GWT concepts. All
of our components are built off of the base GXT component and
boxcomponent classes.
If I were working on a simpler project, such as a personal project, I
would use plain GWT.
In other words, let's back to applets/JNLP. :-) JavaFX, for example,
is a great thing anyway. For graphs/charts etc. And CPU/memory wise it
is still reasonable and competitive. The only thing I really dislike:
that ugly startup in the applet. But once it is cached — users are
very satisfied much more than with Flash thing.
--
bm
http://www.smartclient.com/smartgwt/showcase/#featured_nested_grid
http://www.smartclient.com/smartgwtee/javadoc/com/smartgwt/client/types/ExpansionMode.html
In the latest nightlies you can play with yet another level of
sophistication, for release in 2.1:
1. general purpose APIs for attaching components to any individual
cell or row, with multiple sizing modes
2. support for automatic pooling of components at the record level,
for use cases where you have components in most/every row and you are
paging through a large dataset and need to re-use a pool of components
attached to the currently visible records
If it's a "positive" experience to have to fix a lot of bugs, and have
to add missing features, can't wait to see what you guys say when you
evaluate SmartGWT for your next project ;)
My take on this:
Point #1: Both GXT and SmartGWT have issues. There are so many
different opinions in this discuss and I feel that signifies that
neither have been widely accepted as reliable/mature/enterprise
extensions. Respond if you like, but the evidence is past history :)
Point #2: There are issues regarding JSNI wrapping libraries (i.e. not
"pure gwt") which result in instability, inconsistancies between API's
and a lack of interaction between JavaScript and GWT communities. None
of which is beneficial and is causing problems.
Conclusion:
Sticking to just the CORE GWT 2.0 seems like the best advice! In case
you are wondering, here's how.. http://code.google.com/webtoolkit/doc/latest/DevGuide.html
CHEERS :)
* Writing your own UI in straight-up GWT is not as hard as you might think.
The stock widgets are not beautiful out-of-the-box but they are
heavily customizable with CSS. They are *very* easy to learn and
nearly always behave "the way you would expect". You can extend the
stock widgets easily, adding behavior, events, visual effects,
whatever you want. Client/server communication is already elegantly
implemented in stock GWT.
GXT and SmartGWT have very pretty demos. If what you're really
looking for is an attractive app (as opposed to specific behavior in
some of their advanced widgets), consider that they both have very
steep learning curves. In the time it will take you to learn to use
these systems with facility, you could learn enough to extend GWT with
custom widgets and customize the CSS to your liking. Maybe even
publish a few pieces as opensource for the rest of us :-)
It should also not go without mention that GXT and SmartGWT will have
a significant impact on the size of your download. Even trivial GXT
apps are 600+k, and code splitting is useless.
Jeff
> --
> You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
> To post to this group, send email to google-we...@googlegroups.com.
> To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
The features I like about GXT are:
- The UI looks super clean and polished
- I actually like the layouts managers - I spent too many years
doing Swing, so my brain is warped into understanding things like
BorderLayout.
- Its developed by the same company/group/people that work on EXT
- The grid can easily handle "large" sets of data (1000 rows per
page, with delayed rendering). One of the previous posts griped about
no server-side integration, but I disagree - GXT provides objects like
BasePagingLoadConfig and BaseTreeLoader for asynchronous on-demand
loading of data.
I haven't used SmartGWT, so it probably has many of these same nifty
features. I basically had about a day to pick one, and so far GXT
hasn't disappointed me.
Good luck!
GXT API is much like the AWT API.
> > > > google-web-tool...@googlegroups.com<google-web-toolkit%2Bunsubs cr...@googlegroups.com>
On Feb 3, 2:21 pm, Jonathan <jona...@gmail.com> wrote:
> > > > google-web-tool...@googlegroups.com<google-web-toolkit%2Bunsubs cr...@googlegroups.com>
Anyhow, we'll be looking on our next project and seeing how we feel
about it. Extended GXT was very simple for us once we got over the
learning curve and SmartGWT will have the same learning curve.
John-
On Feb 3, 4:26 pm, ckendrick <charles.kendr...@gmail.com> wrote:
> Re: widgets inside grid rows: not only is it "out of the box" in
> SmartGWT, there are multiple out of the box modes for it, including
> nested editable grids.
>
> http://www.smartclient.com/smartgwt/showcase/#featured_nested_grid
> http://www.smartclient.com/smartgwtee/javadoc/com/smartgwt/client/typ...
Note that even if you don't have hard requirements for these features,
the fact is that they make your application better, and you will never
have to deal with a user request for such a feature: it's already
there.
ahhughes as far as your #2, please point to examples. Almost everyone
who has *actually tried* SmartGWT remarks on the extremely low number
of bugs.
@Tercio, mariyan: unclear on why you found server integration with the
SmartGWT LGPL version difficult. All you need to do is expose your
EJBs as REST services and there are countless tutorials on the web on
how to do this, as well as frameworks that can do this from Java
annotations. People achieve this all the time.
Tercio in particular, I'm guessing this was you:
http://forums.smartclient.com/showthread.php?t=5632
You took the wrong approach, and our Support staff told you it wasn't
a good idea and gave you appropriate alternatives.
As far as "useless" features, if you think they're useless, you
frankly have not absorbed what they actually do. Remember, Isomorphic
is a consulting company too. We build applications in defense, life
sciences, insurance, financials and many other verticals. We use the
features of Pro/EE *every single time*.
Dude, but after all, SmartGWT so far is the best among others, despite
its somewhat tragifunky API. Yes, for us, who are doing Swing as well,
SmartGWT is quite painful, although it intended to be like Swing for
Web. Yes, method names are wicked, composing widgets is weird etc. And
there is also a number of reasons why they're done this way — hence
let's don't regard them as fools — the guys, actually doing awesome
job. Because what else on the market is available right now that could
solve a huge number of a problems that we facing every day, making
enterprise software for the Web?
Personally I don't like concentrating on JavaScript horror and prefer
Java Swing over JNLP in most cases. In Enterprise controlled internal
network we never allow web stuff — there is only Swing and it works
rock stable. But it requires very clean and highly controlled
networks. Since outside the company, in the wild world, there are
anything you might expect, so browsers + JavaScript + HTML is the only
way. However, it is horrific way to make UIs, has no real standards,
is very unpredictable, slippery and unreliable.
So let's better think how we can help them instead, because everyone
can bashing things: that's no brainer...
--
bm
The only person with hands-on experience claiming there are bugs
turned out to be talking about a particular, narrow Calendar
enhancement that he was displeased had not received more attention.
The actual samples should be self-explanatory. The functionality
demonstrated is extremely broad and deep, the code required is clear
and concise, it's difficult to find a bug and what few exist are
addressed quickly.
See for yourself.
http://www.smartclient.com/smartgwt/showcase/
http://www.smartclient.com/smartgwtee/showcase/
But I am encouraged by the wrapping of Qooxdoo (finally) at
http://www.ufacekit.org/index.php?cat=02_Qooxdoo&page=01_QxWT.
The latest Demo can be found here:
http://www.ufacekit.org/qxwt/demos/QxDemo-dev/QxDemo.html. The next
release is scheduled for End of Febuary and I'm just working on a real
world example application as a show case.
From a technical point of view QxWT is doing the same SmartGWT does
because after evaluating a complete
rewrite in Java it didn't make sense to me from a business point of
view (I guess the same was true for SmartGWT).
I've used SmartGWT some time ago and didn't had any problems with
using it still I decided to start QxWT
because though it might sound strange LGPL is something some of my
customer don't allow to be used (hence all code is dual licensed under
EPL and LGPL)
and because I'm confident that there has to be competition and we can
learn all from each other.
Another important part which made me write the QxWT port is that
Qooxdoo-Widgets are plain widgets which means there are no stores
and all those stuff but I can create my own domain-model integration
(I don't know if this changed since I worked with SmartGWT and GXT).
For those interested on the progress can subscribe themselves to my
personal blog http://tomsondev.bestsolution.at/
Tom
Pros
- I think the look and feel is sharp and responsive (much nicer that
SmartGWT IMHO - but look at the showcases and judge for youself).
- Grids are the best I've seen (sorry SmartGWT) but no lockable
columns (which Smart does have) - we had to write our own (I've
posted them on the forums)
- It's all java and it's trivial to debug / overrride features
- Good community in the forums
- Bugs get fixed if you are persistent enough
Cons
- Quirky bugs and behaviour changes in each version - need to check
for regression when taking an upgrade.
- Only first point release if available if you don't have a support
contract (even if you buy the product) and there can be a long wait
(for your business / customers) between versions.
- Mostly trivial examples in showcase that aren't like an app you will
build (though to be fair same can be said for most GWT frameworks)
- Not much doco / java doc, which can make complex apps / layouts
difficult to get right - some unexpected behaviours
On skins, you don't sound as though you've looked at the Showcase
since 2.0, when we made a series of improvements which now has most
users commenting that our skins are sharper than GXTs.
On grids, this is the first time I've ever seen someone claim the GXT
grids are better, I really don't think you took more than a cursory
look at the samples. Here are some of the largest features missing
from GXT's grids (there are many many more):
Adaptive Filtering
http://www.smartclient.com/smartgwt/showcase/#grid_adaptive_filter_featured_category
Databound Dragging
http://www.smartclient.com/smartgwt/showcase/#grid_db_dragging_featured_category
Custom nested components (embed anything)
http://www.smartclient.com/smartgwt/showcase/#featured_nested_grid
http://www.smartclient.com/smartgwt/showcase/#grid_nested_form_new_category
Pluggable data models (build a master-detail component for any data
model)
http://www.smartclient.com/smartgwt/showcase/#featured_master_detail
Frozen columns with editing, drag and drop and all other features
still supported
http://www.smartclient.com/smartgwt/showcase/#grid_frozen_editing
Multi-level sort
http://www.smartclient.com/smartgwt/showcase/#grid_multisort_new_category
Automatic cache synchronization on update
http://www.smartclient.com/smartgwtee/javadoc/com/smartgwt/client/data/ResultSet.html
Multi-level filtering
http://www.smartclient.com/smartgwt/showcase/#grid_nested_filter_builder
Multiple rows of headers
http://www.smartclient.com/smartgwt/showcase/#grid_appearance_header_spans
User-specified formula and summary columns
http://www.smartclient.com/smartgwt/showcase/#grid_appearance_formula_sumamry_builder
Also, once again, these features work *together*. There are many
combinations of GXT features that don't (eg Live Grid and most major
grid features), and if you go with some hack from the forums to enable
one of the missing features, you'll find even less compatibility with
other features (and no support).
Just didn't want anyone to think the grids are even close to
comparable. The features above are all part of the free LGPL edition
by the way.
On Feb 14, 7:00 pm, Carl Pritchett <bogusggem...@gmail.com> wrote:
> We have used GXT from 1.2 to 2.1.1 on a mid-sized project.
>
> Pros
> - I think the look and feel is sharp and responsive (much nicer thatSmartGWTIMHO - but look at the showcases and judge for youself).
> - Grids are the best I've seen (sorrySmartGWT) but no lockable
Drag Reorder of columns
http://www.smartclient.com/smartgwt/showcase/#grid_appearance_columnorder
The CubeGrid (multi-dimensional data model support)
http://www.smartclient.com/index.jsp#basicCube
http://www.smartclient.com/index.jsp#analytics
A whole range of autoFit behaviors (not just this sample, the whole
folder)
http://www.smartclient.com/smartgwt/showcase/#grid_autofit_filter
Also, the fact that all of these features also apply to TreeGrids (eg
frozen columns and full-row editing).
Also, SmartGWT's data connector architecture and it's ability to
support multiple caches on the same large data set, with independent
search criteria, sort direction, etc. This is needed for dozens of
use cases involving large data sets, such as moving records from one
category to another by drag and drop. GXT's "Store" is extremely
primitive by comparison and a lot of manual effort is required to
achieve something like this:
http://www.smartclient.com/smartgwtee/showcase/#row_drag_save
I have probably missed another 9 major grid features, and this only
covers feature advantages related to grids, however this and my
previous post are probably the best answer to the original question:
what are the technical advantages.
On Feb 15, 12:02 pm, ckendrick <charles.kendr...@gmail.com> wrote:
> Carl,
>
> On skins, you don't sound as though you've looked at the Showcase
> since 2.0, when we made a series of improvements which now has most
> users commenting that our skins are sharper than GXTs.
>
> On grids, this is the first time I've ever seen someone claim the GXT
> grids are better, I really don't think you took more than a cursory
> look at the samples. Here are some of the largest features missing
> from GXT's grids (there are many many more):
>
> Adaptive Filtering
> http://www.smartclient.com/smartgwt/showcase/#grid_adaptive_filter_fe...
>
> Databound Dragging
> http://www.smartclient.com/smartgwt/showcase/#grid_db_dragging_featur...
>
> Custom nested components (embed anything)
> http://www.smartclient.com/smartgwt/showcase/#featured_nested_grid
> http://www.smartclient.com/smartgwt/showcase/#grid_nested_form_new_ca...
>
> Pluggable data models (build a master-detail component for any data
> model)
> http://www.smartclient.com/smartgwt/showcase/#featured_master_detail
>
> Frozen columns with editing, drag and drop and all other features
> still supported
> http://www.smartclient.com/smartgwt/showcase/#grid_frozen_editing
>
> Multi-level sort
> http://www.smartclient.com/smartgwt/showcase/#grid_multisort_new_cate...
>
> Automatic cache synchronization on update
> http://www.smartclient.com/smartgwtee/javadoc/com/smartgwt/client/dat...
>
> Multi-level filtering
> http://www.smartclient.com/smartgwt/showcase/#grid_nested_filter_builder
>
> Multiple rows of headers
> http://www.smartclient.com/smartgwt/showcase/#grid_appearance_header_...
>
> User-specified formula and summary columns
> http://www.smartclient.com/smartgwt/showcase/#grid_appearance_formula...
--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
Our current KATO demo ( see http://myjsp.dynamicalsoftware.com/kato )
uses SmartGWT and, though not perfect, the default eye candy does look
nice and we will most probably stay with SmartGWT.
Those who are in Birmingham, AL might consider attending the JUG ( see
http://groups.google.com/group/birmingham-jug ) meeting on the 25th
where I will give a presentation on GWT. In that talk, I will share my
opinions on Incubator, SmartGWT, and GXT.
On Feb 15, 2:02 pm, ckendrick <charles.kendr...@gmail.com> wrote:
> Carl,
>
> On skins, you don't sound as though you've looked at the Showcase
> since 2.0, when we made a series of improvements which now has most
> users commenting that our skins are sharper than GXTs.
>
> On grids, this is the first time I've ever seen someone claim the GXT
> grids are better, I really don't think you took more than a cursory
> look at the samples. Here are some of the largest features missing
> from GXT's grids (there are many many more):
>
> Adaptive Filtering
> http://www.smartclient.com/smartgwt/showcase/#grid_adaptive_filter_fe...
>
> Databound Dragging
> http://www.smartclient.com/smartgwt/showcase/#grid_db_dragging_featur...
>
> Custom nested components (embed anything)
> http://www.smartclient.com/smartgwt/showcase/#featured_nested_grid
> http://www.smartclient.com/smartgwt/showcase/#grid_nested_form_new_ca...
>
> Pluggable data models (build a master-detail component for any data
> model)
> http://www.smartclient.com/smartgwt/showcase/#featured_master_detail
>
> Frozen columns with editing, drag and drop and all other features
> still supported
> http://www.smartclient.com/smartgwt/showcase/#grid_frozen_editing
>
> Multi-level sort
> http://www.smartclient.com/smartgwt/showcase/#grid_multisort_new_cate...
>
> Automatic cache synchronization on update
> http://www.smartclient.com/smartgwtee/javadoc/com/smartgwt/client/dat...
>
> Multi-level filtering
> http://www.smartclient.com/smartgwt/showcase/#grid_nested_filter_builder
>
> Multiple rows of headers
> http://www.smartclient.com/smartgwt/showcase/#grid_appearance_header_...
>
> User-specified formula and summary columns
> http://www.smartclient.com/smartgwt/showcase/#grid_appearance_formula...
It's worrysome:
Thread
http://forums.smartclient.com/showthread.php?t=3012
Bug report asking for RPC datasource
http://code.google.com/p/smartgwt/issues/detail?id=303
I see there is an api but it states:
Smart GWT supports declarative, XPath-based binding of visual
components to any server capable of returning XML or JSON responses
over HTTP, without the need for the 'Smart GWT server'.
> A fetch operation for example will pass the startRow, endRow and the
> applications server side code needs to return data as XML, JSON or GWT-RPC
> beans in response to this request.
> : http://www.smartclient.com/smartgwt/showcase/#featured_restfulds
Are there any examples using GWT-RPC (without the smart server)
Sanjiv what you said and what the docs say seem to be different. Can
we really use GWT-RPC to get a bean back that can be used as a
datasource?
Well I use GXT but like the smartgwt grids better so am looking at
this datasource issue.
It's worrysome:
Thread
http://forums.smartclient.com/showthread.php?t=3012
Bug report asking for RPC datasource
http://code.google.com/p/smartgwt/issues/detail?id=303
I see there is an api but it states:
Smart GWT supports declarative, XPath-based binding of visual
components to any server capable of returning XML or JSON responses
over HTTP, without the need for the 'Smart GWT server'.
Are there any examples using GWT-RPC (without the smart server)
> A fetch operation for example will pass the startRow, endRow and the
> applications server side code needs to return data as XML, JSON or GWT-RPC
> beans in response to this request.
Sanjiv what you said and what the docs say seem to be different. Can
we really use GWT-RPC to get a bean back that can be used as a
datasource?