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