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