@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 <[email protected]> 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/... > > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
