Un caso de uso bastante común se produce cuando hay una lista de objetos Java, desde la cual se pueden hacer selecciones en un formulario web; generalmente usaría la clave primaria del object como el valor para que el controlador pueda realizar una búsqueda, o simplemente vincular la clave a cualquier objeto creado/actualizado.Spring MVC - Selección de objetos desplegables - Sin identificador primario
Mi problema es que la lista para elegir no son persistentes, los objetos con clave, son modelos comerciales de un servicio que no tienen forma razonable de recuperarlos en función de los datos contenidos. A continuación se muestra un código psuedo donde se le da una lista de Foo a la página, y podemos comunicarnos fácilmente con el controlador en Enviar el nombre de Foo, pero ¿qué ocurre si hay otros campos de Foo que se deben enviar?
controlador:
referenceData() {
...
List foos = fooService.getFoosForBar(bar)
return { 'foos', foos }
}
jsp:
<form>
...
<spring:bind path="formData.foo">
<select name="<c:out value="${status.expression}" />">
<c:forEach items="${foos}" var="foo">
<option value="<c:out value="${foo.name}"/>">
<c:out value="${foo.name}"/>
</option>
</c:forEach>
</select>
</spring:bind>
...
</form>
Algunos ejemplos de soluciones sería utilizar campos ocultos a presentar otras propiedades de Foo y mantenerlos sincronizados como la selección se cambia, pero yo prefiero no usar JavaScript en una situación como esta donde probablemente agregará confusión. Sin duda, hay otras maneras de lograr esto también.
Mi pregunta es, ¿existe alguna práctica estándar para lograr esto? ¿O debería crear mi propio modo de hacerlo? Prefiero no volver a inventar las ruedas si es posible, y esto es tan común que simplemente volar no puede ser el mejor enfoque.
Utilicé este enfoque al registrar una carpeta personalizada en el controlador para pasar de la cadena al objeto representativo (que es el centralizado código que sugiere dwb). – Nate