Skip to main content

MetaData

12 replies [Last post]
rbair
Offline
Joined: 2003-07-08

Wow, today's my day for posting :-)

Some thoughts on MetaData (for DataModel columns):

Small improvement, but what about adding a default label of "valueX" where x is an incrementing number (static to the class)? This is just a little nicety if, for instance, a bunch of data is read into a DataModel with no label information

There is a @todo on SetLabel. Is this still to be done?

How do you envision maxValueCount being used? It seems to me like simply changing the column class to collection.class or List.class would achieve the same thing while being a bit more straightforward.

Rich

Reply viewing options

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

jdnc-interest@javadesktop.org wrote:

>>As I mentioned in an earlier thread,
>>columnDisplaySize property is the width of the data
>>column in characters, and might not make sense for
>>all kinds of columns (such as those containing
>>images). PreferredSize, or labelWidth (in pixels)
>>belongs in TableColumn (or its extension), not in the
>>model metadata.
>
>
> Ok, so for instance, I have a RowSet retrieved over the internet from a remote server. The RowSet contains in it sensible columnDisplaySize defaults. However all that information is lost when the RowSet is wrapped by a DataModel.
>
> If the DataModel's MetaData doesn't contain this information, then I have to create a custom MetaData/DataModel that DOES contain that information. I would also have to create a custom TableBinding that would take this into account when setting up the table.
>
> On the other hand, if there was a displayWidth stored in MetaData, the existing infrastructure could be used to accomplish the same thing. Furthermore, the displayWidth could be specified to be in characters. Also, the displayWidth would only be a hint.
>
> So, for columns that contain images (which is possibly discernable by checking the MetaData's getElementClass) the hint may well be ignored, but for String data, the binding could attempt to honor the setting.
> ---
> [Message sent by forum member 'rbair' (Richard Bair)]

I agree that it is advantageous to supply such hints in model meta-data
since multiple UI components might be bound to the same model element
and this allows for more sensible visual defaults. One should always
be able to override the visual settings in the UI component of course.

So yes, if we are wrapping a RowSet, then we'll surface any displaySize
property as a displayWidth (or whatever we ultimately name it) on the
StringMetaData wrapper.

Aim

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

rbair
Offline
Joined: 2003-07-08

Hi Aim,

Yes, I did notice the StringMetaData (and the others), but I had a few questions about its use. One thing that kind of bothers me about the design of these meta data classes is that they require an awful lot of casting. For instance, a basic data model would have an array/list of MetaData objects. Each bound component then can retrieve the meta data for the field they are bound to via the getMetaData(String field) method. However, the binding must then either assume that the MetaData is of a certain type (such as StringMetaData), or it must check (a stack of instanceof checks). The first choice is unstable, and the second is not extendable (what if the MetaData is MyCustomMetaData instead?).

This is fundementally why I wanted to get displaySize put into MetaData itself, so I don't have to do a bunch of instanceof checks or casts.

Cheers,
Rich

Amy Fowler

jdnc-interest@javadesktop.org wrote:
> Hi Aim,
>
> Yes, I did notice the StringMetaData (and the others), but I had a few questions about its use. One thing that kind of bothers me about the design of these meta data classes is that they require an awful lot of casting. For instance, a basic data model would have an array/list of MetaData objects. Each bound component then can retrieve the meta data for the field they are bound to via the getMetaData(String field) method. However, the binding must then either assume that the MetaData is of a certain type (such as StringMetaData), or it must check (a stack of instanceof checks). The first choice is unstable, and the second is not extendable (what if the MetaData is MyCustomMetaData instead?).

In my first rev of MetaData I had only a single class with all the
various type-specific constraint properties. Early critique suggested
breaking the class up to ensure more context-appropriate properties.
But as you mention, there are definite downsides to the multi-class
design, so it may be worth pondering collapsing these classes again.

At a minimum it probably makes sense to fold StringMetaData back into
the base MetaData class, since strings likely account for the majority
of data types.

Aim

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

rbair
Offline
Joined: 2003-07-08

Hmmm... what about a properties based approach? Kind of what I did with the Application object. In the Application object that I posted on another thread we have certain convenience methods for accessing things such as the datasource etc, and then generic setProperty(String key, Object val) and getProperty(String key, Object default) methods for setting any miscellaneous application property.

The same could be done with MetaData. Allow for basic settings such as DisplayWidth and whatnot to be supported directly, and then use a getProperty/setProperty method pair for setting whatever custom setting you want.

In this way, components that want the custom setting can check for it and use a sensible default if it doesn't exist, while not cluttering up the API.

Amy Fowler

jdnc-interest@javadesktop.org wrote:

> Hmmm... what about a properties based approach? Kind of what I did with the Application object. In the Application object that I posted on another thread we have certain convenience methods for accessing things such as the datasource etc, and then generic setProperty(String key, Object val) and getProperty(String key, Object default) methods for setting any miscellaneous application property.
>
> The same could be done with MetaData. Allow for basic settings such as DisplayWidth and whatnot to be supported directly, and then use a getProperty/setProperty method pair for setting whatever custom setting you want.
>
> In this way, components that want the custom setting can check for it and use a sensible default if it doesn't exist, while not cluttering up the API.

I did consider this approach in the design. I'd characterize this
as 'Attribute' support, which is generally more flexible but a little less
api/tools-friendly than straight property support. In fact, when I
worked on JSF, I put in this exact design on the components (properties
for concrete, guaranteed component settings and attributes for settings
which were renderer dependent). And I'll confess that some people felt it
was too complicated. It would be nice if the JavaBeans spec
included support for 'attributes' so that tools would build-in support
for discovering and setting attributes.

But I think this is a reasonable suggestion worth considering, so I'll
go back and look at it again. I'd also like to discuss it with some tools
folks (if any of you are paying attention, I'd welcome input on the properties
vs attributes issue).

Aim

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

Amy Fowler

jdnc-interest@javadesktop.org wrote:

> Another thing: what about adding a preferredSize, or labelWidth or something to MetaData? RowSetMetaData has the notion of column display size, and the same could be useful in MetaData.
>
> The fear in adding funtionality like this to MetaData is that it opens the way up for adding a ton of stuff to the api that may or may not be applicable for everyone. The upside is, of course, new functionality.
>

The StringMetaData subclass supports a "displayWidth" property, which is
fairly ambiguous as it isn't obvious whether its referring to number of
chars or number of pixels (it's the former). How about "displayLength"
or "displaySize" (to be consistent with RowSetMetaData).

Aim

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

Amy Fowler

Hi Rich,

jdnc-interest@javadesktop.org wrote:

>
> Some thoughts on MetaData (for DataModel columns):
>
> Small improvement, but what about adding a default label of "valueX" where x is an incrementing number (static to the class)? This is just a little nicety if, for instance, a bunch of data is read into a DataModel with no label information

If no label is set, it will default to the metaData's "name" property.
We should probably initialize the name (and hence the label) for
columns in the way you describe. I'll try to remember to do this,
but filing an RFE would ensure I won't forget!

> There is a @todo on SetLabel. Is this still to be done?

Do you like "label" or "title" better? I'm fond of "label", but would
go with the majority opinion.

>
> How do you envision maxValueCount being used? It seems to me like simply changing the column class to collection.class or List.class would achieve the same thing while being a bit more straightforward.

Specifying the column class as a collection only indicates that there
be 0 to n values for that column. maxValueCount enables an upper bound
to be specified.

Aim

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

rbair
Offline
Joined: 2003-07-08

> > There is a @todo on SetLabel. Is this still to be
> done?
>
> Do you like "label" or "title" better? I'm fond of
> "label", but would
> go with the majority opinion.

I'm quite happy with label personally. I think its probably 6's either way.

rbair
Offline
Joined: 2003-07-08

Another thing: what about adding a preferredSize, or labelWidth or something to MetaData? RowSetMetaData has the notion of column display size, and the same could be useful in MetaData.

The fear in adding funtionality like this to MetaData is that it opens the way up for adding a ton of stuff to the api that may or may not be applicable for everyone. The upside is, of course, new functionality.

Rich

rameshgupta
Offline
Joined: 2004-06-04

> Another thing: what about adding a preferredSize, or
> labelWidth or something to MetaData? RowSetMetaData
> has the notion of column display size, and the same
> could be useful in MetaData.
>
[snip]
>
> Rich

As I mentioned in an earlier thread, columnDisplaySize property is the width of the data column in characters, and might not make sense for all kinds of columns (such as those containing images). PreferredSize, or labelWidth (in pixels) belongs in TableColumn (or its extension), not in the model metadata.

Ramesh

rbair
Offline
Joined: 2003-07-08

> As I mentioned in an earlier thread,
> columnDisplaySize property is the width of the data
> column in characters, and might not make sense for
> all kinds of columns (such as those containing
> images). PreferredSize, or labelWidth (in pixels)
> belongs in TableColumn (or its extension), not in the
> model metadata.

Ok, so for instance, I have a RowSet retrieved over the internet from a remote server. The RowSet contains in it sensible columnDisplaySize defaults. However all that information is lost when the RowSet is wrapped by a DataModel.

If the DataModel's MetaData doesn't contain this information, then I have to create a custom MetaData/DataModel that DOES contain that information. I would also have to create a custom TableBinding that would take this into account when setting up the table.

On the other hand, if there was a displayWidth stored in MetaData, the existing infrastructure could be used to accomplish the same thing. Furthermore, the displayWidth could be specified to be in characters. Also, the displayWidth would only be a hint.

So, for columns that contain images (which is possibly discernable by checking the MetaData's getElementClass) the hint may well be ignored, but for String data, the binding could attempt to honor the setting.

rameshgupta
Offline
Joined: 2004-06-04

[snip]
> Ok, so for instance, I have a RowSet retrieved over
> the internet from a remote server. The RowSet
> contains in it sensible columnDisplaySize defaults.
> However all that information is lost when the RowSet
> is wrapped by a DataModel.
>
Yes, this is a hole right now. We do have plans to implement proper support for WebRowSet for use with JXTable/JNTable. We need to make sure that we preserve as much metadata as possible.

[snip]
> On the other hand, if there was a displayWidth stored
> in MetaData, the existing infrastructure could be
> used to accomplish the same thing. Furthermore, the
> displayWidth could be specified to be in characters.
> Also, the displayWidth would only be a hint.

If we want to remain compatible with WebRowSet, we cannot change the semantics of columnDisplaySize. I think this means, for example, if the ZIP_CODE column has a columnDisplaySize of 5 characters, then it is a hint that the column typically contains 5 characters even if some records contain zip+4 data in that column. In any case, columnDisplaySize describes a property of the data in the column, not a property of the view itself.

On the other hand, the pixel width for the column is a view property, and must be set on a per-table-column basis. If two views share the same underlying RowSet (and therefore the same MetaData), they may independently set column width preferences.

>
> So, for columns that contain images (which is
> possibly discernable by checking the MetaData's
> getElementClass) the hint may well be ignored, but
> for String data, the binding could attempt to honor
> the setting.

One thing we could do is use the columnDisplaySize property from the MetaData as a hint and convert it to pixel values, but only as a fallback, if no prototype value or column width preference has been specified. Should we do this?

Ramesh