Skip to end of metadata
Go to start of metadata

A simple taglib to display a bean in a table, à la displaytag, but with one bean instead of a collection, each property being a row instead of a column.

temp notes:

  • if you don't specify any <property>, all properties of the bean are displayed, sorted.
  • if you don't specify any <property> and your bean is an instance of java.util.Map, all String.valueOf(each key) is used as a property name.
  • No labels

1 Comment

  1. Some old doc to be integrated or trashed:
    -----------------------------------------
    After some ideas shared by Jeroen and me, some thinking, some blogging and some DisplayTag? code review, I decided I'd write this tag from scratch.

    (see http://www.incongru.net/space/start/2004-02-12/2#DisplayTag and http://www.incongru.net/space/start/2004-02-14/1#DisplayTag_-_BeanDisplayTag for previous state about this)

    It was written test-first, using HttpUnit?, more specifically ServletUnit?, which supports jsp! (It also supports listeners and filters, at least in cvs)

    I wrote a tiny test framework to test my jsp's, and voilà.

    The tag seems to be working quite well.

    I should do a release soon.

    It needs a little revamping with the way it writes stuff to the output, and how it's configured. For now there's an ugly singleton, which makes it untestable.

    Seems we might be able, by using pico/nanocontainer's servlet extension, to do a nice little design. Something like pico'servletcontextlistener would put a BeanDisplayTagConfig? object in the container, which in turn could be somehow retrieved by the tag, eventhough it's not really pico-isable ....(The configuration would only be possible through pico, maybe, but I'd consider that being ok. To be checked, anyway)

    Or we could have a custom servletcontextlistener specific for the tag, which would put a config object in the application context? That actually seems cleaner, in the sense that it does not create an extra dependency on pico (which is not used in any other way by this tag, and probably won't), and the listener would be only declared in the tld.

    For this, we need to check if listeners declared in tld's are loaded in any case, or only when they're located in the standard WEB-INF/tld (especially since I prefer to leave the tld in the jar file under META-INF/taglib.tld)

    – Main.gj - 17 May 2004