Avoiding UI-centric Domain Classes

[dhainlin]

I have a question about what others are doing to avoid UI-centric features creeping into their domain classes. First a little setup.

I am really digging the way this framework allows easy use of domain classes in UI layers. The one area I have struggled with architecturally is when UI-centric stuff needs to be added to support something like multiple selection lists or date ranges. I'd like my domain classes to be more logically pure. When faced with this in the past few apps, I used to simply slam this support directly into the domain but this seems wrong. Now what I've started doing is to create a UI-centric decorator for a domain class that needs additional UI 'features'. An example might help explain what I'm getting at...

Assume we have a domain Widget

package abc.domain;
public class Widget
{
  private String name = null;
  private List cogs = null;

  public Widget()
  {
  }

  public String getName()
  {
    return name;
  }
  public List getCogs()
  {
    if (cogs == null) {
      cogs = new ArrayList();
    }
    return cogs;
  }
...
}

Because I know I'm going to extend this (below), I go ahead and refactor my domain class by creating an interface and renaming the concrete class as shown:

package abc.domain;
public interface Widget
{
  String getName();
  void setName(String val);
  List getCogs();
  void setCogs(List val);
}

public class WidgetImpl implements Widget
{
  ...
}

I need to now provide a widget edit controller that allows 0 to many cogs to be added to a widget via a multiple selection list. A common way to do this is to provide a referenceData handler to populate a list of selections (e.g. "selectedCogs")The list contains SelectionOption instances (a pojo class that has name, value and a boolean indicating if it is selected) and is built by adding all available cogs to be selected and then marking those as selected if they are found in the widget.cogs list.

The view (jsp in this case) uses this reference list to build the select/option dynamically. The select is bound to a new ui-centric form attribute called something like cogIds which is a String. When the form binds (during a POST), any option that is selected is passed to the cogIds as a comma delimited list.

To make this work, I decorate/extend Widget like this

package abc.ui.forms;
import abc.domain.Widget;

public class WidgetForm implements Widget
{
  private Widget delegate = null;

  public WidgetForm(Widget val)
  {
    super();
    delegate = val;
  }

  public String getName()
  {
    return delegate.getName();
  }
  ...
  // UI methods
  public void setCogIds(String val)
  {
    delegate.setCogs(functionToSplitStringIdsIntoCogList(val));
  }
         
}

The jsp code fragment might look like

<spring&#58;bind path="command.cogIds">
<label><fmt&#58;message key="label.$&#123;status.expression&#125;" /></label>
<select multiple name="$&#123;status.expression&#125;">
<c&#58;forEach items="$&#123;assignedCogs&#125;" var="selectionOption">
  <option <c&#58;if test="$&#123;selectionOption.selected&#125;"> selected </c&#58;if> value="$&#123;selectionOption.value&#125;">
  $&#123;selectionOption.name&#125;
  </option>
</c&#58;forEach>
</select>
<br/>
</spring&#58;bind>

The controller now simply provides a WidgetForm instance. The DomainForm is responsible for translating the UI-centric info into Domain-centric info.

The net result is my domain's retain some logic purity (which is a bonus if I provide access to them via remoting for example) but it is somewhat messy to wrap a complex domain class inside a ui form. I'm also not a fan of domain interfaces in general. This also works well with input parameters to iBatis sql maps (they can be told the input is the interface) which allows them to work from a pure domain context but be provided UI-centric extensions.

While I'm currently doing this via brute-force (my decorated ui form class delegates all calls manually) but am thinking of building a base class that will provide auto-magic reflection based decoration/delegation. Does this seem like a reasonable approach? Other thougts?

BTW, I know it would be simpler to provide a ui form that simply has the domain as an attribute rather than extending it but I didn't want to the UI views to be aware of the extension.

${command.widget.name}
and
${command.cogIds}

[Asya]

I might not understand something but if you use command Controllers would not they perform UI functions for you, like splitting ids into list.

[Colin Yates]

You need to use PropertyEditors, so your form would have a setCogs(Cog[] cogs) method.

Then create a PropertyEditor that converts to and from a Cog[] to a String[] of ids. Register this propertyEditor for the Cog[] class in initDataBinder.

Then in your jsp you will get a Cog[] when binding to command.cogs.

Hope this helps.

Note: If you decide to specify a Set of cogs, then you can do this, but obviously don't register your propertyEditor against a Set.class Register it against the field name.

[Bubba Puryear]

Maybe I'm being dense... I'm having some trouble setting up what yatesco suggests. I don't have Cogs, but I do have SelectableMarkers. Anyhow - I have an entity class - a QcRequest. A QcRequest has a list of child SelectableMarker's. I'm using FreeMarker (love it, btw - I hope to never touch a JSP again, ever) and have my wonderful little property editor. Seems, though, that the property editor is converting the list to a string (as in editor.getAsText()) and is driving the checkbox macro nuts. Here's the relavent code and such:

public class QcRequest {
  private int pk;
  ...
  private List<SelectableMarker> bacterialSelectableMarkers;

  ... various getters/setters and few methods that 'do stuff'
&#125;

public class SelectableMarker &#123;
  private int pk;
  private String marker;
  private String abbreviation;

  ... again with the getter/setters
&#125;

And a property editor:

public class SelectableMarkerListEditor extends PropertyEditorSupport {
  private Map<String, SelectableMarker> selectableMarkerMap;

  public SelectableMarkerListEditor&#40;List<SelectableMarker> markerList&#41; &#123;
    this.selectableMarkerMap = new HashMap<String, SelectableMarker>&#40;markerList.size&#40;&#41;&#41;;
    for &#40;SelectableMarker marker &#58; markerList&#41; &#123;
      this.selectableMarkerMap.put&#40;Integer.toString&#40;marker.getPk&#40;&#41;&#41;, marker&#41;;
    &#125;
  &#125;


  public void setAsText&#40;String text&#41; &#123;
    String&#91;&#93; keys = text.split&#40;","&#41;;
    List<SelectableMarker> markers = new ArrayList<SelectableMarker>&#40;keys.length&#41;;

    for &#40;int i=0; i<keys.length; ++i&#41; &#123;
      markers.add&#40;selectableMarkerMap.get&#40;keys&#91;i&#93;.trim&#40;&#41;&#41;&#41;;
    &#125;

    setValue&#40;markers&#41;;
  &#125;
&#125;

The relevant bit of the freemarker template that renders the control (er, blows up spectacularly - more on that below):

      <tr>
        <td><@genie.label "form.label.selectableMarkers"/></td>
        <td><@spring.formCheckboxes path="request.bacterialSelectableMarkers"
                                    options=selectableMarkers
                                    separator="<br/>"/>
             <@spring.showErrors separator="<br/>" classOrStyle="error"/>
        </td>
      </tr>

The code that populates the view model with the list o' available markers:

... from the relevant referenceData() override. (Spring MVC - good times)

    Map<String, Object> model = new HashMap<String, Object>&#40;&#41;;
    model.put&#40;"selectableMarkers", viewListService.getSelectableMarkerMap&#40;&#41;&#41;;
    return model;

... the interface for the viewListService&#58;

public interface ViewListService &#123;
  public Map<String, String> getVectorTypeMap&#40;&#41;;
  public Map<String, String> getSelectableMarkerMap&#40;&#41;;
&#125;

and, of course, registering the property editor:

  @Override protected void initBinder(HttpServletRequest request, ServletRequestDataBinder binder) {
    binder.registerCustomEditor(List.class, "bacterialSelectableMarkers",  new SelectableMarkerListEditor(selectableMarkerService.getMarkers()));
  }

Ok, so that all looks fine to me. Problem is, it blows up. Not so good. Here's the lovely stack trace:

freemarker.template.TemplateException: Expected collection or sequence. list evaluated instead to freemarker.template.SimpleScalar on line 300, column 16 in spring.ftl.
	freemarker.core.TemplateObject.invalidTypeException(TemplateObject.java:135)
	freemarker.core.IteratorBlock$Context.runLoop(IteratorBlock.java:183)
	freemarker.core.Environment.visit(Environment.java:351)
	freemarker.core.IteratorBlock.accept(IteratorBlock.java:95)
	freemarker.core.Environment.visit(Environment.java:196)
	freemarker.core.MixedContent.accept(MixedContent.java:92)
	freemarker.core.Environment.visit(Environment.java:196)
	freemarker.core.Macro$Context.runMacro(Macro.java:164)
	freemarker.core.Environment.visit(Environment.java:537)
	freemarker.core.MethodCall._getAsTemplateModel(MethodCall.java:105)
	freemarker.core.Expression.getAsTemplateModel(Expression.java:89)
	freemarker.core.Assignment.accept(Assignment.java:91)
	freemarker.core.Environment.visit(Environment.java:196)
	freemarker.core.MixedContent.accept(MixedContent.java:92)
	freemarker.core.Environment.visit(Environment.java:196)
	freemarker.core.IteratorBlock$Context.runLoop(IteratorBlock.java:160)
	freemarker.core.Environment.visit(Environment.java:351)
	freemarker.core.IteratorBlock.accept(IteratorBlock.java:95)
	freemarker.core.Environment.visit(Environment.java:196)
	freemarker.core.MixedContent.accept(MixedContent.java:92)
	freemarker.core.Environment.visit(Environment.java:196)
	freemarker.core.Macro$Context.runMacro(Macro.java:164)
	freemarker.core.Environment.visit(Environment.java:537)
	freemarker.core.UnifiedCall.accept(UnifiedCall.java:128)
	freemarker.core.Environment.visit(Environment.java:196)
	freemarker.core.MixedContent.accept(MixedContent.java:92)
	freemarker.core.Environment.visit(Environment.java:196)
	freemarker.core.Environment.process(Environment.java:176)
	freemarker.template.Template.process(Template.java:231)
	org.springframework.web.servlet.view.freemarker.FreeMarkerView.processTemplate(FreeMarkerView.java:267)
	org.springframework.web.servlet.view.freemarker.FreeMarkerView.doRender(FreeMarkerView.java:221)
	org.springframework.web.servlet.view.freemarker.FreeMarkerView.renderMergedTemplateModel(FreeMarkerView.java:180)
	org.springframework.web.servlet.view.AbstractTemplateView.renderMergedOutputModel(AbstractTemplateView.java:160)
	org.springframework.web.servlet.view.AbstractView.render(AbstractView.java:250)
	org.springframework.web.servlet.DispatcherServlet.render(DispatcherServlet.java:928)
	org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:705)
	org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:625)
	org.springframework.web.servlet.FrameworkServlet.serviceWrapper(FrameworkServlet.java:386)
	org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:355)
	javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
	javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
	net.sf.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:292)
	net.sf.acegisecurity.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:84)
	net.sf.acegisecurity.intercept.web.SecurityEnforcementFilter.doFilter(SecurityEnforcementFilter.java:182)
	net.sf.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:303)
	net.sf.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:154)
	net.sf.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:303)
	net.sf.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:311)
	net.sf.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:303)
	net.sf.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:215)
	net.sf.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:303)
	net.sf.acegisecurity.securechannel.ChannelProcessingFilter.doFilter(ChannelProcessingFilter.java:168)
	net.sf.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:303)
	net.sf.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:173)
	net.sf.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:125)

which just says that this line here is blowing up: (if you don't know freemarker macro syntax, don't worry -- it's all pretty easy)

<#function contains list item>
	<#list list as nextInList>                         <--- line 300
	<#if nextInList == item><#return true></#if>
	</#list>
	<#return false>
</#function>

which is being called by this:

<#macro formCheckboxes path options separator attributes="">
	<@bind path/>
	<#list options?keys as value>
	<#assign isSelected = contains&#40;spring.status.value?default&#40;&#91;""&#93;&#41;, value&#41;>                       <---- which is being called here. 
	<input type="checkbox" name="$&#123;spring.status.expression&#125;" value="$&#123;value&#125;"           ---- 'spring.status.value?default&#40;&#91;""&#93;&#41;' is a scalar?!
		<#if isSelected>checked="checked"</#if> $&#123;attributes&#125;                                        
	<@closeTag/> 
	$&#123;options&#91;value&#93;&#125;$&#123;separator&#125;
	</#list>
</#macro>

So, basically spring.status.value (ie, the current binding's value) is coming up as a scalar instead of as a sequence or list. In fact, if I comment out the call to the checkbox macro, call bind directly and print out the value of ${spring.status.value} - I get a lovely string-representation of my list. Which makes me think that the property editor is being applied to the property of the bean (bacterialSelectableMarkers) and the string value that the property editor is returning is being used by spring.status.value instead of the list value of the property. Which makes the macro bomb when it tries to apply a list function to it.

Am I crazy, or did I forget to do something?

Any help would be greatly appreciated......

[Colin Yates]

The problem is that the property editor shouldn't convert from a List to a string and back, it should convert from a single item (Cog or SelectableMarker).

Spring will handle the "array" bit by choosing the appropriate (i.e. your) property editor to handle each element of the array. You register your PE against the class (SelectableMarker) and Spring will handle the array, not the List.class as Spring knows how to handle Lists or arrays etc.

In your jsp/template if you want to display a list of selectableMarkers then you just bind on your property ${form.bacterialSelectableMarkers}.

If you want to display all markers and preselect the chosen ones you will need to stick all the chosen ones in a map (have your form return a map as well) and during iteration, check the map.

Hope this helps.

[Bubba Puryear]

It did. Sorry for not saying so months earlier. I was just noticing some of my ealier posts.