Announcement Announcement Module
No announcement yet.
Automatic binding of table renderers Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Automatic binding of table renderers

    My class Person has
    - Date date
    - PersonType type (= tiger-enum)
    When I show a glazedlists of persons, it formats my date wrong and doesn't use my i18n tiger-enum binding, instead it shows something like:
    2007-01-01 | YOUNG
    2007-01-01 | OLD

    but it should be:
    01/01/2007 | Jong
    01/01/2007 | Oud

            glazedTableModel = new GlazedTableModel(getFinalList(), getMessageSource(), new String[]{"date", "type"}, getId()) {
                protected boolean isEditable(Object row, int column) {
                    return false;
            table = getComponentFactory().createTable(glazedTableModel);
    Is there any way to allow auto-configure the renderers of the table based on my properties?

  • #2
    Currently, the table model is not creating any bindings for the data displayed in the table. It is using the standard Swing renderer mechanisms.

    The question you ask about "auto-configure" the renderers is a difficult one to implement. The main problem lies in the fact that the "rendering" you are seeing when those properties are bound into a form are coming from specific bindings selected by the models we're all familiar with. However, a binding doesn't provide any mechanism to extract a table cell renderer that would perform the same formatting.

    This is a potentially interesting problem to solve, but it is intimately tied into the problems in having a collection of editable objects being presented in a large container (like an editable table). This has been discussed a few times in the past and there are a number of problems in dealing with it (validation, error reporting, commit management, etc.) that have not been worked out yet.

    Your best bet would be to create appropriate renderers for the class types in the table model. You can probably come up with a small set of generalized renderers that will handle your common types (dates, enums, etc.).



    • #3
      My use case only requires read-only renderers.
      Even with complete renderers (validation, error reporting, commit), wouldn't it be possible to reuse the current binders?


      • #4
        i'm not sure but Oliver has send to list-dev a code contribution and this contains an implementation for collection support
        to FormModel architecture and a DetailFormModelTableModel with a createColumnEditorBinding.
        Maybe it is useful

        there is a planned integration in spring-rcp?