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