Customizable, persisted column order and selection.

[mlavwilson2]

Hi Matthew

A further 3 questions:
1- any particular reason why the selection form is implemented as a Wizard? This seems to be OTT but I could have misunderstood something...

I planned on making a next page to set up the sorting on the selected columns, i want to get to this soon. But it could be converted to a dialog.

2- Is there a way to simplify the setup? at the moment, it requires both a class and a key name. The risk is that they could be going out of sync, one is used to get the tableFormat and the other the initial config (in settings) and labels (in messages.properties). That may be ok, but the ColumnInfo seems to have a lot of info and does not seem to take advantage of the discovery of attribute type (see GlazedTableModel). I will investigate further if it is ok with you.

In my application I have a Player.class. This player is displayed in many different tables, I want each to have its own selection persisted. However, I see the point the *.class could go away...

As for the GlazedTable model I discarded that when I discovered it did not support indexed and mapped properties. I have an attribute that returns an array of Float(s), I could not get the GlazedTableModel and BeanWrapper to display "player.projection[12]".

3- usage, it may be possible to have this behaviour by default if the TableFactory (may be) was able to handle all the glue work... For instance, I use GlazedTableModel everywhere with a modelId, that in turn could be used as the Key. More thinking to do of course... and it is getting late!

I like where this is going...

I've removed the beanutils dependencies and so far it seems working fine. I have also removed the DefaultTableFormat and used directly the GlazedTableModel. Again, it seems to work fine.

Thanks for this, it is cool stuff.

Benoit

Have you tested mapped and indexed properties?

[benoitx]

Thanks for the icons. I'd like to suggest a few changes, could you get in touch directly?

I must admit that I have *not* tested mapped or indexed properties. I do not know whether BeanWrapper support them or not...

Thanks & regards,

Benoit

[benoitx]

Hi

I'd also like to have possibility to entirely do away with the addTableInfo/addColumnInfo.

My thoughts (just that at the moment) is that the combination of modelId and list of columnNames given to a GlazedTableModel should be enough to build the Table/ColumnInfo on the fly if no special comparison/renderer etc are required.

I'd like to try this and send you the code (probably add a ColumnInfo constructor with less parameters and have an extended GlazedTableModel to handle the case where there is nothing known about the model/columns).

What do you think?

Best regards

Benoit

PS: I did move the Wizard to a dialog but as you mention the sorting... that'd be cool to have so I have reverted to a Wizard. In order to display the title correctly, you need to explicitly setTitle on the dialog in TableCustomizationWizard.
For the "Title Panel Title" and "Title pane description" I've found that one needs to add a id to the TableCustomizationWizard and then have a message:
id.pageId.title and id.pageId.caption entries.

[mlavwilson2]

I could not get GlazedTableModel to render indexed or mapped properties. This is a feature I can not afford to give up. So we need to have an extension point so that I can plug in my impl to replace the GlazedTableModel. However, I think you want to delegate some of the work down to the GlazedTableModel. Be careful we do not want to eliminate indexed properties.

Hi

I'd also like to have possibility to entirely do away with the addTableInfo/addColumnInfo.

My thoughts (just that at the moment) is that the combination of modelId and list of columnNames given to a GlazedTableModel should be enough to build the Table/ColumnInfo on the fly if no special comparison/renderer etc are required.

I'd like to try this and send you the code (probably add a ColumnInfo constructor with less parameters and have an extended GlazedTableModel to handle the case where there is nothing known about the model/columns).

What do you think?

Best regards

Benoit

I like the auto discovery of table attributes, however I need the ability to limit what the user can configure. There are some public methods that mean nothing to the end user. I also would not want to loose the ability to set the min, recomended and max column widths. So overloading the method with less params would be cool.

PS: I did move the Wizard to a dialog but as you mention the sorting... that'd be cool to have so I have reverted to a Wizard. In order to display the title correctly, you need to explicitly setTitle on the dialog in TableCustomizationWizard.
For the "Title Panel Title" and "Title pane description" I've found that one needs to add a id to the TableCustomizationWizard and then have a message:
id.pageId.title and id.pageId.caption entries.

I was wondering why it was not displaying a title like the rest of my wizards

[benoitx]

I guess we could have an injected implementation for the getValue/setValue onthe CustomizableTableFormat.

One using beanUtils and the other beanWrapper.

I'm currently modifying things to allow auto-discovery (without removing the ability to fully define it as you have now).

Best regards from London,

Benoit

[mlavwilson2]

I guess we could have an injected implementation for the getValue/setValue onthe CustomizableTableFormat.

One using beanUtils and the other beanWrapper.

Benoit

That would work. We could have the beanWrapper be the default implementation, that would lower the required depends