WebWork-2.2 and Generics

October 30, 2005 on 6:04 pm | In Technical stuff | No Comments

I’m working on a settings screen (using JSP) which iterates over a Map of generic SettingEntries. A SettingEntry is defined as follows:

public class SettingEntry <T> implements Serializable {

private final String key;
private final T defaultValue;
private T value;

// Ctor, getters and setters removed for brevity's sake
}/code>

When a user enters a new value, ideally the form value should be converted to the correct type. For example, “board.size” was created as a SettingEntry <Integer>. Ideally XWork/WebWork's type conversion should set the value as a new Integer. However, this is not the case. Instead, a String[] array (WW's default type for form parameters), of length one is set as the value.

Java's implementation of generics does not create a new class based on a class template. Instances of a generic class have the same run-time class. So, the following lines will both print true:

System.out.println(new HashSet<String>().getClass() == new HashSet<String>().getClass());
System.out.println(new HashSet<String>().getClass() == new HashSet<Integer>().getClass());

Well, after looking through a piece by Gilad Bracha, I made SettingEntry<T> aware of its type, in a generic way. I added a generic instance of the targetClass to SettingEntry, and then I could at least check that the T value being set on the SettingEntry instance is the same Class that the class was initially made with. Now, I can just make a converter which will create new instances based on the targetClass.

Currently, XWork-Tiger allows for a collection’s generic type to be used, rather than the developer defining the element types, and the key for maps in a conversion property file. Although this is a specific use case (iterating over a map of generic settings), I think the new XWork-Tiger module could benefit from this. It should allow for users to define a target Class, which XWork could later use to provide new instances, or at least properly cast existing references.

Context-sensitive menu using WebWork

October 14, 2005 on 9:54 am | In Technical stuff | 1 Comment

Looking to build a generic context-sensitive menu using WebWork. Came up with the following requirements:

  • All items described below are menu elements.
  • A menu element has a name attribute.
  • A menu element has a parent menu element.
  • If a menu element does not have a parent, it is the root menu.
  • A menu element is only aware of its structural representation, i.e.: it’s a model.
  • A menu may be composed of other menus.
  • There is only one root menu.
  • The root menu has a default menu set.
  • The default menu is shown if the current use case does not provide a menu.
  • There is a mechanism to change the current menu based on the current use case.
  • A menu may have child menu items.
  • A menu item has an action attribute. The view will rely on this to react to a menu item being selected or clicked. This action may be a URL or script call.

The visual representation of the menu elements above could be as simple (html) or complex (Ajax/DHTML) as the end user wants. As a default, you could use a simple html output. The output would basically output the root menu’s immediate children. While displaying a menu item, the cell/div would be clickable. Its onclick would either send the user to a given URL, or execute a given script call.

In terms of setting the menu based on the current context, an interceptor requesting the desired root menu seems enough. For example, FooAction would implement MenuProvider. A MenuProvider would return its desired root menu. If FooAction wanted to modify the existing root menu, rather than completely replacing it, it would implement MenuAware. The same aforementioned interceptor would set the root menu on MenuAware classes.

Constructive suggestions appreciated.

Powered by WordPress with Pool theme design by Borja Fernandez.
Entries and comments feeds. Valid XHTML and CSS. ^Top^