Skip to main content

MetaData enhancement: additional fields

14 replies [Last post]
Anonymous

Are there any plans to support custom properties in MetaData? What I
mean is something similar to Action where we can store any key/value
pair. Would come handy in custom FormFactories.

Yeah, I actually ran into a use-case :

Currently I'm playing with a Form/SubForm scenario where the outer form
should contain a collection view whose selection will drive the content
of the nested form.

That can be handled nicely by a controlling DataModel which is fed by a
collection model, f.i a TabularDataModel/ListModel whatever. It's
responsibility is to wrap it into an appropriate DataModelAdapter,
create a ListSelectionModel and keep the nested DataModel's recordIndex
in synch with the selectionModel. A TableBinding will bind the field
with the TabularDataModel to the JTable and set the JTable's
rowSelectionModel to the field exposing the selectionModel.

And now comes (at last :-) the problem: the outer form tries to create
and bind a JComponent to every field, which will blow up for the field
selectionModel. Here it would be nice to have a metaData property
"ignoreInForm" which could be checked by the FormFactory.

This may lead to a related question: is it okay to store non-visual
value/metaData pairs in a DataModel? I think it should - opens up quite
a lot of possibilities for specialized DataModels: the above mentioned
controller f.i. exposes the current selection index and the rowCount, so
it's easy to implement f.i. navigating across records by listening to
these fields only without a need to know the concrete nature of the
collection.

Greetings
Jeanette

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

Reply viewing options

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

I checked in the MetaData API to support custom properties
(courtesy of Rich's incubator version):

public void putCustomProperty(String key, Object value)
public Object getCustomProperty(String key)
public Object getCustomProperty(String key, Object defaultValue)

Also added:

public void removeCustomProperty(String key)
public String[] getCustomPropertyKeys()

Setting an existing custom property to a new value WILL fire
a property change event.

Note that I did change the exception thrown for null key params
from IllegalArgumentException to NullPointerException. I know
this gets debated to death, but awhile back I clarified this with
Josh Bloch, who confirmed it's preferable to throw the most
descriptive exception possible, which in this case is the NPE.
(minor)

As far as collapsing StringMetaData, EnumeratedMetaData, and
NumberMetaData, I'd like to hold off until I can do some more
experimenting with how such a change would effect the FormFactory
code, which, as Jeanette points out, was written with a tight
deadline in mind and has yet to be 'revisited' :-)

Oh, but I will promote displayWidth from StringMetaData to
MetaData in the meantime.

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:
>
> I checked in the MetaData API to support custom properties
> (courtesy of Rich's incubator version):
>

Things are moving, great!

Just a minor comment:

> public void putCustomProperty(String key, Object value)

I would prefer that to be "setCustomProperty" - it's meant to be used as
a property and it's easier to remember/find the name of the
method if it's as near the normal get/set as possible.

>
> Setting an existing custom property to a new value WILL fire
> a property change event.

Hmm, I don't quite understand the distinction: whenever in
a sequence of method calls

firstValue =

secondValue =

may lead to secondValue != firstValue then must fire a
propertyChange. So put/remove always have to fire, I think.

>
> Note that I did change the exception thrown for null key params
> from IllegalArgumentException to NullPointerException. I know
> this gets debated to death, but awhile back I clarified this with
> Josh Bloch, who confirmed it's preferable to throw the most
> descriptive exception possible, which in this case is the NPE.
> (minor)

but - good decision.

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

Kleopatra wrote:

>> public void putCustomProperty(String key, Object value)
>
>
> I would prefer that to be "setCustomProperty" - it's meant to be used as
> a property and it's easier to remember/find the name of the
> method if it's as near the normal get/set as possible.

No big argument with this change. Though in webtier speak, these
would be called "Attributes" rather than "Properties" to denote
the divergence from the JavaBean property pattern.

>>Setting an existing custom property to a new value WILL fire
>>a property change event.
>
>
> Hmm, I don't quite understand the distinction: whenever in
> a sequence of method calls
>
> firstValue =
>
> secondValue =
>
> may lead to secondValue != firstValue then must fire a
> propertyChange. So put/remove always have to fire, I think.

I debated this one. Would you expect the oldValue to be "null"
on the first put and newValue to be "null" on remove (?)

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:
>
> No big argument with this change. Though in webtier speak, these
> would be called "Attributes" rather than "Properties" to denote
> the divergence from the JavaBean property pattern.
>

no argument here.

> >
> > firstValue =
> >
> > secondValue =
> >
> > may lead to secondValue != firstValue then must fire a
> > propertyChange. So put/remove always have to fire, I think.
>
> I debated this one. Would you expect the oldValue to be "null"
> on the first put and newValue to be "null" on remove (?)
>

well, it is ... that's what getCustomProperty returns or not (may be too
early for me, though :-)?

Jeanette

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

Kleopatra

>
> Lets get rid of the HierarchicalDataMetaData, EnumeratedMetaData, NumberMetaData, and StringMetaData while we're at it.
>
> The problem with the proliferation of MetaData is two-fold. First, it clutters the API (certainly not a big deal). Second, all MetaData for a DataModel are contained in a collection holding objects of type MetaData (or worse, Object). Thus you must cast from MetaData to StringMetaData or NumberMetaData, etc. But you can only do that if you know what type it is. So, you end up with mile-long if(md instanceof StringMetaData) statements. If a new meta data type is added, you have to go add another elseif to every one of these structures.

I can't see anything wrong with typed MetaData if they are properly
factored. And no - you end up with if-else only in such raw code as the
DefaultFormFactory which is veeery raw, looks like just a quick shot to
have to show something at all. I bet those constructs will be replaced
by clean OO-code in the next serious effort to clean it up :-) And then
typing will help a lot: you can easily register component/binding
creators based on MetaData type, f.i. similar to the renderer choosing
in JTable.

Greetings
Jeanette

---------------------------------------------------------------------
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
Points: 0

> I can't see anything wrong with typed MetaData if they are properly factored. And no - you end up with if-else only in such raw code as the DefaultFormFactory which is veeery raw, looks like just a quick shot to have to show something at all. I bet those constructs will be replaced by clean OO-code in the next serious effort to clean it up :-) And then typing will help a lot: you can easily register component/binding creators based on MetaData type, f.i. similar to the renderer choosing in JTable.

I'll believe it when I see it ;). IMHO we'd be better off to borrow (note I said borrow and not extend!) from RowSetMetaData than roll our own. I have yet to run into a constraint on data that SQL doesn't provide for. That, coupled with custom properties (providing an extension point for custom code) will give us all we need, I think.

Richard

Kleopatra

jdnc-interest@javadesktop.org wrote:
>
> I'll believe it when I see it ;).

you will :-)

> IMHO we'd be better off to borrow (note I said borrow and not extend!) from RowSetMetaData than roll our own. I have yet to run into a constraint on data that SQL doesn't provide for.

Hmm ... maybe I misunderstand you (the SQL/JDBC realm is nothing I
particularly like), but let mere integers act as typing flags is not
exactly what I would use in an OO-world.

Greetings
Jeanette

---------------------------------------------------------------------
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
Points: 0

Hey Jeanette,

> >
> > I'll believe it when I see it ;).
>
> you will :-)

Looking forward to it :)

> Hmm ... maybe I misunderstand you (the SQL/JDBC realm
> is nothing I
> particularly like), but let mere integers act as
> typing flags is not
> exactly what I would use in an OO-world.

Don't get me wrong, I like the strongly typed MetaData approach. I just can't see how you'll be able to get around the casts & if..else constructs. I hope you *can* refactor things so it works out.

Richard

Amy Fowler

Kleopatra wrote:

> Are there any plans to support custom properties in MetaData? What I
> mean is something similar to Action where we can store any key/value
> pair. Would come handy in custom FormFactories.

I think it's a fine idea to add API for storing custom key/value
attributes on MetaData. This is a good way to support some of the more
obscure/uncommon constaints, as well as those custom to apps.
I'll file an RFE unless you beat me to it :-)

>
> And now comes (at last :-) the problem: the outer form tries to create
> and bind a JComponent to every field, which will blow up for the field
> selectionModel. Here it would be nice to have a metaData property
> "ignoreInForm" which could be checked by the FormFactory.
>
> This may lead to a related question: is it okay to store non-visual
> value/metaData pairs in a DataModel? I think it should - opens up quite
> a lot of possibilities for specialized DataModels: the above mentioned
> controller f.i. exposes the current selection index and the rowCount, so
> it's easy to implement f.i. navigating across records by listening to
> these fields only without a need to know the concrete nature of the
> collection.

I think the DataModel can contain data of any flavor - be it data that
is or isn't visualized by the GUI. I'll have to think about the "ignoreInForm"
property -- it doesn't feel immediately right to me. One thing to keep in
mind is that although by default JForm uses the FormFactory to automatically
create components/bindings for ALL fields in a given data model, it's possible
to selectively bind individual fields. In fact, a form may have bindings
to multiple fields in multiple data models.

e.g. stolen from JForm javadoc:

Customer customer = new Customer(); // bean
Cart cart = new Cart(); // bean

JForm form = new JForm();
try {
form.bind(customer, "firstName"); // binds to "firstName" property
form.bind(customer, "lastName"); // binds to "lastName" property
form.bind(customer, "address"); // binds to "address" property (nested bean)
form.bind(cart, "items"); // binds to "items" property
} catch (BindException e) {
}

One might imagine how a tool could really facilitate this selection
of fields to bind when creating a form.

Aim

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

Kleopatra

Amy,

>
> I think it's a fine idea to add API for storing custom key/value
> attributes on MetaData. This is a good way to support some of the more
> obscure/uncommon constaints, as well as those custom to apps.
> I'll file an RFE unless you beat me to it :-)

No, I'll leave it your.

>
> I think the DataModel can contain data of any flavor - be it data that
> is or isn't visualized by the GUI. I'll have to think about the "ignoreInForm"
> property -- it doesn't feel immediately right to me.

no problem - if we have custom attributes.

> One thing to keep in
> mind is that although by default JForm uses the FormFactory to automatically
> create components/bindings for ALL fields in a given data model, it's possible
> to selectively bind individual fields.

Thanks for the reminder - but did I ever tell you that I'm greedy by
nature, wanting _both_ selective and automatic binding :-)

Greetings
Jeanette

---------------------------------------------------------------------
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
Points: 0
Kleopatra

jdnc-interest@javadesktop.org wrote:
>
> Check out https://jdnc-incubator.dev.java.net/source/browse/jdnc-incubator/src/jav... for a possible implementation.

fine - except for the missing propertyChange notification when setting a
custom property.

Greetings
Jeanette

---------------------------------------------------------------------
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
Points: 0

+1

Lets get rid of the HierarchicalDataMetaData, EnumeratedMetaData, NumberMetaData, and StringMetaData while we're at it.

The problem with the proliferation of MetaData is two-fold. First, it clutters the API (certainly not a big deal). Second, all MetaData for a DataModel are contained in a collection holding objects of type MetaData (or worse, Object). Thus you must cast from MetaData to StringMetaData or NumberMetaData, etc. But you can only do that if you know what type it is. So, you end up with mile-long if(md instanceof StringMetaData) statements. If a new meta data type is added, you have to go add another elseif to every one of these structures.

I think having an extensible property structure as you describe will therefore remove the need for these other classes, and clean things up as well.

Richard

Amy Fowler

jdnc-interest@javadesktop.org wrote:

> +1
>
> Lets get rid of the HierarchicalDataMetaData, EnumeratedMetaData, NumberMetaData, and StringMetaData while we're at it.

So I think I'm in agreement with this as well, however I do want to
keep as many of the meta-data properties as bean-compliant as possible so
they can be readily configurable via tools; 'client properties' are neither
type-safe, nor truly introspectible by existing tools. This will mean
we trade off the instanceof checks for complex checks on the 'fieldClass'
to determine which metadata properties we deem appropriate for that class.

note: HierarchicalDataMetaData is an old kludge that is left over from
an ancient incantation of the API; it has nothing to do with
MetaData or its subclasses and is long overdue to be removed.

Aim

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