GWT Grid vs. SmartGWT grid

[Ken]

I'm exploring using GWT for future work and for a project I'm looking
at now I'm particularly interested in the Grid widget. The GWT Grid
just doesn't compare to that provided by SmartGWT, but I'm concerned
about using the SmartGWT libraries for several reasons:

1) It requires taking the whole library whole and it doesn't do things
in really the same way that GWT does in many cases.

2) I'm concerned about browser compatibility since it relies on JSNI
calls to the Smart Client library and not the Java->JavaScript
transformation provided by GWT.

3) I'm concerned that by using the SmartGWT library I will be
increasing the load time of the application since it will require
downloading the entire library again.

So what I would really like is a grid control that has a similar
feature set as that provided by SmartGWT, but doesn't come with all
the extra baggage.

Does such a widget exist? Is there at least a JavaScript grid that
can be used with GWT that doesn't come with all the baggage of
SmartGWT?

Am I wrong about the disadvantages to using SmartGWT? Is it a better
choice than I have been led to believe by my research?

Thank you.

[mariyan nenchev]

Try scroll paging table from gwt incubator, i think it was updated to gwt 2.0.

[Nathan Wells]

I would say you are correct on the disadvantages of SmartGwt. There
are those (most notably the author(s)) who I know disagree with me.
GWTers recognize the need for a more robust, data-backed table
solution, and it's currently in the works, targeted for 2.1. Our
company decided to go with SmartGwt for now, then migrate to a more
"Gwtfull" solution later.

[ckendrick]

And here are the authors to disagree :)

1) Yes, we make intentional departures from the GWT way, such as..

2) SmartGWT has better cross-browser consistency than GWT itself.
Why? Because GWT relies on native browser behavior and CSS for
layout, and this is where all the quirks come from. We do layout with
layout manager classes, more in the style of Java Swing. Yes, GWT has
layout managers, but what they're actually doing in many cases is
relying on the browser interpretation of sizes and layout rules.
Also, re-skinning your application with GWT is straight CSS, whereas
SmartGWT provides an abstraction that separates styling-as-such from
layout.

3) The library is cached, so you only increase the first-ever load
time. If you have a site where you are trying to display something as
fast as possible for a visitor who comes only once, this may matter.
If you're building an enterprise application and people use it
regularly, it doesn't matter, the extreme productivity benefits of the
SmartGWT grid (and other components) are much more important. On
broadband, SmartGWT applications come up faster than the launch time
of Word or Acrobat, so it's right in line with user expectations for
enterprise/desktop applications.

As far as the future, my take is that GWT cannot both retain an
ultralight footprint *and* provide the features of an enterprise
platform like SmartGWT - static code analysis just isn't a strong
enough approach to code trimming to enable this. I covered this in
depth here:

http://www.mail-archive.com/google-we...@googlegroups.com/msg34128.html

You've also got to consider the state of the art, of course. Will
your customers be doing a head-to-head comparison on functionality and
productivity between your competitor, who used SmartGWT, and your app,
which uses plain GWT grids? That's going to go very badly against
you.

[Open eSignForms]

And if you'd like to use GWT but don't care about GWT programming per se, check out Vaadin.com.  It's a servlet based solution that uses GWT for the client portion. They have tables/grids that work well with javabeans without DTOs or RPC programming (except for minor attribute-value passing via the UIDL if you build your own client widget).

[ckendrick]

Someone off-list took some of my comments the wrong way. I'd just
like to clarify, as long as GWT is targeting the ultralight use case
of an application that must be as fast as possible on first access, it
makes sense for GWT to rely on browser layout and just provide direct
CSS for skinning. It's not something I'm saying is a flaw in GWT or a
bad design decision, in fact, it's the same decision I would make in
addressing that use case.

The reason is simply that it takes a certain irreducible amount of
code to really build layouts that don't depend on native browser
behavior, and that's too much to deliver for the ultralight use case.
It's just different designs for different use cases.

I hope the core GWT widgets continue to focus on the ultralight use
case, because there's just nothing comparable, especially for mobile.

On Mar 12, 12:44 pm, ckendrick <charles.kendr...@gmail.com> wrote:
> And here are the authors to disagree :)
>
> 1) Yes, we make intentional departures from the GWT way, such as..
>

> 2)SmartGWThas better cross-browser consistency than GWT itself.

> Why?  Because GWT relies on native browser behavior and CSS for
> layout, and this is where all the quirks come from.  We do layout with
> layout manager classes, more in the style of Java Swing.  Yes, GWT has
> layout managers, but what they're actually doing in many cases is
> relying on the browser interpretation of sizes and layout rules.

> Also, re-skinning your application with GWT is straight CSS, whereasSmartGWTprovides an abstraction that separates styling-as-such from

> layout.
>
> 3) The library is cached, so you only increase the first-ever load
> time.  If you have a site where you are trying to display something as
> fast as possible for a visitor who comes only once, this may matter.
> If you're building an enterprise application and people use it

> regularly, it doesn't matter, the extreme productivity benefits of theSmartGWTgrid (and other components) are much more important.  On
> broadband,SmartGWTapplications come up faster than the launch time

> of Word or Acrobat, so it's right in line with user expectations for
> enterprise/desktop applications.
>
> As far as the future, my take is that GWT cannot both retain an
> ultralight footprint *and* provide the features of an enterprise

> platform likeSmartGWT- static code analysis just isn't a strong

> enough approach to code trimming to enable this.  I covered this in
> depth here:
>

>    http://www.mail-archive.com/google-we...@googlegroups.com/msg34...

>
> You've also got to consider the state of the art, of course.  Will
> your customers be doing a head-to-head comparison on functionality and

> productivity between your competitor, who usedSmartGWT, and your app,

> which uses plain GWT grids?  That's going to go very badly against
> you.
>
> On Mar 12, 1:58 am, Nathan Wells <nwwe...@gmail.com> wrote:
>

> > I would say you are correct on the disadvantages ofSmartGwt. There

> > are those (most notably the author(s)) who I know disagree with me.
> > GWTers recognize the need for a more robust, data-backed table
> > solution, and it's currently in the works, targeted for 2.1. Our

> > company decided to go withSmartGwtfor now, then migrate to a more

[Fabio Kaminski]

the right question is.. what do you need?
you need simplicity or a lots of built-in features?
do you need stand up for millions of users.. or do you control the app users.. and could even train them if you like?

in my case i need simplicity and support a lot of users.. low latency.. etc..
and my fear is that third part library could get broken by futures versions of GWT
that can change the way it does thing in its roots.. so a lot of rewrites for these fellows

Smart its a cool project... but you always need to think if you fill you project with a bunch of features your users may get lost..
and may repeats "Vista" mistakes..

you need to balance when to make developers life easier or user life easier... 

--
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.

[gengstrand]

The Grid class from GWT is a layout handler and not a GUI widget at
all. I suspect that you are looking for some kind of data table GUI
widget control.

The ListGrid control from the SmartGWT project has all the nice bells
and whistles but the download can be less than snappy. I don't think
that it is too bad though. Check out http://myjsp.dynamicalsoftware.com/kato/
which is a demo containing many SmartGWT widgets including the
ListGrid. I wouldn't say that the download was too terrible.

SmartGWT works fine on many popular browser/OS combinations. The only
place I found of relevance where SmartGWT doesn't work and GWT does is
the iPhone.

The Grid control from the GXT project might be a nice compromise
between eye candy and download time but do check out their license
first.

@Mariyan has already recommended the PagingScrollTable from the
incubator project.

Also, you might be interested in this presentation ( see
http://www.dynamicalsoftware.com/gwt ) on GWT and some popular yet
mature 3rd party libraries. The slide deck covers the very topic that
you are asking about.

I hope this helps.