Rocky Horror Picture Show: generics, binding and varargs (aka: arrays)

[jdnc-interest]

The preface of the story: while under my hat as application developer (roaming in the swinglabs-demos), I learned a love a nice little pattern that Karl introduced for binding to selection in trees or combos which begged to be generified (after c&p the base several times <g>). It goes along the lines

[code]

// wrap the element we want to bind into some class which carries a description
// for use in the display

public class DisplayInfo<T> {
   
    private final String description;
    private final T item;
   
    public DisplayInfo(T item) {
        this(item.getClass().getSimpleName(), item);
    }
   
    public DisplayInfo(String description, T item) {
        this.description = Contract.asNotNull(description,
            "description cannot be null");
        this.item = item;
    }
   
    public String getDescription() {
        return description;
    }
   
    public T getValue() {
        return item;
    }
   
}

// define a converter to make the element accessible for binding

public class DisplayInfoConverter<T> extends Converter<DisplayInfo<T>, T> {

    @Override
    public T convertForward(DisplayInfo<T> info) {
        return info.getValue();
    }

    @Override
    public DisplayInfo<T> convertReverse(T item) {
        throw new UnsupportedOperationException();
    }

   
}

// then use for concrete types, f.i. Painter:

   // build  a tree with nodes containing DisplayInfos
        DefaultMutableTreeNode pin = new DefaultMutableTreeNode(
                new DisplayInfo<Painter>(desc, painter));
   ....
   // use a renderer with StringValue which handles DisplayInfo
   painterDemos.setCellRenderer(new DefaultTreeRenderer(
                DisplayValues.DISPLAY_INFO_DESCRIPTION));
  // use a converter parameterized to Painter
   Converter<?, ?> painterConverter = new DisplayInfoConverter<Painter>();
  // and wire all together
   Binding b = Bindings.createAutoBinding(READ,
          painterTree, BeanProperty.create("selectedElement_UNWRAP_NODE")),
          target, BeanProperty.create("painter");
   b.setConverter(painterConverter);
[/code]

works like a charm (and yeah, again thanks to Karl, the demos have a JTreeAdapterProvider :-)

Now the main content (though short, contains lots  of question marks <g>): With all your combined help I recently accepted the general rule: don't mix arrays and generics, so I don't. On the other hand: we have api in swingx classes which ... guess what .. have varargs parameters. Binding barks if it gets a converter like above: it insists on getting an array. So tried a converter analogous to the above

[code]

public class DisplayInfoConverter<T> extends Converter<DisplayInfo<T>, T[]> {

[/code]

but couldn't make it work, gave up early and added concrete converters with concrete types like

[code]
public class AreaEffectInfoConverter extends Converter<DisplayInfo<AreaEffect>,
    AreaEffect[]> {

[/code]

which is okay but not very satisfying. Now the questions

- is there a way to make those generic array converters, how?
- shouldn't we replace all api taking varargs (or arrays) because they don't play with generics?
- any way the binding itself can support it transparently?

Eager for opinions/comments

Jeanette
[Message sent by forum member 'kleopatra' (fastegal@...)]

http://forums.java.net/jive/thread.jspa?messageID=369949

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

[jdnc-interest]

Jeanette,

Glad you are able to make good use of the binding additions that I placed in the demos.  Fabrizio, I did supply the JTree adapter to BB in a bug, you can grab it for BBB, if you like.

So, there are two possibilities for tackling this problem:
1. Use the Aggregator code that I added.  Theorectically, you can aggregate one thing, meaning you can use the already created ArrayAggregator to combine a single info's value into an array.
2. Use the supplied class below.  You cannot get around passing in the class type, the compiler needs to know what to check against and we need that type to reflectively define an array.  (Ugly I know.)  It should do what you need.

[code]import java.lang.reflect.Array;

import org.jdesktop.beansbinding.Converter;
import org.jdesktop.swingx.util.Contract;

/**
 *
 * @author Karl George Schaefer
 */
public class DisplayInfoConverter<T> extends Converter<DisplayInfoConverter<T>, T[]> {
    private Class<T> type;

    public DisplayInfoConverter(Class<T> type) {
        this.type = Contract.asNotNull(type, "type cannot be null");
    }

    /**
     * {@inheritDoc}
     */
    @Override
    @SuppressWarnings("unchecked")
    public T[] convertForward(DisplayInfo<T> info) {
        T[] arr = (T[]) Array.newInstance(type, 1);
        arr[0] = info.getValue();

        return arr;
    }

    /**
     * {@inheritDoc}
     */
    @Override
    public T convertReverse(T[] value) {
        throw new UnsupportedOperationException();
    }

}[/code]

Karl
[Message sent by forum member 'kschaefe' (kschaefe@...)]

http://forums.java.net/jive/thread.jspa?messageID=369960

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

[jdnc-interest]

Karl,

thanks - used option 2 (didn't look yet at your aggregator, will do soon :).

One slight adjustment, though: typically a null value should be mapped to an empty array (instead of one containing the null) -

[code]
    /**
     * {@inheritDoc}
     *
     * Implemented to return an array of length 1 containing the info's element, if not
     * null, empty array otherwise.
     */
    @Override
    public T[] convertForward(DisplayInfo<T> info) {
        if (info.getValue() == null) {
            return empty;
        }
        T[] arr = createArray(1);
        arr[0] = info.getValue();
        return arr;
    }
 

[/code]

CU
Jeanette
[Message sent by forum member 'kleopatra' (fastegal@...)]

http://forums.java.net/jive/thread.jspa?messageID=369968

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

[jdnc-interest]

Jeanette,

> thanks - used option 2 (didn't look yet at your
> aggregator, will do soon :).

Part of the problem with binding is that it is set as one-for-one.  The aggregator takes n-source items and returns an aggregate (Set, List, array, etc.) of the source items and passes it into one target.  I believe that I used it the Highlighter area to bind many different individual highlighters to one highlighters property.  Or perhaps it was predicate....will have to look at that again.

> One slight adjustment, though: typically a null value
> should be mapped to an empty array (instead of one
> containing the null) -

Good call. Probably have the same problem in the aggregator, though that probably wants an option to allow nulls in the aggregate.

Nice work on the demos, by the way.

Karl
[Message sent by forum member 'kschaefe' (kschaefe@...)]

http://forums.java.net/jive/thread.jspa?messageID=370018

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

[Fabrizio Giudici]

jdnc-interest@... wrote:
> Jeanette,
>
> Glad you are able to make good use of the binding additions that I placed in the demos.  Fabrizio, I did supply the JTree adapter to BB in a bug, you can grab it for BBB, if you like.
>  
Read this only now. Did you already pointed it to me? If not, can you
please do now?

--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/people
Fabrizio.Giudici@...


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

[jdnc-interest]

Here's the [url=https://beansbinding.dev.java.net/issues/show_bug.cgi?id=56]original bug[/url] from [url=https://beansbinding.dev.java.net/]Beans Binding[/url].  It points to code that's been mvoed.  Here's the latest location for the JTree selection adapater:

https://swinglabs-demos.dev.java.net/source/browse/swinglabs-demos/trunk/SwingXSet6/swingxset/src/org/jdesktop/swingx/binding/JTreeAdapterProvider.java?rev=1164&view=log

Karl
[Message sent by forum member 'kschaefe' (kschaefe@...)]

http://forums.java.net/jive/thread.jspa?messageID=370682

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

[jdnc-interest]

Fabrizio,

(wrong place to post here, I'm aware, but couldn't find something in bbb itself)

Just wanted to let you know: downloaded the 1.3 release (seems to work fine in swinglabs-demos, cool!) but got a bit confused about the naming of the files

- betterbeansbinding-all contains the binaries
- betterbeansbinding-bin contains the javadoc
- betterbeansbinding-project contains the source

bug or feature (keeping devs alert :-)

CU
Jeanette
[Message sent by forum member 'kleopatra' (fastegal@...)]

http://forums.java.net/jive/thread.jspa?messageID=370840

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