Who is using smartgwt?

[Chris]

So there is a new version:
http://www.jroller.com/sjivan/entry/smartgwt_1_2_released

So far I have just been using standard gwt and gwt Incubator.
Smartgwt looks like it has some great widgets and layouts.

I would be curious to here from anyone who is using it. Either way
I am going to give it a try. I like the fact that it is lgpl.

-chris

[Daniel Jue]

I am using it.  Once I got the extra layers of code implemented for the RPC Datasource (mostly from off thier forum), It's been pretty painless.  I came from GXT 2 because I was having some rendering problems and wanted to try something else.  SmartGWT _is_ painfully slow in hosted mode, but the widgets are very nice and full featured.  My favorite so far is the combo box where the elements have sortable columns, etc like a grid. 

[Chris]

It is slow in hosted? But how is it deployed in
a regular browser?

[Daniel Jue]

It is slow in hosted, although I'm on SmartGWT 1.1/GWT 1.7 at the moment.  Deployed it is better, but its' still chunky.  However it's full of features that I don't have the time or desire to recreate, so it works for me.  It's definitely not a lightweight, but it's not bad.  There's just a lot going on behind the scenes.  The full "sc" directory that gets put in the war is like 18.7 MB (19,630,389 bytes) worth of Js files.  I'm guessing 98% of those won't be touched/loaded.  I like SmartGWT so far and have recommended it to some people.

[Sanjiv Jivan]

Hi Daniel,

Please try upgrading to SmartGWT 1.2. Hosted mode should perform better.  You're right that most of the resources from a compile output are not used and so if you're benchmarking, best to actually see what's transferred over the wire rather than the size of the output directory on the server. The default com.smartgwt.SmartGwt module bundles all the readable source versions that have a lot of documentation, the obfuscated / minified ones, various tools like the Developer Console and a lot of other resources that are pretty much never used in deployment. I'll look into creating a module that outputs the minimal resources which will save some MB of disk space on the server.

As for runtime performance, you can have a look at the SmartGWT showcase which is comparable is size to a real world application having ~260 samples and includes most widget types. If you're not using Calendar, or TileGrid etc you can exclude these resources.

Sanjiv

[shay]

I Highly recommend SmartGWT, been using it for months now.

Sanjiv and the smart client team have done a great job. Kudos!

The architecture is clever and robust , way better then Ext.

Shay


On Aug 13, 9:03 pm, Sanjiv Jivan <sanjiv.ji...@gmail.com> wrote:
> Hi Daniel,Please try upgrading to SmartGWT 1.2. Hosted mode should perform

> better.  You're right that most of the resources from a compile output are
> not used and so if you're benchmarking, best to actually see what's
> transferred over the wire rather than the size of the output directory on
> the server. The default com.smartgwt.SmartGwt module bundles all the
> readable source versions that have a lot of documentation, the obfuscated /
> minified ones, various tools like the Developer Console and a lot of other
> resources that are pretty much never used in deployment. I'll look into
> creating a module that outputs the minimal resources which will save some MB
> of disk space on the server.
>
> As for runtime performance, you can have a look at the SmartGWT showcase
> which is comparable is size to a real world application having ~260 samples
> and includes most widget types. If you're not using Calendar, or TileGrid
> etc you can exclude these resources.
>
> Sanjiv
>

> On Thu, Aug 13, 2009 at 8:18 PM, Daniel Jue <teamp...@gmail.com> wrote:
> > It is slow in hosted, although I'm on SmartGWT 1.1/GWT 1.7 at the moment.
> > Deployed it is better, but its' still chunky.  However it's full of features
> > that I don't have the time or desire to recreate, so it works for me.  It's
> > definitely not a lightweight, but it's not bad.  There's just a lot going on
> > behind the scenes.  The full "sc" directory that gets put in the war is like
> > 18.7 MB (19,630,389 bytes) worth of Js files.  I'm guessing 98% of those
> > won't be touched/loaded.  I like SmartGWT so far and have recommended it to
> > some people.
>

[Daniel Jue]

Now, how about an MVP/Eventbus version of SmartGWT showcase?
=)

[Nathan Wells]

I would like to add a dissenting voice... As always, it's a matter of
trade-offs

Benefits:
1) Pretty, usable, full-featured widgets, with very small up-front dev
time.
2) Very responsive dev team (you're awesome Sanjiv)

Problems:
1) Incompatible or redundant APIs. Specifically, I'm thinking of
a. Redundant event system
b. Datasource
c. TreeGrid has approximately 160 methods.
2) Lack of GWT Compiler optimization
3) no use of ImageBundle
4) b/c of 2 & 3, very request intensive.
5) No intuitive way to customize styling

Right now, our team is using TreeGrid, because no comparable widget
exists, but I've been thinking we should take a look at customizing
the gwt-incubator tree grid.

[Sanjiv Jivan]

Hi Nathan,

Thanks for mentioning me under the "Benefits" section :)

As always, constructive criticism is welcome and helps improve the product. For example it was primarily due to user feedback the the new Enterprise skin was quickly delivered by SmartClient.

I'd like to respond to some of your concerns 

"1) Incompatible or redundant APIs. Specifically, I'm thinking of
a. Redundant event system
b. Datasource
c. TreeGrid has approximately 160 methods."

Can you clarify b) ? DataSources are a very powerful concept and most SmartGWT components support being bound to a DataSource.  As you probably know, this means that any changes made to the data in the widget - whether it be cell edits, or tree node reordering, or drag and drop across separate databound components are automatically reflected in the underlying local data, or propagated to the server for you to act upon the change operation. Thanks to datasources and their inbuilt capabilities, this can save the application developer from writing a whole lot of code to manage these operations per-widget per-screen.

The TreeGrid does have a lot of methods. An advanced tree is a sophisticated component and the philosophy of SmartGWT is that pretty much any feature or customization that the user may require is supported out of the box and can be settable via a simple property. As you noted, the SmartGWT Tree component is very powerful. Here's a link to the TreeGrid javadocs for the benefit of the users :

http://www.smartclient.com/smartgwt/javadoc/com/smartgwt/client/widgets/tree/TreeGrid.html

If you have a closer look, you'll see that there are listeners for numerous events and properties like canAcceptDroppedRecords that turn on local or DataBound drag & drop. It would be interesting to see what the API for the incubator Tree looks like when it supports all these features - and I say this in a positive way with the best of intentions.

"2) Lack of GWT Compiler optimization"

The SmartGWT API's are optimized by the GWT compiler such that only those methods used are part of the compiled output. You're right that the underlying SmartClient JS files are not going to be aggressive pruned by the GWT compiler however there are other benefits to this. For example the core SmartClient JS files can be have an expires header set to the future to enable caching and even deployed on a CDN. So when the users application code changes, and a new set of GWT md5 based files are generated, the only file that gets refreshed when a user accesses the site is the smaller GWT compiled files, and not the core "kernel" SmartClient JS files as they are cached. 

As you say its about trade-offs but what is important to keep in mind is not dismissing SmartGWT due to this, but rather focus on the end result once your real world application is build. The SmartGWT showcase is a good example of this which comparable, if not larger than many real world applications. A good apples to apples comparison would be to compare a GWT based application with as many screens and similar featureset. With this in place it would be a good basis for total file size comparison. The GWT version will no doubt be smaller. If every single KB is important to you, that might be a factor but you have to ask the question about how much more application code did you have write to build your enterprise application? 

I can state with confidence that if you are building a data intensive enterprise application, SmartGWT can cut down application code by 50% or more compared to home grown solutions and this is due to the combination of a lot of configuration properties being supported out of the box, and the strong data-binding capabilities. In my blog I have a complete example of an end to end CRUD sample that supports filtering, sorting, inline edits and more with as little as 20 lines of client side SmartGWT code and a 20 odd line server descriptor file. Moreover no code generation is involved. No other AJAX based technology that I know of can deliver so much with so little coding. On the other hand if you're looking to simply include a couple of widgets in your page that interact with client side data only, SmartGWT is probably overkill.

"3) no use of ImageBundle"

100% agree with this. This is on the roadmap and hopefully will make it for the next major release without code changes for the end user.

"5) No intuitive way to customize styling"

SmartGWT, by virtue of SmartClient does have a very powerful skinning system. A key advantage is that users can customize styling using a Java API in cases that make sense, while using CSS in others. If you look at SmartClient's different skins you'll notice that essentially everything can change, including the use of completely different widgets in different places (eg switching ListGrid headers between pure CSS, 1 image, or triple image representations). As another example, have a look at the tabs in the TreeFrog skin. Perhaps users can take the initiative and create a lightweight theme for SmartGWT similar to GWT's theme that is simplified and involved way less media. It certainly is possible.

I'll be happy to try to answer any other questions / concerns here, or if you have specific questions or suggestions for improvement you can post on the SmartGWT forums as well.

Thanks,

Sanjiv

[Chris]

Ok, I have started with smartgwt, like the look and feel. I am
looking into using gwt-rpc as a datasource.

There is this sticky thread on the smartclient forum:
http://forums.smartclient.com/showthread.php?t=4814

Is this the info you used to figure out how to make a gwt rpc
datasource?

Maybe I should take this ove to the smartclient forum. I am posting
this here
in case someone else is looking for the same info.

-chris

On Aug 13, 4:00 pm, Daniel Jue <teamp...@gmail.com> wrote:

> I am using it.  Once I got the extra layers of code implemented for the RPC
> Datasource (mostly from off thier forum), It's been pretty painless.  I came
> from GXT 2 because I was having some rendering problems and wanted to try
> something else.  SmartGWT _is_ painfully slow in hosted mode, but the
> widgets are very nice and full featured.  My favorite so far is the combo
> box where the elements have sortable columns, etc like a grid.
>

[Malte]

Hi all,

For a few month a had the same problems: GXT or SmartGWT and I choose
GXT. Ok now why?
The main reason was the speed. Cause the extjs team recreated the
whole library in pure GWT code, what make it amazing fast. But that
was for a few month. Currently SmartGWT has nearly the same
performance, but I think the main reason is that the browsers are now
much faster (I am using Firefox 3.5). Currently I am thinking again,
but I am not a fan of wrapper libraries. I know there is a lot of work
in creating SmartGWT, but there are some disadvantages:
1. When the GWT compiler gets better and can optimize more and more,
the SmartGWT library will not get any of these advantages.
2. Loading time! Sure after the first load the load time will be equal
to pure GWT application. But the first time is the time where the user
decides to stay on this page or not... in most cases there is no
second chance.
3. Upcoming features like runAsync bring no advantages.

Greetz
Malte

[Daniel Jue]

Yep, that is the link I used.  I like generics, so I went with the version on page 7 I believe.  Modified it, posted mods on page 14.
http://forums.smartclient.com/showthread.php?t=4814&page=14

It's non trivial to do with with generics, but I have lots of objects to make datasources for.  Perhaps I'll turn it into more of a bean model in the future.  However it doesn't have to be hard.  The code you want to take advantage of is in the SmartGWT-Extentions lib, which I link to.                                                                              

The GWT RPC Datasource seem so be the key to making a real app in Smartgwt.

As far as the bridges, at some point I had to write similar code when I was using GXT.  I believe my dtos in GXT were just a wrapper around a map<string,serializable> etc, to work as a bean model in their widgets, etc.

[ckendrick]

Hi Malte,

As far as once-ever load time, if you're building an enterprise
application with several screens and lots of productivity features,
you're going to be using substantially all of SmartClient - if it was
written in Java, the impact of the GWT compiler's static analysis
would be negligible. If you're building something more trivial, just
a few components and basic interactions, it doesn't really matter what
you use, anything will do.

On performance, SmartGWT is already more than fast enough in terms of
UI interactions. It doesn't matter whether a menu appears in 40
milliseconds or 60, humans literally cannot perceive that difference.
So, while I would argue that future changes to the GWT compiler are
not going to beat SmartClient's hand-coded JavaScript, it doesn't
matter anyway, it makes no perceptible difference.

What does matter for real world performance is a feature like Adaptive
Filtering, which radically cuts down on trips to the server, improving
responsiveness and scalability:

http://www.smartclient.com/smartgwt/showcase/#grid_adaptive_filter_featured_category

SmartGWT has half a dozen other features that make similar, real world
impacts on performance. This is what actually matters in a deployed
application.

[Aladdin]

The only difference that the GWT compiler will not include the JS in
the downloadable files. So the optimization is not only for the speed
it's also for the size of the application.

If you wanna developed huge project SmartGWT is the way to go, but
remember that your minimum app is going to be 1mb in size because of
the SmartGWT core files.

On Aug 14, 10:34 pm, ckendrick <charles.kendr...@gmail.com> wrote:
> Hi Malte,
>
> As far as once-ever load time, if you're building an enterprise
> application with several screens and lots of productivity features,
> you're going to be using substantially all of SmartClient - if it was
> written in Java, the impact of the GWT compiler's static analysis
> would be negligible.  If you're building something more trivial, just
> a few components and basic interactions, it doesn't really matter what
> you use, anything will do.
>
> On performance, SmartGWT is already more than fast enough in terms of
> UI interactions.  It doesn't matter whether a menu appears in 40
> milliseconds or 60, humans literally cannot perceive that difference.
> So, while I would argue that future changes to the GWT compiler are
> not going to beat SmartClient's hand-coded JavaScript, it doesn't
> matter anyway, it makes no perceptible difference.
>
> What does matter for real world performance is a feature like Adaptive
> Filtering, which radically cuts down on trips to the server, improving
> responsiveness and scalability:
>

>    http://www.smartclient.com/smartgwt/showcase/#grid_adaptive_filter_fe...

[pmonestie]

I was using smartGwt for a while but then reverted to Gxt. The main
reason is that smartgwt had issue when I was combining smartgwt
widgets and normal Gwt widgets (things that I had built and wanted to
reuse).
Things would not layout properly or would not resize... Gxt did not
have the problem. I also think that Gxt is better designed in general
as it is written in Java, where often you can tell that smartgwt is a
wrapper. It seemed to me that there was very little abstraction and
inheritance, making it difficult to look at a classes with lots of
methods.
Though the Data Source concept of smart is good when you have DB
intensive apps.

[Tercio Filho]

Hi Chris,

I used SmartGWT since 1.0.

It has a great Widget library and a great integration with data
providers(Database, XML, JSON, and so on).
People in forum are very helpful. Isomorphic is a little, raw, but
it's fine, some times we ask dumb questions.. :-P. Sanjiv is very
committed, and prompt for help.
Other advantage is that it's released in LGPL which let you use it in
a commercial application without paying.

But, everything has a but, my application is VERY custom, it's like a
generic CRUD. And I need to made a lot of custom UI, based on it's
widgets, and as SmartGWT is a wrapper for SmartClient JS I cannot
change it's behavior directly in Java, only trivial things are
accessible.

I re-created my application on GXT 2.0.1 and it's sensational! It's
coded 100% in Java(Except for JSNI...) and you can change widgets
behavior just extending a class, for me, it's really important. And
debug is FAR easier, as you can debug widget's, Stores and not have a
JSNI method that you don't know what it does and if it has a bug or
not.

GXT is a GPL, which means that you cannot use it in a commercial
application without releasing your source code, or you can buy a
license(~ USD 330,00 without support, USD 579 with support). SmartGWT
license starts at USD 745,00 without support, support price is only by
request.

Another bad point in GXT is it's Widget library, SmartGWT is far
bigger and have complex widgets, GXT has only the basic++.. :-P

I prefer to pay USD 500 and have access to their SNV instead of
waiting to Sanjiv commit a new build of SC in the SmartGWT SVN. You
know, sometimes you really need "instant" access to corrections.
SmartGWT or SmartClient don't have this option, the SVN has
confidential things...

I'm not defending one or another, just exposing my point of view.

Both are fine, just look for these points that are more important to
you.

Regards,

Tercio

[Tercio Filho]

Just to point another SmartGWT issue, the DataSource concept is
completely different from GXT Store. And IMHO GXT is far ahead from
SmartGWT.

The SmartGWT DataSource, just provides the data, like a Proxy, it
doesn't cache it, like Store in GXT, that said, if you have 2
components bounded with this DataSource, you will have 2 calls to the
server. This is really unacceptable. You don't have a central place to
get/set data. You have to go to the Grid and get/set records.

One thing that cannot be negated is that SmartGWT Filtering and
Sorting is very very good.

GXT is well-founded, it's classes, concepts. Will not have problems to
grow.

Regards,

Tercio

[Daniel Jue]

FWIW, my compiled js code for just my SmartGWT app is around 300k, and it's based off of the SmartGWT Showcase.  I think I also have about 3MB worth of icons, but that's besides the point. =)

[ckendrick]

@Tercio On GXT Store vs SmartGWT DataSource, the SmartGWT architecture
is the correct one here and is a superset of GXT's.

When you have a large dataset you frequently have multiple components
working with independent, smaller slices of that large dataset, each
with different criteria and sort order, and each independently
managing paging and a partial cache. In SmartGWT each of these is
called a ResultSet. A ResultSet can be shared between components, and
some components automatically re-use ResultSets in an LRU fashion when
the component needs a subset of a dataset that has already bean
loaded. All ResultSets observe the DataSource and automatically
update their caches when a change occurs that affects their slice of
the dataset.

http://www.smartclient.com/smartgwt/javadoc/com/smartgwt/client/data/ResultSet.html

When you are working with smaller datasets, you can simply tell a
DataSource to go into clientOnly mode and it behaves like GXT's simple
"Store":

http://www.smartclient.com/smartgwt/javadoc/com/smartgwt/client/data/DataSource.html#setClientOnly%28java.lang.Boolean%29

We believe that GXT will eventually have to revise their architecture
to match SmartGWT, most likely breaking backwards compatibility at
that time. Take a close look and think about the use cases
surrounding large datasets and I think you'll reverse your opinion on
which architecture is the correct one, and is more advanced.

Bear in mind also: we offer SmartGWT under the LGPL for free, and this
free product has a lot more features that what you have to pay for
with GXT (unless you can accept GPL - very rare). For the $745 price
tag of SmartGWT Pro, you're getting a huge amount of Java-based server
functionality and a visual design tool (Visual Builder). It's simply
not valid to compare price tag of SmartGWT Pro to GXT; it's more
accurate to compare the free SmartGWT to the paid GXT, where SmartGWT
Pro is another class of product entirely.

@pmonestie We just addressed issues with GWT interop last week.

[Tercio Filho]

@ckendrick

The way SmartGWT works, every component caches it's data,
independently if another component is using the same data.

If you need some resultset, you need to access a component that cached
this data, ie. Grid. When you have multiples components bounded to the
same store you will have several server trips.

The way that GXT has been developed, they let you implement what is
needed for you, for example the Store need an Loader, that need an
Reader. With that architecture, you can implement it the way you want.
By the way, SmartGWT let you do this in a different matter,
overloading the processRequest, and processResponse, which in my point
of view is "simpler", but very effective.

See, both have pros and cons.

For sure, with SmartGWT you have much more code than with GXT
(Especially in server side).

For me, GXT has more flexibilities, as it's coded in pure Java, so I
can extend a class or something and change it's functionality.

I think that Chris has a lot of opinions about both systems, and will
be happy with either.

Regards.,

Tercio

On Aug 15, 6:36 pm, ckendrick <charles.kendr...@gmail.com> wrote:
> @Tercio On GXT Store vs SmartGWT DataSource, the SmartGWT architecture
> is the correct one here and is a superset of GXT's.
>
> When you have a large dataset you frequently have multiple components
> working with independent, smaller slices of that large dataset, each
> with different criteria and sort order, and each independently
> managing paging and a partial cache.  In SmartGWT each of these is
> called a ResultSet.  A ResultSet can be shared between components, and
> some components automatically re-use ResultSets in an LRU fashion when
> the component needs a subset of a dataset that has already bean
> loaded.  All ResultSets observe the DataSource and automatically
> update their caches when a change occurs that affects their slice of
> the dataset.
>

> http://www.smartclient.com/smartgwt/javadoc/com/smartgwt/client/data/...

>
> When you are working with smaller datasets, you can simply tell a
> DataSource to go into clientOnly mode and it behaves like GXT's simple
> "Store":
>

> http://www.smartclient.com/smartgwt/javadoc/com/smartgwt/client/data/...

[ckendrick]

@tercio You're still missing the key point. Let's try again:

It is absolutely 100% required in an enterprise application that
different components have different caches, potentially partially
overlapping, on the same dataset. A simple example is an interface
for dragging and drop users between two different groups where both
groups are very large and cannot be loaded in their entirety. In
SmartGWT this is a single DataSource, and two ResultSets on that
DataSource. Each ResultSet loads the first batch of members of each
group and is capable of paging in the rest as needed.

It is not a drawback that SmartGWT has separate caches per component.
It's the correct architecture, and is a necessity where large datasets
are involved.

As I mentioned previously, if the datasets involved are small, you can
use a clientOnly DataSource, and then there is only one central
cache. This is the trivial case, which is the only one GXT currently
handles.

In either case (clientOnly or not) APIs exist in SmartGWT that allow
fetching data directly from the DataSource without the use of a
component - you can both call methods like DataSource.fetchData(), or
you can directly create a ResultSet.

Once you've absorbed all this, I think you will agree, the SmartGWT
architecture is the correct one and the GXT architecture has
limitations.

Another mistatements: in SmartGWT you can extend the built-in widgets
and other classes and override methods. People do this all the time.

I have no idea why you think more code would be involved with SmartGWT
for server integration. People constantly say the reverse. There may
other misconceptions there that I could address, if you were to
explain why you think this is. Regardless, most professional,
enterprise developers can easily justify a purchase of SmartGWT Pro,
where the amount of SmartGWT-specific server code involved is
literally zero for many cases, and very small for the others.

[Tercio Filho]

On Aug 16, 7:39 pm, ckendrick <charles.kendr...@gmail.com> wrote:
> @tercio You're still missing the key point.  Let's try again:
>
> It is absolutely 100% required in an enterprise application that
> different components have different caches, potentially partially
> overlapping, on the same dataset.  A simple example is an interface
> for dragging and drop users between two different groups where both
> groups are very large and cannot be loaded in their entirety.  In
> SmartGWT this is a single DataSource, and two ResultSets on that
> DataSource.  Each ResultSet loads the first batch of members of each
> group and is capable of paging in the rest as needed.

As I said in my first post, we cannot compare SmartGWT DataSource with
the GXT Store, as they do different jobs, DataSource in SmartGWT is
just a Proxy, or in GXT the Loader and the Reader, that's the function
of the DataSource in SmartGWT, retrieve data when somebody need it.

>
> It is not a drawback that SmartGWT has separate caches per component.
> It's the correct architecture, and is a necessity where large datasets
> are involved.

I disagree that this is the right way to do things, I cannot accept
the fact that the widget manages it's data cache, widget is just a
widget, it has nothing to do with model data.

> As I mentioned previously, if the datasets involved are small, you can
> use a clientOnly DataSource, and then there is only one central
> cache.  This is the trivial case, which is the only one GXT currently
> handles.
>
> In either case (clientOnly or not) APIs exist in SmartGWT that allow
> fetching data directly from the DataSource without the use of a
> component - you can both call methods like DataSource.fetchData(), or
> you can directly create a ResultSet.

Coupling problem, why should I, a data manipulator, must care about
this?? I just need the data, that's why the GXT Store is better, you
have a store, a reader and a loader, layers of decoupling. One taking
care of another...

> Once you've absorbed all this, I think you will agree, the SmartGWT
> architecture is the correct one and the GXT architecture has
> limitations.
>
> Another mistatements: in SmartGWT you can extend the built-in widgets
> and other classes and override methods.  People do this all the time.

And you CAN'T change a widget behavior in SmartGWT, at least in
Java... you have a lot of methods that you can override, but it's just
property setter/getters for JS code, it's internal behavior is inside
JS code, so, no go. Even extend is uncertain.

> I have no idea why you think more code would be involved with SmartGWT
> for server integration.  People constantly say the reverse.  There may
> other misconceptions there that I could address, if you were to
> explain why you think this is.  

About the server code I mentioned, i didn't made myself clear, I'd
like to say exactly this(Less work for the developer). I wish I have a
better english.. :-P

> Regardless, most professional,
> enterprise developers can easily justify a purchase of SmartGWT Pro,
> where the amount of SmartGWT-specific server code involved is
> literally zero for many cases, and very small for the others.

Sure, a professional can justify, I didn't said the opposite.

Anyways, let's see what Chris think about all this, it's all about
point of view.

Regards,

Tercio

[ckendrick]

Sorry Tercio, I can't spend more time helping you understand the
architecture here, but suffice it to say, try building the example I
suggested (drag and drop between two very large user groups that can't
be loaded in advance) and you'll see why widget-specific caches are an
absolute necessity.

Each widget is looking at a particular subset of the data available
from the model, managed by a ResultSet which serves as a projection of
the model data needed for that particular view. You will find the
same approach in every system that handles large datasets, from Swing
to JDBC and everywhere else - it's really worth your time to
investigate this and understand it.

I'd also appreciate it if you could stop asserting things that are
just clearly false. SmartGWT has many, many Java override points that
allow you to deeply customize behavior - not "getters/setters" but
fundamentals like which cells are editable (listGrid.canEditCell()),
how data is transmitted (various DataSource APIs), many aspects of how
HTML is generated (getInnerHTML, cellFormatters, many others), and of
course, countless events. I think you have some misconceptions which
date back to right after 1.0 was released - not every override point
from SmartClient is yet available in SmartGWT, but we are getting
closer to that all the time.

[Tercio Filho]

ckendrick, is canEditCell() a behavior or a feature?

protected native boolean canEditCell(int rowNum, int colNum) /*-{
var self =
this.@com.smartgwt.client.widgets.BaseWidget::getOrCreateJsObj()();
return self._canEditCell(rowNum, colNum);
}-*/;

Damn, it's behavior is inside JS code.

I'm not saying that a widget cannot have a cache, I'm saying it just
can't manage it, well, it can, but shouldn't...

Regards,

Tercio.

[ckendrick]

Tercio, might be a language gap problem here, but canEditCell() is an
override point that a Java developer can override purely in Java. The
default behavior of canEditCell is well documented, and a developer
should always look *first* at the documentation, not the
implementation, in understanding what a method does. Otherwise it is
easy to make apparent "progress" when in fact you are relying on
unsupported functionality.

Again, I highly recommend working through the details of drag in drop
between large groups of users so you can discover why it is necessary,
when data volume is high, to creating caches on behalf of individual
widgets in the view.

On Aug 17, 10:31 am, Tercio Filho <terciofi...@gmail.com> wrote:
> ckendrick, is canEditCell() a behavior or a feature?
>
>     protected native boolean canEditCell(int rowNum, int colNum) /*-{
>         var self =

> th...@com.smartgwt.client.widgets.BaseWidget::getOrCreateJsObj()();

[Tercio Filho]

ckendrick, the main point is that *if* a functionality isn't
supported, you can't implement it just overriding some methods, you
need to go deeper in JS code.

Sorry, but I cannot accept that a widget caches it's data. IMO it
should have a composite with an well defined object that manages that
cache, not the widget itself. I understand that with huge data volume
you need different cache, but the widget should not manage it.

If you have a well defined interface for an object that manages data,
you don't need to know a widgets specifics to know how to access it's
data.

Regards,

Tercio.

> > > just clearly false.  SmartGWThas many, many Java override points that

> > > allow you to deeply customize behavior - not "getters/setters" but
> > > fundamentals like which cells are editable (listGrid.canEditCell()),
> > > how data is transmitted (various DataSource APIs), many aspects of how
> > > HTML is generated (getInnerHTML, cellFormatters, many others), and of
> > > course, countless events.   I think you have some misconceptions which
> > > date back to right after 1.0 was released - not every override point

> > > from SmartClient is yet available inSmartGWT, but we are getting

> > > closer to that all the time.
>
> > > On Aug 16, 8:45 pm, Tercio Filho <terciofi...@gmail.com> wrote:
>
> > > > On Aug 16, 7:39 pm, ckendrick <charles.kendr...@gmail.com> wrote:
>
> > > > > @tercio You're still missing the key point.  Let's try again:
>
> > > > > It is absolutely 100% required in an enterprise application that
> > > > > different components have different caches, potentially partially
> > > > > overlapping, on the same dataset.  A simple example is an interface
> > > > > for dragging and drop users between two different groups where both
> > > > > groups are very large and cannot be loaded in their entirety.  In

> > > > >SmartGWTthis is a single DataSource, and two ResultSets on that

> > > > > DataSource.  Each ResultSet loads the first batch of members of each
> > > > > group and is capable of paging in the rest as needed.
>

> > > > As I said in my first post, we cannot compareSmartGWTDataSource with

> > > > the GXT Store, as they do different jobs, DataSource inSmartGWTis
> > > > just a Proxy, or in GXT the Loader and the Reader, that's the function

> > > > of the DataSource inSmartGWT, retrieve data when somebody need it.
>
> > > > > It is not a drawback thatSmartGWThas separate caches per component.

> > > > > It's the correct architecture, and is a necessity where large datasets
> > > > > are involved.
>
> > > > I disagree that this is the right way to do things, I cannot accept
> > > > the fact that the widget manages it's data cache, widget is just a
> > > > widget, it has nothing to do with model data.
>
> > > > > As I mentioned previously, if the datasets involved are small, you can
> > > > > use a clientOnly DataSource, and then there is only one central
> > > > > cache.  This is the trivial case, which is the only one GXT currently
> > > > > handles.
>

> > > > > In either case (clientOnly or not) APIs exist inSmartGWTthat allow

> > > > > fetching data directly from the DataSource without the use of a
> > > > > component - you can both call methods like DataSource.fetchData(), or
> > > > > you can directly create a ResultSet.
>
> > > > Coupling problem, why should I, a data manipulator, must care about
> > > > this?? I just need the data, that's why the GXT Store is better, you
> > > > have a store,  a reader and a loader, layers of decoupling. One taking
> > > > care of another...
>
> > > > > Once you've absorbed all this, I think you will agree, theSmartGWT
> > > > > architecture is the correct one and the GXT architecture has
> > > > > limitations.
>

> > > > > Another mistatements: inSmartGWTyou can extend the built-in widgets

> > > > > and other classes and override methods.  People do this all the time.
>

> > > > And you CAN'T change a widget behavior inSmartGWT, at least in

> > > > Java... you have a lot of methods that you can override, but it's just
> > > > property setter/getters for JS code, it's internal behavior is inside
> > > > JS code, so, no go. Even extend is uncertain.
>
> > > > > I have no idea why you think more code would be involved withSmartGWT
> > > > > for server integration.  People constantly say the reverse.  There may
> > > > > other misconceptions there that I could address, if you were to
> > > > > explain why you think this is.  
>
> > > > About the server code I mentioned, i didn't made myself clear, I'd
> > > > like to say exactly this(Less work for the developer). I wish I have a
> > > > better english.. :-P
>
> > > > > Regardless, most professional,
> > > > > enterprise developers can easily justify a purchase ofSmartGWTPro,

> > > > > where the amount ofSmartGWT-specific server code involved is

[shay]

a few other aspects that i was considering before going with smart.

1) documentation on smart is much better, which is a major issue.
2) dev console is a huge help.
3) although "isomorphic" on the forums is at times "raw" , Ext have
their own "raw" posters which when combined with the lack of
documentation is a serious issue.
4) i found the ext architecture to be overly complex, for example
their data binding , maybe sometimes you need all this complexity ,
but sometimes you don't , Smart components allow me to start simple
and add complexity later, Ext forces me into the complexity from day
one.
5) I might be wrong , but Ext feels to me just like Spring, their open
source code is just a way to drive , sales of books, trade shows , and
support contracts. Now don't get me wrong they should be able to make
money , but i i find their approach a bit forced. not to mention the
fact that there are as good alternatives like smart that don't suffer
from these shortcomings.

Shay

[Shawn Brown]

Hi,

> the lack of
> documentation is a serious issue.
> 4) i found the ext architecture to be overly complex

> 5) I might be wrong , but Ext feels to me just like Spring, their open
> source code is just a way to drive , sales of books, trade shows , and
> support contracts.

I went with GXT and am happy with it. The samples they provide are a
much better source for understanding the architecture that a 3rd party
book I have on it.

Anyway, best luck to the smartGWT team!

[Jeremy Cohen]

The book on GXT is terrible. The GXT guys stiffed Grant Slender, who was an active user, contributor and author of this book who is no longer involved with the project. You can clearly tell that the book was published prematurely with broken samples and the chapters end abruptly skipping the whole APress EAP process. The author clearly wanted out.

The GXT API's change very frequently and they break a lot of API's across minor releases. There's are other really annoying technical issues like rendering bugs with layouts and resize but when factoring the total cost of GXT, it is not *only* USD 579. The release schedule is whimsical and their upgrade from major version 1.x to 2.x was totally unjustified given the new features that it added being very minor and the short duration of the existence of version 1.x, yet they required users to pay an upgrade fee. GXT 2.0 uses the old event mechanism to look for it to break all your API's when they upgrade to the new event handling mechanism. Possibly in v3.0 which will likely have an upgrade fee.

Sorry, I cannot deal with all this when we have a tight release schedule. I am no longer enamored by the shiny widgets on the Ext / GXT  family.  Buyer beware!