Skip to main content

columns & inconsistent metadata nomenclature

6 replies [Last post]
Anonymous

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Kleopatra

Hi Amy,
> > I feel a bit uncomfortable with it because the columns are created twice: first
> > in table.setModel (in TableElement.dataAssimilator) and then when the markup for
> > the columns is found. I would expect that the columns which were created first
> > would be modified by the latter instead of overwriting them with newly created
> > ones.
>
> The problem with the modify approach is that in the markup, the set of
> table *view* elements may not match the set of data
> elements, since we allow the view columns to be a re-ordered subset of the
> data columns. Perhaps what the dataAssimilator ought to do is check to see
> if there's a tag on the table, and if so, set autoCreateColumnsFromModel
> to false before setting the model. This would avoid the initial creation of
> the table columns when the model is set.
>

Sounds goods. BTW, the above fix might not be enough - seems that the
identifier has to be set in JXTable.addColumn() as well

public void addColumn(TableColumn column) {
super.addColumn(column);
if (column.getIdentifer() == column.getHeaderValue()) {
column.setIdentifier(column.getHeaderValue());
}
}

looks funny, I know The issue is that TableColumn.getIdentifer
returns the headerValue if the identifer is not explicitly set, thus
augmenting the confusion.

There's a similar issue with TreeTable: it can be seen when running the
treeTable.jdnc demo. Could not find a fix after a quick glance, though,
and did not try harder, I'm lazy and you are more familiar with the code
base.

>
> One reason I went with "name"(String) and "label"(String) in MetaData was
> because that is what ResultSetMetaData/RowSetMetaData use, but perhaps its
> better to be consistent with Swing.
>

Working mostly in the Swing realm, I would prefer to be consistent with
Swing - surprise, surprise :-)

>
> =>So, I'm in favor of changing MetaData from having "name"(String) to
> "identifer"(Object) for this identifying property.
>

I agree. Nevertheless I would like to reserve the "name" for identifying
purposes when Strings are involved: it would come handy to map the
identifier.toString() to a component.getName() on binding - this would
allow reasonably unique access to automatically created components on a
form later in their lifetime, f.i. for data-dependent
enabling/disabling.

> If we want the API and tag library to be consistent,
> that would mean we'd use "xml:id" for referencing tags and "identifier"
> for referencing the objects. A bit confusing, but perhaps not much more
> so than the current "name" vs. "xml:id" attribute scenario, which already
> perplexes newcomers.
>

at least both "xml:id" and "identifier" both are clear about identifying
... Maybe it's even easier to understand the difference is the scope of
referencing.

> "headerValue" vs. "title" vs. "label" vs. "name"
> ------------------------------------------------
>
> Unfortunately, it appears that the TableModel's getColumnName() method
> is intended to return the headerValue:
>
> * Returns the name of the column at columnIndex. This is used
> * to initialize the table's column header name. Note: this name does
> * not need to be unique; two columns in a table can have the same name.
>

ARRGGG... I'm getting sloppy, could have checked myself, sorry.
Interestingly TabularDataModel does not follow this contract, it returns
metaData.getName() - filed already as issue 46. This needs a very
careful fix and clarification of the api, including:

- TabularDataModel.getColumnName() should return the metaData.getLabel()
- the parameter in TabularDataModel.getColumnIndex(String) should be
defined as meaning the metaData.identifier. Then the method must no
longer be implemented via comparing with getColumnName()
- TabularDataModelAdapter.getFieldNames() must not use
model.getColumnName

IMO the issue 46 should get a higher priority, maybe even P1.

> I've no huge opinion whether we go with "title"(String) or "label"(String),
> though there is the ResultSetMetaData/RowSetMetaData "label" precedent.
>

> =>Anyone want to weigh in a vote on "title" vs "label"?

>From a Swing perspective it should be "text" :-) My second vote is for
"label" because "title" in the context of Swing is - kind of - reserved
for "window's title".

Greetings
Jeanette

Amy Fowler

Hi Jeanette,

All very excellent points...I'll move this discussion to the forum
since it has some interesting issues.

kleopatra@dev.java.net wrote:

> https://jdnc.dev.java.net/issues/show_bug.cgi?id=50
>
> ------- Additional comments from kleopatra@dev.java.net Thu Aug 12 13:09:32 +0000 2004 -------
> On the surface the reason seems to be that the tableColumn identifier is not set
> properly at the time of calling the bindingApplier. A quick fix is to make the
> bindingApplier responsible for setting the identifier to the binding's attribute
> value:
>
> public static final AttributeApplier bindingApplier = new AttributeApplier() {
> public void apply(Realizable target, String namespaceURI,
> String attributeName, String attributeValue) throws
> ApplierException {
> int columnIndex = TableColumnAttributes.getModelIndex(target,
> attributeValue);
> if (columnIndex >= 0) {
> TableColumnExt column = (TableColumnExt) target.getObject();
> column.setModelIndex(columnIndex);
> column.setIdentifier(attributeValue);
> }
> }
> };
>
> I feel a bit uncomfortable with it because the columns are created twice: first
> in table.setModel (in TableElement.dataAssimilator) and then when the markup for
> the columns is found. I would expect that the columns which were created first
> would be modified by the latter instead of overwriting them with newly created
> ones.

The problem with the modify approach is that in the markup, the set of
table *view* elements may not match the set of data
elements, since we allow the view columns to be a re-ordered subset of the
data columns. Perhaps what the dataAssimilator ought to do is check to see
if there's a tag on the table, and if so, set autoCreateColumnsFromModel
to false before setting the model. This would avoid the initial creation of
the table columns when the model is set.

>
> Further I would suggest to clean up the naming mess: there are two semantic
> properties, let's call them "identifierValue" and "displayValue". The pair is
> mapped very differently in different parts of the api (not sure if I got it
> right, it's a bit confusing :-):
>
> DataField markup: "name"/"title"
> MetaData: "name"/"label"
> TableColumn: "identifier"/"name" (=internally "headerValue")
> TableColumnExt: "identifier"/"title"
> Column markup: "binding"/"title"
> TableModel: none/"name" or "name"/none - the original intention is a bit vague.

We are stuck with "identifier"(Object) and "headerValue"(Object)
in TableColumn.

One reason I went with "name"(String) and "label"(String) in MetaData was
because that is what ResultSetMetaData/RowSetMetaData use, but perhaps its
better to be consistent with Swing.

"identifier" vs. "name"
-----------------------

In thinking about it, "identifier" is more descriptive of the property's
purpose, which is to serve as the key to uniquely identify the object
within some scope (in this case, the ColumnModel). It is also type Object
(vs String) which has been the source of a debate which we've had inside
the Swing team. I was initially (& somewhat irrationally) in favor of
using String for this purpose (for simplicity & synergy with markup), but
Scott Violet finally humbled me into admitting that using Object was much
more flexible at the API level.

=>So, I'm in favor of changing MetaData from having "name"(String) to
"identifer"(Object) for this identifying property.

The only problem with "identifier" is that it clashes with the notion of
the "xml:id" attribute in the markup, where the latter is specifically used to
specify a reference to an object *tag* instance, rather than identify
the object realized from that tag. Currently in our schema, we use
"xml:id" for referencing tags and "name" for referencing the underlying
realized objects. If we want the API and tag library to be consistent,
that would mean we'd use "xml:id" for referencing tags and "identifier"
for referencing the objects. A bit confusing, but perhaps not much more
so than the current "name" vs. "xml:id" attribute scenario, which already
perplexes newcomers.

"headerValue" vs. "title" vs. "label" vs. "name"
------------------------------------------------

Unfortunately, it appears that the TableModel's getColumnName() method
is intended to return the headerValue:

* Returns the name of the column at columnIndex. This is used
* to initialize the table's column header name. Note: this name does
* not need to be unique; two columns in a table can have the same name.

I really don't care for "headerValue" or "name" as the generic name to
establish the user-friendly, localizable labeling property of a
data field, so I'm a little reluctant to adopt either in MetaData for the purpose.

I've no huge opinion whether we go with "title"(String) or "label"(String),
though there is the ResultSetMetaData/RowSetMetaData "label" precedent.

=>Anyone want to weigh in a vote on "title" vs "label"?

Aim

rameshgupta
Offline
Joined: 2004-06-04

> =>Anyone want to weigh in a vote on "title" vs
> "label"?
>

As long as we are dealing with just the string value, I prefer to call it "title". But when we are referring to the string value *together* with visual attributes, such as alignment, fore/back color, ..., I prefer to call it "label". This is how Swing uses these terms (most of the time, anyway).

Ramesh

Kleopatra

Hi Ramesh,

> I prefer to call it "label". This is how Swing uses these terms (most of the time, anyway).
>

Hmm, "most of the time" might be arguable (and I love to argue and
cannot resist now :-).
Swing has methods getLabel() in

- AbstractButton: it's deprecated
- JPopupMenu: returns the label of the popup itself
- Option: some really hidden class in text.html

The alternativ for getting the "displayed text" is getText(), it's used
in

- AbstractButton
- JLabel
- all JTextComponents (which don't really count, conceded :)

For me that looks like there had been a discussion sometime early in
Swing life and "text" won over "label".

Greetings
Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

Amy Fowler

Upon reflection and conversations with Ramesh....
For MetaData, I think "title" is the best choice, as the data
description is supposed to be completely independent of the UI,
and in such a context, "label" is a little ambiguous and "text" isn't
at all descriptive.

Aim

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

Kleopatra

Amy Fowler wrote:
>
> Upon reflection and conversations with Ramesh....
> For MetaData, I think "title" is the best choice, as the data
> description is supposed to be completely independent of the UI,
> and in such a context, "label" is a little ambiguous and "text" isn't
> at all descriptive.
>

okay - the "independ" argument wins me :-)

Greetings
Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net