@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. On Aug 15, 10:15 am, Tercio Filho <terciofi...@gmail.com> wrote: > 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 > > On Aug 15, 1:57 pm, Tercio Filho <terciofi...@gmail.com> wrote: > > > 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 > > > On Aug 15, 5:22 am, Aladdin <alaamu...@gmail.com> wrote: > > > > 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... > > > > > SmartGWT has half a dozen other features that make similar, real world > > > > impacts on performance. This is what actually matters in a deployed > > > > application. > > > > > On Aug 14, 10:59 am, Malte <mlegenhau...@gmail.com> wrote: > > > > > > 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 --~--~---------~--~----~------------~-------~--~----~ 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-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
