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. On Aug 17, 8:12 pm, ckendrick <[email protected]> wrote: > 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 <[email protected]> wrote: > > > > > ckendrick, is canEditCell() a behavior or a feature? > > > protected native boolean canEditCell(int rowNum, int colNum) /*-{ > > var self = > > [email protected]::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. > > > On Aug 17, 1:56 pm, ckendrick <[email protected]> wrote: > > > > 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. 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 <[email protected]> wrote: > > > > > On Aug 16, 7:39 pm, ckendrick <[email protected]> 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 > > > > > 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 [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 -~----------~----~----~----~------~----~------~--~---
