Domain objects as form objects with nested relationships

[rob_from_ca]

Pardon me if I've overlooked something; I'm still trying to wrap my head around all of spring, and a quick search of the forums didn't turn up exactly what I was looking for.

I like the idea of avoiding basically useless VTO/DTO's, so I'm using domain objects (which are persisted w/Hibernate) as the command/backing objects for my forms. My question is where should relationships be resolved and loaded from the string parameters.

For example I've got an "Image" class, which as a photographer property whose type is my Photographer class. The image additon form asks for the photographer, as a string. I'm using the velocity bind macros, and predictably enough when I submit an additon form, it gives an error message like this on validation:

Failed to convert property value of type [java.lang.String] to required type [Photographer] for property 'photographer'

No problem, I understand where it comes from.

My plan is to just validate for format in the validator (valid string, no spaces, etc), then in the controller, lookup the photographer via the business interface and if it's not found add the error to the model and pass it back to that page.

However, can I still use the the straight domain object as the command object? There's no place to store/validate the basically temporary photographer "key string". I can think of a few things, but they feel like hacks and it seems obvious that there must be a spring-like way of doing things...Would this be a good place for a property editor?

[katentim]

Would this be a good place for a property editor?

I think so - see below.

Failed to convert property value of type [java.lang.String] to required type [Photographer] for property 'photographer'

If your Photographer class is naturally able to be represented as a single String (e.g. "Name" or "Surname, Firstname"), register a custom property editor for the Photographer class.

can I still use the the straight domain object as the command object?

Yes.

[rob_from_ca]

I found a fairly complete description of a very similar question:

http://forum.springframework.org/showthread.php?t=9845

However, is it really the intention that this sort of thing get done in a property editor? My "photographer" can't be -completely- represented by a String; just enough to perform a lookup. So following some of this advice, In the property editor I'd either

a) Create a new, empty photographer and just set the logical key property supplied, then pull that out later to query for and load the real photographer object from the database, or

b) Actually do the lookup from the database in the property editor.

"A" seems better to me, because "B" feels like it pushes property editors a little too far. I don't know if it's a correct inference or not, but it seems that property editors are intended to be more about type conversion that doing real work. Looking up an object from a database seems like too much work. Although, I guess it get a reference to the business logic routine wired up by spring; that wouldn't be too bad.

[ojolly]

The idea of doing a lookup in the property editor isn't a bad idea. Considering that hibernate has a 2nd level cache which can be used to make this db lookup a simple reference fetching in the same jvm, the overhead at runtime is acceptable and the transparency of getting a full object given its string representation is worth some more complexity in the property editor.

Olivier

[katentim]

If you Photographer class can't be converted naturally and completely to a String (like from a single HTML text form field), I wouldn't use a property editor.

My plan is to just validate for format in the validator (valid string, no spaces, etc), then in the controller, lookup the photographer via the business interface and if it's not found add the error to the model and pass it back to that page.

Given that your Photographer class can't be completely re-constructed from a String, you suggested approach above is probably the best.

[rob_from_ca]

One for, one against. :-)

At first I avoided the propertyeditor because I was probably going to end up needing quite a few, and wiring them all up with their application facade reference sounded tedious. But then I created a constructor that sets up that reference, and it was easy to pass it from the controller to the editor when setting it in initBinder:

binder.registerCustomEditor(Photographer.class, null, new PhotographerEditor(imageApplication));

So that seemed rather nice. The bean spec seems to imply that the as the most recent poster says, that the representations should be completely convertible from one format to another, which is why I was afraid it was bending it too far. Although the string in question is a logical, user exposed key field so it should always return a full photographer (or nothing if that photographer doens't exist; I suspect that's where the problem likes; I get the impression property editors aren't really supposed to have a lot of failure modes).

Of course, half the bean spec talks about graphic editing of bean properties and linkages to the AWT, so maybe it's not all that relevant anymore...

This form is complicated enough that I think I might just implement a dedicated command object for it and fix everything up in the controller, but that still feels more struts-like than spring-like.

[katentim]

I might just implement a dedicated command object for it and fix everything up (do the lookup) in the controller

That's a scenario common to web applications, not just Struts or Spring.

Another approach would be to have a select list of Photographers (see referenceData method), or a search for photographers on a previous or subsequent web-page. Then you know the photographer key is valid.

[ryan.tyer]

I am encountering this same problem. I have a need to set a location object to a user.

I load a list of users in my reference data method and then in the jsp have:

<spring&#58;bind path="command.location">
	<label for="location" accesskey="l">
		<span class="underline">L</span>ocation&#58;<span class="error"><c&#58;out value="$&#123;status.errorMessage&#125;" /></span>
		<select id="location" name="location" title="Select the location">
		<c&#58;forEach var="location" items="$&#123;requestScope.locations&#125;">
			<option value="<c&#58;out value="$&#123;location.id&#125;"/>"><c&#58;out value="$&#123;location.name&#125;"/></option>
		</c&#58;forEach>
		</select>
	</label>
</spring&#58;bind>

I have not done anything with property editors as my location objects are a lot more complex than simple string representation. I need to either get the item selected from the list and set it, or do a database lookup for the object. I'm at a loss on how to set this field.

[mmcintos]

Back to the original question, I'm also using domain objects directly as form backing objects in a small application. If my "Group" object may have a "contact" member of type Person that could legitimately be null, what's the simplest way to avoid NullValueInNestedPathException in my JSP? Is there a straightforward use of <spring:bind> that I'm missing?

Or am I forced to choose between creating an empty Person object that I throw away and manufacturing a new Group-like object just for use in this view?