Use smartgwt or not

[azure]

Hi all,
There are many gwt experienced developers in this group. I am starting
a project and am in a dilemma where to use smartgwt or not. There are
many advantages of using it (like filters/sorting in list grids etc).
However I think there will be many problems later on (for example
changing the design). Want to hear experienced people's voice.

[mariyan nenchev]

Hi,
i have used smart gwt for some projects, and i was not impressed from smart gwt, but it you decide smart gwt ee its good to use, but it is paid. So only smart gwt is painful to integrate with your server side (at least it was before 3 months). Also the widgets are a little slower than the widgets in pure gwt. I think it depends on what widgets you need, smart gwt has rich pallete of them and they are easy for use, but those datasources doesn't match me.

Regards.

[gcstang]

I've been using SmartGWT now with GWT for a few versions and it works
over all really well considering how relatively new it is.

I previously used gwtext and SmartGWT has a lot more capability.

If you're after a very professional look without having to accomplish
all the CSS on your own SmartGWT is a much better solution than others
I've found.

As with any software you will find some bugs but like I said for the
most part it works really well.

[Yozons Support on Gmail]

We're just now evaluating this ourselves, but we do like the look of their large variety of widgets, but it is big and takes time to really evaluate it all and there are myriad options from LGPL through proprietary EE.  No doubt, much depends on your app's needs.  Ours is more business-focused, so I think it's a good match, hence our eval will begin in earnest in January.  GWT's widgets just don't have much to show for grids tied to server data for ACID/CRUD operations, and the DataSource concept seems powerful should it pan out, which we expect it will from what we've read.  But any real-world experiences are most welcome.

I am a bit concerned about some items like "turn off Firebug" because it runs inordinately slow -- why their JS is overly impacted is not clear.  I have seen some odd painting issues in the showcase examples on FF3.5/Win7.  Do check out their forums though to see what others are saying and reporting as they may match what you intend to do.

I'm also not sure what it means to integrate SmartGWT with CKEditor yet, but we want to use the more powerful layout capabilities of CKEditor.

[Flemming Boller]

Hi

I think these javascript wrappers will have a hard time, with all new features coming from GWT.

Code split, UiBinder etc..  I am excited to see how they will integrate it.

I used ext-gwt, which had a pretty big startup-download-size. Unfotunally it was javascript coming from EXT, and not GWT, so codesplit was not going to help here.

Anybody have any thought about this?


/Flemming

--

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.

[Yozons Support on Gmail]

In the end, it's all JS to the client, so not sure what "wrapper" would really mean.  The downside may be they can't get the same optimizations that come with the Java-to-JS compiler as it increases in capability and can gen browser-specific versions.

But if you need to move now, GWT just doesn't have professional quality widgets for enterprise solutions.  It's almost like a step backwards from JSP when you see how much effort it takes to develop a table with sortable columns and have to transmit data (damn those DTOs) client-server when before it was all in the server. 

SmartGWT has some good solutions now, but you do have to wonder how long they'll command that lead.  Then again, if you like SmartGWT, you (or Google) could use those classes to eventually be all-GWT-based and no longer rely on SmartClient, or of course develop comparable widgets of their own from the ground up.  But how long will that take?  There's no promise of it coming is there?  And can you wait that long?  It's a conundrum for us right, now, that's for sure.

[Shawn Brown]

> I used ext-gwt, which had a pretty big startup-download-size. Unfotunally it
> was javascript coming from EXT, and not GWT, so codesplit was not going to
> help here.
>
> Anybody have any thought about this?

I don't understand your analysis.

I use ext-gwt and mvc and found it pretty easy to split code [I call
the dispatcher via History just add the controllers to the dispatcher
via the normal GWT split mechanism so they are only loaded if needed].

I am not a splitting guru so don't have any hard numbers on initial
loads, but yeah you can split the code. I really haven't gone through
the process iteratively (as GWT says is necessary) but already have
about a 50% reduction.

Why do you say you can't?

[András Csányi]

2009/12/17 azure <rock...@gmail.com>:

Unfortunately, I'm not a well experienced at gwt, yet. :)
Maybe you should take a look for ExtGwt (http://www.extjs.com/products/gxt/)

--
- -
-- Csanyi Andras -- http://sayusi.hu -- Sayusi Ando
-- "Bízzál Istenben és tartsd szárazon a puskaport!".-- Cromwell

[K.R.A.3]

I used ExtJS (gxt), at that time I also looked into smartGWT.
Both are excellent and by the same author.

But both require you to add another layer data for binding.
And commercial version is good for use ;-)

But now GWT widgets are as powerful as them. (I needed a data grid
with paging that time, so choose it)
Also I learned to use jQuery, (before I have no experience with JS),
now it seems implementing more things with jQuery with GWt wrapping
will be faster than developing whole thing in GWT (It's my humble
opinion anyway :) ).

So
1) understand what your project really want (lean projects are always
better to manage and maintain)
2) choose another library only if something you want is not in gwt
itself, and you don't know how to implement it (or you are in
urgency )
3) Or use direct JS (if you know it, I'm a newbie to Jquery but it's
power is amazing, NB: JS is not that hard)

Arun.K.R

[Shawn Brown]

> I used ExtJS (gxt), at that time I also looked into smartGWT.
> Both are excellent and by the same author.

No - no. smartGWT and gwt-ext (which is now defunct and was a wrapper
around ExtJS) are by the same author.

ExtJS and Ext-GWT (gxt) are different from smartGWT and gwt-ext.

[gail...@audemat.com]

I use GXT (Ext GWT from extJS) for several months with JBOSS 5.1, the
choice was made quickly between SmartGWT and GXT, GXT offers greater
customization and management of bindings are perfect with annontations
provided by GXTForms 0.2. There is no need to use Gilead or
Hibernate4gwt.

[keyboard_samurai]

I would agree on ext gwt .. Its faster and much better than smart gwt.

[Yozons Support on Gmail]

EXT is GPL while Smart is LGPL, and of course both offer commercial licenses.  LGPL can be used commercially, while GPL cannot, so that could be a consideration.  And of course commercial licenses are fine, unless your code itself is going to be open source.

[Martin Kraus]

On Dec 4th keyboard_samurai wrote :

"Hi, I am a newbie to GWT."

http://groups.google.com/group/google-web-toolkit/browse_thread/thread/2d66440f4c6a59f/449f9401e2d4ddd4

To the original poster : Make sure you do your own research too. There are a lot of "newbies" on this board that love to give advise. Don't blindly follow it.

We are using GWT alone but I know that Ext GWT is a real mess once you go beyond the samples and try to build a larger application.

On Sat, Dec 19, 2009 at 10:02 PM, keyboard_samurai <yog...@gmail.com> wrote:

I would agree on ext gwt .. Its faster and much better than smart gwt.

[azure]

I haven't yet found the answer if I can use it or not. I think it's
better to try using it and if I get any problem, I'll switch back to
GWT only.

On Dec 17, 2:15 pm, András Csányi <sayusi.a...@gmail.com> wrote:
> 2009/12/17azure<rockan...@gmail.com>:

>
> > Hi all,
> > There are many gwt experienced developers in this group. I am starting
> > a project and am in a dilemma where to use smartgwt or not. There are
> > many advantages of using it (like filters/sorting in list grids etc).
> > However I think there will be many problems later on (for example
> > changing the design). Want to hear experienced people's voice.
>
> Unfortunately, I'm not a well experienced at gwt, yet. :)
> Maybe you should take a look for ExtGwt (http://www.extjs.com/products/gxt/)
>
> --
> - -

> --  Csanyi Andras  --http://sayusi.hu-- Sayusi Ando

[ckendrick]

If "the choice was made quickly" it was probably an uninformed
choice. We don't have anyone complaining that there is "less
customization" so perhaps you could clarify that.

With SmartGWT Pro and EE, you can literally open up a visual tool and
create a fully functional CRUD interface to Hibernate by just picking
an existing Hibernate entity from a list. That's not offered in any
other GWT product, and it would be hard to argue that anything could
be simpler or faster than that..

On Dec 19, 7:00 am, "gaill...@audemat.com" <gaill...@audemat.com>
wrote:

[Yozons Support on Gmail]

With SmartGWT Pro and EE, you can literally open up a visual tool and
create a fully functional CRUD interface to Hibernate by just picking
an existing Hibernate entity from a list.  That's not offered in any
other GWT product, and it would be hard to argue that anything could
be simpler or faster than that..

Does the visual builder generate GWT code yet?  I agree that any quick eval is bound to fail, as just s'gwt itself is quite large and needs time to digest and play with. Then there's the integration of whatever you do choose with other toolkits you may need that just add to the time to eval.

[gail...@audemat.com]

You can't stat about 'uninformed choice', quick doesn't mean dirty
Enough of us to quickly test and evaluate a new framework and SmartGWT
does'nt meat our requirement.
We are moving from java to GWT with our own framework and it was
really more easy to do it with GXT.
We have no needs to have javascript knowledge when adapting /
modifiying core GXT, SmartGWT use a lot more javascript.
Even creating new widgets could be made easily with GWT, with SmartGWT
we must have good javascript skill to achieve the same task.
Same arguments about Hibernate and CRUD, we can't dig enough under the
hood with SmartGWT.
Another good point for GXT is the instanciation Windows builder Pro
support.
I don't want to say that SmartGWT is bad nor good, It does not meet
our criteria, point.

[Yozons Support on Gmail]

We'll investigate GXT as well.  I have to say that the licensing is more straightforward with GXT because the free/commercial tiers are not related to functionality in GXT versus SGWT.  But if you go want OSS in a commercial product (cheap?), you'd need to stick with LGPL of SGWT over the GPL of GXT.

But once you go commercial licensing, GXT looks more straightforward. 

How is GXT in terms of ease of data source integration with Java backends?

Not sure too that GXT is on version 2 while ExtJS is version 3.  Does the latest GXT include the latest of ExtJS under the hood?  I suppose I can check on their web forums for such details.

But as a GWT developer, it makes sense to look at both if you need more robust widgets.

[maku]

@Yozons Support

GXT is not a wrapper of ExtJs. So you can not compare the current GXT
version with any of the existing extJS versions.

They try to produce an almost identically looking end product (extjs
vs. GXT). But the way how this is achived is technically different
(and also from a functional point of view)

[Yozons Support on Gmail]

Thanks.  I just read about that, which means it should be even easier to debug and work with for us Java folks.  I like what I see in GXT so far, but admittedly very little.  I'm most interested in the DTO issue and if there are good ways to send HashMaps and the like to avoid creating so many of them, or whether the benefits of DTOs outweigh it with the stronger and simpler typing.

[John Armstrong]

There are a few strategies for DTO and GXT. Here are two

http://www.extjs.com/helpcenter/index.jsp?topic=/com.extjs.gxt.help/html/tutorials/beanmodel.html

I also did some using Commons::BeanUtils to autopopulate a DTO since I
use Cayenne on the backend and it was not serializing very cleanly.

So far I've found GXT to be pretty good to use although DataGrids have
been, and continue to be, somewhat of a nightmare for me but I'll find
my way through. GXT + Instantions WindowBuilder or GXT have made
things mostly great on my current project.

John

[Tom Schindl]

Just to mention that there are other Widget-Projects besides SmartGWT
and GXT. I'm working
on a library called QxWT [1] which works similar to SmartGWT by
wrapping an JavaScript-Library.

We are (yet) not at the point where GXT and SmartGWT are but we are
working hard on to get there. For me
and probably others the main interesting things the license all this
work is available which is in this case LGPL and EPL.

In the next few days we are going to release a small bugfix release
and the next release will hold support for
optimizing the "native" library code by leveraging the tooling support
we get from our upstream library
(scheduled for first 1-2 months 2010).

In alignment with QxWT release in Q1 there's going to be an release of
an MVP-Library which has highlevel support for Databinding
(to fairly any Domain-Technology you can think of by leveraging the
Eclipse-Databinding-Framework) and other well known
Eclipse Technologies like JFace-Viewers.

Tom

[1] http://tomsondev.bestsolution.at/2009/12/17/qxwt-1-0-0-0-released/

[Martin Kraus]

Great - Yozons is already a confused person incapable of making any decision by himself for *his* project and now you throw in another variable. I suspect this might throw him in a further endless loop. Oh, btw there's also gwt-mosaic and Vaadin. Make sure you evaluate those too and good luck trying to understand Vaadin's server side GWT rendering - not that I'm suggesting its good / bad.

Anyone who thinks GXT license / commercial model is straightforward is either uninformed or disillusioned. I'll just repeat what I've said earlier.

Ext / GXT / Ext GWT have and continue to have a very deceptive licensing scheme. It's licensed under GPL so you cannot use it commercially unless you are will to open source you client source code *and* your server side source code according to their very terms of use - which is very bizarre. Secondly even if you do end up buying a commercial license at $329 / license, you still do not have access to the bug fix releases.

The $329 / license really doesn't get you much. Version 2.0 final of ExtGWT was pretty much demoware with over 100 critical bugs. 4 - 6 months later several bugs have been fixed but license holders are not
entitled to the latest bug fix release of 2.0.3. You not only need a license but you need a support subscription to download the latest stable version.

See http://www.extjs.com/products/gxt/download.php
http://www.extjs.com/forum/showthread.php?p=393316#post393316

So the real cost of the license is $629 / license / year. In addition to this be prepared to pay frequent upgrade fees for no good reason. Users were required to buy upgrade licenses within less than a year of
the ExtGWT 1.0 release because they did an *internal* refactoring to clean up the code and not because new features were added to justify the 2.0 release. Ext GWT 2.1 is just out and they are already talking about Ext GWT 3.0 which is essentially clean up of their internal code to support the new GWT listener API's. What should customers pay an upgrade fee again for something like this?

A final word of caution - read the terms of their commercial license very carefully and run it by your legal. It's not your typical commercial license that you'd expect with a commercial product. They have some really severe restrictions that might even require you end user / customer to buy a commercial license of ExtGWT. If after reading their license you still think its straightforward, then good luck to you.

Martin

[Chris Ramsdale]

While the information on this thread has become a bit passionate, it is all good and relevant information. When building large scale GWT-based apps, developers typically sketch out the foundation and then immediately start looking for a good widget add-on. Threads like this can be extremely useful when deciding which route to go.

That said, I would suggest we take this conversation offline as it has become a bit personal. 

Thanks,

Chris

[Yozons Support on Gmail]

@Martin - Why would you want to attack me just because I'm evaluating toolkits?  I understand our application domain just fine, and we've built multiple applications in JSP technologies that are in our area of expertise and have been running a profitable software business for 10 years now.  Apparently you have an innate ability to review toolkits and understand all of their complexity, options and licensing terms quickly and easily.  You are very blessed indeed.  The fact that it takes me time to review them shouldn't mean I'm confused.  It is your attitude that has led me to reconsider sgwt because why buy a product from people who seem to think its users are not worthy? 

In our case, we expect to license both under AGPL and commercial, so GPL should be fine as all of our code would be similarly available.  When selling a commercial license of our product, we can do so assuming we've also purchased a commercial license of the library for our developers.  So it should not be a huge issue, but we will review it closely (our lawyers also must be clueless because they also take time to evaluate, and it's "just words").  As to GXT product capabilities, that is something we'll have to evaluate, fortunately not worrying about your concern for how long it takes us to do so.

@Tom, I'll take a look.  I've not heard of even qooxdoo before, but a quick check shows it's got a lot of stuff in there for a 1.0 release.

[John Armstrong]

@Martin
Regarding the below, can you point to the section that you read this
from @ http://www.extjs.com/store/extjs/license.php ?

Our reading of the license is that its a standard, straightforward,
developer seat + support model + 'no royalty/source release
requirement' which meshes with how most toolkits are licensed (Qt
etc).

Tx
J

[Yozons Support on Gmail]

I'm not sure about him, but the license itself does not seem to make it clear, but on their web site, they define a developer:

"Are on a per developer basis. Each person who directly or indirectly creates an application or user interface containing Ext components is considered a developer." ( http://www.extjs.com/products/license.php )

The "indirectly" part is odd because there are many apps where you can do some configuration that generates something that will appear on a web page, and if that web page uses Ext, it would imply that person is a developer, though only by an odd definition that is not used anywhere else that I've seen before.  Normally, a developer of a library would be the person who actually writes the code that uses the interface/library directly.  So, if a user creates a "new calendar" to share with others, and the calendar that an actual developer created uses Ext, it could be suggested by that clause that the user is somehow a developer (indirectly).  Same if it was a "greeting card" or "social network site" etc.  If they even define a link that appears then appears on a page with Ext widgets also on it, they'd be indirectly developers by that broad definition.

It's odd, because the license itself reads normally and contains no such overly broad definition of a developer.  And while you may be able to argue it, and even win in a court because the license itself does not say it and normally the license would rule as the reasonable definition of a developer would not include such users, but who wants to fight a legal battle where there are no winners besides lawyers and there are alternatives out there that would not put your product/company at risk?

We were told by Ext that our application would likely consider all of its users to be developers in their parlance because they are writing HTML code via CKEditor (which has no such broad strokes), and since the page that would show the HTML they developed might also contain at least 1 Ext widget of some sort, then they'd auto-magically because Ext developers.  Go figure, but it does preclude our use since we can't have every user of our system be considered a developer as we'd have no way of knowing.  Even sys-admins would configure items that would cause functionality to appear for users with a given permission, and that would be shown on a page containing Ext, so they'd now possibly be Ext developers, too.  While it sounds untenable to me, lawsuits are expensive even if you win, so why bother?  That's my 2 cents anyway since our lawyers said to pick an alternative rather than be have to worry about it.  Too bad since Ext is really pretty, and their all-GWT GXT could be nice if in fact it's not too buggy as was also suggested.

[Martin Kraus]

Yozons,
I apologize for the tone in my previous mail. I've been following the Ext / GXT shenanigans for a long time now and have raised numerous issues with them in the past as well on their licensing terms and numerous license violations. The issues were either ignored or deleted from their forum. When you stated they have a clearer license compared to products with standard  LGPL / EPL licenses it triggered a reaction from me without realizing that not all users are aware of the history and the way they operated. Even as of today they use the Creative Commons licensed silk icons without any attribution to the original author or pointer to the famfamfam site which is a blatant violation of the Creative Commons license.

They conveniently alter interpretations of their license to maximize how much they can extract from you and constantly alter their online license contents. A previous version of their license included the "indirectly" and "developer" interpretation in the license itself but I see they have now moved it to a different URL.

I'm glad you were able to determine that they would need all your end users to buy a license and thus ruled it out prior to getting further along in your project. I'm pretty certain that a majority of the current Ext GWT users will also be in violation of this indirectly developer end user license requirement and will be told so if they contact Ext licensing. They carefully never state such things publicly and work behind a veil of deceit but as mentioned in your previous mail, you were told so when you contacted them.

We only use GWT + incubator and I do not care which library you use. Just want people to be aware of what they are in for if they go with the Ext family of products.

Martin

[Yozons Support on Gmail]

No problem....  It's all good!

Our architect is trying to contact them directly now because he said it sounds so goofy he can't believe it's the case since the license itself has no such references and claims to be the authoritative document (so anything else on other pages would not supersede the license itself).  Interesting that they used to have that clause in the license.  Maybe they've fixed it finally, or maybe they are just playing games, but that seems overly odd.  Anyway, we're still looking and wish GWT incubator had better paging grids, which I understand they are working on, but when it will come out is hard to know.

I know that we found it took a lot of code to just make a paging table for one object (our group object), with a detail page to allow for updating and 'create like' type functionality.  When we looked at our model, we realized we'd be doing hundreds of these, and the pain seemed real. 

[ckendrick]

On Dec 26 2009, 3:51 am, "gaill...@audemat.com" <gaill...@audemat.com>
wrote:

> You can't stat about 'uninformed choice', quick doesn't mean dirty

> Even creating new widgets could be made easily with GWT, with SmartGWT
> we must have good javascript skill to achieve the same task

This statement is unequivocally false, as anyone can see by looking at
the many code samples being shared between users on the SmartGWT
forums - lots and lots of users creating sophisticated new widgets
entirely in Java without needing to know any JavaScript.

This is what I meant by a possibly uninformed decision.. most likely
this person ran across a forums thread talking about core framework
enhancements under consideration, caught a mention of JavaScript in
that context, and misconstrued it as applying to any kind of custom
widget.

In reality, you can subclass SmartGWT widgets, override methods, call
superclass methods, compose them, etc, all in Java. You can also
embed normal GWT widgets inside SmartGWT containers (people do this
for Google Maps, certain types of charts, etc).

[Jeff Schnitzer]

I must also give a big thumbs-down to GXT. The licensing is annoying
and misleading, yes - you must buy support to get a usable version,
making it rather bait-and-switch - but I'm willing to pay for good
tools so that's not what I'm complaining about. If it did what it was
supposed to, it would be well worth the $600.

I went quite a ways into implementation of a significant project with
GXT and eventually ripped it all out went with straight-up GWT. I
also have a fair amount of experience with ExtJS and jquery, so I'm
not by any means a novice.

The problems with GXT are basically summed up by:

* The layout system is entirely different from GWT's.
* All controls behave in highly non-intuitive ways.
* There is nearly *zero* documentation, not even decent javadocs.
* The examples, while pretty, do a very poor job of actually
explaining how to use the controls.
* The support team is very sluggish to respond to questions in forum
posts, even by paid users.
* If you want to deviate the appearance of a control even slightly,
you are screwed.
* The code download, even with code splitting, quickly becomes very
large (600k+). That's not including the css and img downloads.
* Code splitting is nearly useless because small pieces of framework
are tied to much larger pieces of framework (ie, an entirely new panel
& layout hierarchy).

If you want to experience a very simple test to verify this, here's a
frustrating exercise. Try to make a form that looks like this (two
fields on one line):

Name: [______________________]
Age: [___] Sex: [_dropdown__]

Sound simple? It's not.

My development pace doubled when I gave up and switched back to
straight-up GWT, and the results are a better user experience as well.
GXT was a waste of $600 and one month of my time.

Jeff

[Open eSignForms]

@Jeff,

If you went with "straight-up GWT" what did you do for all the various widgets that otherwise seem powerful and useful?

For example, what are your replacements for:

1) Paging grid/tables for showing lists of objects/data that users can then click on to view/edit in detail for typical CRUD operations?  I found PagingScrollTable to be a lot of work for a simple object (though I suppose I can just clone after I've built that one), and now it gives lots of warnings under GWT 2.0, and it sounds like they are re-architecting it now so no doubt the future holds something brighter, but perhaps entirely new and not really compatible.

2) Popup windows with title and close buttons in the "top area that you click on to drag around"?  I've used DialogBox, and it doesn't allow for even a simple close button to appear in the title bar.

3) Drag and drop items from one list to another list, such as when configuring objects that need to select multiple items from a defined list of pre-built items (like adding features or permissions or users from one list so it can be assigned to another object for use/reference).

Your approach surely has the most appeal, but wonder how much you had to write instead of getting a widget toolkit.  At the same time, I prefer not to use a distinct widget toolkit because it just seems to add another layer that perhaps will be slowly made less significant as GWT matures, and they all seem to have licensing issues.

I am checking with Ext now on their definition of "developer" to see if the complaints are still real or whether they are holdovers from earlier.  GPL is fine for our open source product, but we also expect to do commercial licensing, and then it gets complicated if we're somehow held to a standard that all users are developers and must have a Ext GWT license.  I am fine to pay for our developers who write our UI and use their library, but it gets murky with their "indirect developer" language that is not defined anywhere and the license itself doesn't even mention it.

As for SmartGWT, their LGPL product looks great and would pose no issue, but if you want their more advanced stuff for server-side code, you'd need to go commercial, which itself is not bad for us, but then it makes it impossible for us to offer our code as open source -- we want to do both open source for the open source community, but know that we have to offer commercial licenses to our business customers who demand that their systems be allowed to be proprietary.

[Shawn Brown]

> The problems with GXT are basically summed up by:

Not to dismiss your experience in anyway, but actually GXT to me seems
easier than Google's appengine. At least with GXT I can see the
source (well not of the current master branch but ...) to clarify what
something does. App-Engine is much murkier and if you want to talk
about lack of documentation (especially on bigtable).

OK, GXT and App-Engine are different products but as organizations go,
GXT and Google are not that far apart from my view with AppEngine
being the worst.

Anyway, if you can do it in GWT but not GXT then isn't that fine.
They are not mutually exclusive.

Here is what Darell (GXT lead dev) posted:

"GXT containers vs. GWT panels. GXT containers and layouts are great
when laying out your applications interface. They provide precise
control of your interface including area resizing. For these benefits,
there is a cost. Basically, you are controlling sizes and positions
via JavaScript, rather than natively by the browser. You should not
rule the use of GWT panels when building GXT applications. If you are
using many GXT HorizontalPanels and VerticalPanel's I would suggest
you consider the GWT version of the same widgets. As the GXT version
uses layouts which the GWT panels do not. But the best choise really
will depend on your particular use."

All the Best,

[Jeff Schnitzer]

I find the "type of complexity" of BigTable to be far easier to
handle. BigTable operates in a consistent manner and once you
understand the basic principles (watch *all* of the Google I/O video)
everything pretty much makes sense. The "type of complexity" of GXT
is endless little unrelated errata that ends up becoming death by a
million papercuts.

I did spend a lot of time working with the GXT grid for part of the
backend of my application, including the in-line editor. It took a
long time to get right, far more time than the feature was worth. I
don't know what the alternatives are for a heavily grid-oriented app,
fortunately mine wasn't.

I didn't manage to get the GWT and GXT panels to play nicely together.
It's not a comfortable thing to do - they behave completely
differently, so you not only have two separate and nearly isolated
learning curves to climb, but the grey intersection in between. Plus
you're talking about loading parallel frameworks of javascript to
render the UI, doubling the download.

Modal draggable dialogs - I don't use them. Drag and drop - I'll tell
you in a week. But if it's anything like my experience with forms,
layouts, animations, or charts, it'll be easier to build from scratch
than to climb the related GXT learning curve.

BTW, for some help with the appengine datastore, check out
http://code.google.com/p/objectify-appengine/. Even if you don't use
the library, the docs might help.

Jeff

[huherto]

I will be taking a look at QxWT. I still think there is a need for a
good widget library. I've been looking for alternatives. I used mygwt
but stop using it when they did the bait and switch lat year. I lost
several months of work and I'm still pissed. Also, I don't like that
they try to redo the GWT layouts and they changed JFace model just to
do the bait and switch.

Right, now I am using plain GWT widgets. But it is harder to make them
look good if you are not a designer.

[Open eSignForms]

The list of widget libraries is exhausting mostly because it seems so retro.

If the desktop windowing world were this fragmented for GUIs, life would have been harder.

And if developers had to worry about licensing issues to write GUIs, life would have been harder.  Widget libraries needs to be standardized and royalty free to win real mindshare.

Now we're back at that stage for Browser GUIs once again since plain HTML markup is falling by the wayside....cycling through trying to figure out what GUI libraries too choose, with no clear market leaders that are destined to be the winners.

So whatever you choose, it won't matter for long as the likelihood your choice will be that winner is low.

With those grumbles in place, QxWT, like SmartGWT, is nice in that it at least fits in the GWT world, but sadly they are not based on GWT's widgets and panels and so development is impeded if you want to be firmly in the Java/GWT camp and don't want to deal with changes, enhancements, etc. in Javascript should you want different behaviors.

So what is "best widget library" that is purely in the GWT world?  That is tricky indeed as I've found working through it all.  It's quite a task just to analyze them all and determine which are pure GWT and which are GWT wrappers around JS libraries or perhaps use entirely different schemes like Vaadin that I'm not sure what exactly they do yet.

We still have not heard back from Ext GWT on their commercial licensing terms, with the last word being that Ext reserves the right to define what a "developer" means, though we've never heard of a license that does not define such a basic term considering they license on a "per developer" basis.  It is unnerving that they cannot just be clear, suggesting that perhaps they'll just change their license terms in the future in unexpected ways that could mean you are stuck using an old version of their library or deal with the new terms whatever they may morph into.

[ckendrick]

Incorrect, SmartGWT allows both. Purchasing a license does not imply
that you *must* use the closed-source server-side portion. If you use
just the capabilities of SmartGWT LGPL, you can offer the LGPL
licensing terms to customers that prefer it, and you can purchase a
license from Isomorphic to obtain different terms for customers who do
not want the LGPL license.

Several of our customers do this for precisely this reason (needing an
all-OSS version of their product).

[Open eSignForms]

Hmm, but if you want to use the server side code, the primary reason for buying a license I'd guess because you have to be pretty crazy to be concerned about LGPL for a widget library since that's a good thing, then you'd likely include that code in your code base, so then you couldn't also offer your code as OSS as it would now include non-LGPL code.  That was my point.

[philippe]

To finish, my response is : no

I use GWT only and it's work very well.

On 28 déc 2009, 03:16, Chris Ramsdale <cramsd...@google.com> wrote:
> While the information on this thread has become a bit passionate, it is all
> good and relevant information. When building large scale GWT-based apps,
> developers typically sketch out the foundation and then immediately start
> looking for a good widget add-on. Threads like this can be extremely useful
> when deciding which route to go.
>
> That said, I would suggest we take this conversation offline as it has
> become a bit personal.
>
> Thanks,
> Chris
>

> On Sun, Dec 27, 2009 at 8:59 PM, Martin Kraus <martin.krau...@gmail.com>wrote:
>
>
>
> > Great - Yozons is already a confused person incapable of making any
> > decision by himself for *his* project and now you throw in another variable.
> > I suspect this might throw him in a further endless loop. Oh, btw there's
> > also gwt-mosaic and Vaadin. Make sure you evaluate those too and good luck
> > trying to understand Vaadin's server side GWT rendering - not that I'm
> > suggesting its good / bad.
>
> > Anyone who thinks GXT license / commercial model is straightforward is
> > either uninformed or disillusioned. I'll just repeat what I've said earlier.
>
> > Ext / GXT / Ext GWT have and continue to have a very deceptive licensing
> > scheme. It's licensed under GPL so you cannot use it commercially unless you
> > are will to open source you client source code *and* your server side source
> > code according to their very terms of use - which is very bizarre. Secondly
> > even if you do end up buying a commercial license at $329 / license, you
> > still do not have access to the bug fix releases.
>
> > The $329 / license really doesn't get you much. Version 2.0 final of ExtGWT
> > was pretty much demoware with over 100 critical bugs. 4 - 6 months later
> > several bugs have been fixed but license holders are not
> > entitled to the latest bug fix release of 2.0.3. You not only need a
> > license but you need a support subscription to download the latest stable
> > version.
>

> > Seehttp://www.extjs.com/products/gxt/download.php

> >http://www.extjs.com/forum/showthread.php?p=393316#post393316
>
> > So the real cost of the license is $629 / license / year. In addition to
> > this be prepared to pay frequent upgrade fees for no good reason. Users were
> > required to buy upgrade licenses within less than a year of
> > the ExtGWT 1.0 release because they did an *internal* refactoring to clean
> > up the code and not because new features were added to justify the 2.0
> > release. Ext GWT 2.1 is just out and they are already talking about Ext GWT
> > 3.0 which is essentially clean up of their internal code to support the new
> > GWT listener API's. What should customers pay an upgrade fee again for
> > something like this?
>
> > A final word of caution - read the terms of their commercial license very
> > carefully and run it by your legal. It's not your typical commercial license
> > that you'd expect with a commercial product. They have some really severe
> > restrictions that might even require you end user / customer to buy a
> > commercial license of ExtGWT. If after reading their license you still think
> > its straightforward, then good luck to you.
>
> > Martin
>

> > On Mon, Dec 28, 2009 at 6:08 AM, Tom Schindl <tomson...@gmail.com> wrote:
>
> >> Just to mention that there are other Widget-Projects besides SmartGWT
> >> and GXT. I'm working
> >> on a library called QxWT [1] which works similar to SmartGWT by
> >> wrapping an JavaScript-Library.
>
> >> We are (yet) not at the point where GXT and SmartGWT are but we are
> >> working hard on to get there. For me
> >> and probably others the main interesting things the license all this
> >> work is available which is in this case LGPL and EPL.
>
> >> In the next few days we are going to release a small bugfix release
> >> and the next release will hold support for
> >> optimizing the "native" library code by leveraging the tooling support
> >> we get from our upstream library
> >> (scheduled for first 1-2 months 2010).
>
> >> In alignment with QxWT release in Q1 there's going to be an release of
> >> an MVP-Library which has highlevel support for Databinding
> >> (to fairly any Domain-Technology you can think of by leveraging the
> >> Eclipse-Databinding-Framework) and other well known
> >> Eclipse Technologies like JFace-Viewers.
>
> >> Tom
>
> >> [1]http://tomsondev.bestsolution.at/2009/12/17/qxwt-1-0-0-0-released/
>

> >> On Sun, Dec 27, 2009 at 11:32 PM, John Armstrong <siber...@gmail.com>

> >> wrote:
> >> > There are a few strategies for DTO and GXT. Here are two
>

> >>http://www.extjs.com/helpcenter/index.jsp?topic=/com.extjs.gxt.help/h...

> >> >> google-web-tool...@googlegroups.com<google-web-toolkit%2Bunsubs cr...@googlegroups.com>

> >> .
> >> >> For more options, visit this group at
> >> >>http://groups.google.com/group/google-web-toolkit?hl=en.
>
> >> > --
>
> >> > 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%2Bunsubs cr...@googlegroups.com>

> >> .
> >> > For more options, visit this group at
> >>http://groups.google.com/group/google-web-toolkit?hl=en.
>
> >> --
>
> >> 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%2Bunsubs cr...@googlegroups.com>

> >> .
> >> For more options, visit this group at
> >>http://groups.google.com/group/google-web-toolkit?hl=en.
>
> >  --
> > 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%2Bunsubs cr...@googlegroups.com>

[ckendrick]

@yozons

Once again, incorrect. If you are using just the functionality of our
LGPL and you purchase a license from Isomorphic, you can offer your
customers either LGPL licensing or commercial licensing for SmartGWT.

The (several) companies choosing this option are not crazy. They are
selling into systems that move literally tens of billions of dollars a
year. The people running these systems are more than happy to cover a
~$700 per developer license fee to eliminate even the faintest
possibility of risk with respect to software licensing.

It would frankly be better if more developers realized the monetary
context in which they work and produce software. We see so many
examples of developers spending months of extra time to "save the
company money", they seem to forget they themselves are drawing a
paycheck which dwarfs the "savings" :) Let alone the value of on-time
delivery..

The vast differences between different projects is also why "use
SmartGWT or not" is not a yes or no question - any person who answers
this question without spelling out what they are trying to build is
providing zero data. In certain circumstances, Isomorphic will
happily tell prospects that SmartGWT is not the right solution for
them, but there are countless companies for which SmartGWT is the best
solution, and many for whom it is the *only* solution that can deliver
what they want in the relevant timeframe.

You have to compare your requirements and your delivery expectations
to the capabilities of the software. There are no shortcuts to doing
at least the first level of such analysis.

[Jeff Schnitzer]

Funny thing, someone just responded to one of my threads on the Ext
GWT forum and reminded me why I gave up on it: the crappy attitude of
the authors (summarized: "it's not a bug, it's supposed to act
broken"), even after I gave them code to fix their product.

http://www.extjs.com/forum/showthread.php?t=79790

Seems like this thread isn't complete without including this link.

Jeff