On Tue, Sep 23, 2008 at 3:13 AM, Hugh Gibson <[EMAIL PROTECTED]> wrote:
> > > The problem is that when the data model is passed to the
> > > constructor of the Table, the ID values are reset to the column
> names.
> > >
> >
> > Obviously, that's not where it happens. Sorry. It happens when
> > dataModel.setColumns() is called by the application. The problem I
> > described, however, still exists. The data model should be able to
> > set the ID values and not have them overridden with the column names,
> > right?
>
> I don't see the problem. qx.ui.table.model.Abstract.setColumns has two
> arguments - a list of column names and a list of IDs to use. If you pass
> through just the names, then the IDs are reset to the names as you
> describe. If you pass through both arrays then it's OK.
>
Right. I'm not changing that behavior. What is currently not easy to do,
but I think should be, is for the data model to set the IDs in its
constructor. The IDs are often an internally agreed issue between the data
model and the backend, and when that's the case, the application (which
calls setColumns() since it cares about what the user sees) shouldn't need
to know anything about those IDs. Without my proposed patch, though, as
soon as the application calls setColumns() without passing the second
parameter, the ID values specified by the data model in its constructor get
overwritten.
All right, I think this is going to be an innocuous change for most people,
probably everyone. Likely they're either passing the array of IDs to
setColumns() or they're not dealing with IDs. I'll go ahead and check in my
change.
Thanks.
Derrell
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
