Its probably better to subclass Column with one or more custom fields than to add an Object database field to Column itself. If you have to cast anyway, you may as well cast the Column itself.
I don't have a strong opinion about this. Most of the comments are against the idea, so I'll drop it unless others chime in to support the idea. @portsi - Instead of a map, you can consider creating a CustomDelegateColumn that takes a Column instance as a constructor arg and adds some API. Then you wouldn't have to subclass TextColumn, SafeHtmlColumn, etc... you just subclass Column and delegate all existing methods in the Column API to the delegate. On 2011/08/04 19:27:29, rjrjr wrote:
You don't have to add a param type if the app data slot is simply of
type
object. No one will die if they have to cast the thing. But if the
people
who originally requested this feature are willing to back off and
maintain a
map instead, is even that much api clutter really warranted?
@portersi, what stopped you from using a custom column class instead
of a
map?
On Tue, Aug 2, 2011 at 1:53 PM, <mailto:jlaba...@google.com> wrote:
> This came up before, and here is the rationale. > > If you add an app specific data object to Column, you have to add > another parameterized type to Column. That's more verbose, somewhat > confusing, and it will be Void for most users anyway. I'm a big fan
of
> parameterized types because they make the API feels more
bulletproof,
> but I also think parameterized types can be cumbersome if they
aren't
> intended to support the most common use cases. > > Subclassing Column is good option if you need a lot of app specific > data. Yes you have to cast it, but who cares if you're in control
of
> which columns go into your table. In the original design, we
envisioned
> people subclassing Column for app specific data. > > So, now we're special casing the data store field as a string. But
MANY
> databases use String names to describe columns, and its just so > convenient to have that field accessible from the Column itself.
I've
> seen more than a few requests for this feature. If you are using an
SQL
> database, this will probably come in handy. If you don't need it,
don't
> use it, and the compiler should compile it out. > > > On 2011/08/02 20:13:12, rjrjr wrote: > >> It's John L's call, but that's certainly my preference. >> > > On Tue, Aug 2, 2011 at 1:10 PM, John Porter Simons >> > <porte...@google.com>wrote: > > > The other way we (me and dramos@) discussed doing this was, in
our
>> > CellTable subclass, have a map from Column to String to store
these
>> > database > >> > column names. I can update to that and revert this if you like. >> > >> > >> > On Tue, Aug 2, 2011 at 1:01 PM, Ray Ryan
<mailto:rj...@google.com>
>> > wrote: > >> > >> >> I was biting my tongue on this one, but I guess I'll jump in and >> > agree, > >> >> this smells bad. >> >> >> >> @jlabanca, is there no hook in Column or maybe Cell.Context
where
>> > this > >> >> kind of app-specific data can be added? >> >> >> >> On Tue, Aug 2, 2011 at 12:32 PM, Jeff Larsen >> > <mailto:larse...@gmail.com> wrote: > >> >> >> >>> I'm inclined to agree with Stephen here. No where else in GWT >> > widgetry > >> >>> is there a reference to database related things. I don't think >> > this is a big > >> >>> deal either, but it seems like a more application specific
thing
>> > rather than > >> >>> something that belongs inside GWT proper. >> >>> >> >>> -- >> >>>
http://groups.google.com/**group/Google-Web-Toolkit-**Contributors%3Chttp://groups.google.com/group/Google-Web-Toolkit-Contributors>
>> >>> >> >> >> >> >> > >> > > > >
http://gwt-code-reviews.**appspot.com/1503806/%3Chttp://gwt-code-reviews.appspot.com/1503806/>
>
http://gwt-code-reviews.appspot.com/1503806/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
