Usecases for ModelDriven interface

[Unmesh joshi <un...@hotmail.com>]

Hi, 


I am using struts2 on my current project and find ModelDriven interface very inconvenient. The intent of the interface is documented as, "it helps directly populating domain model". But if the domain model is little more complex than a simple bean, it becomes very inconvinient. e.g.

If my domain model is as follows

class Order {
String orderNumber;
UserInformation user;
}

class UserInformation {
String firstName;
String lastName;
Address address;
}

class Address {
String addressLine1;
String city;
String state;
}

The problem with ModelDriven is that I have to use OGNL expressions like user.address.addressLine1 in my HTML form. While this is not a bigger issue for the simple example as above, it can be awkward for little more complex domain models. What suits better for those domain models is to have a builder, which has setters for all the parameters on the form and has responsibility to build the actual domain model objects. Something like following

class OrderBuilder {
String orderNumber;
String firstName;
String lastName;
String addressLine1;
String city;
String state;
 
public Order build() {
  ......
} 
}


I can offcourse use this builder as Model, fooling struts framework like following

class MyAction imeplements ModelDriven<OrderBuilder> {
private OrderBuilder builder;
public OrderBuilder getModel() {

builder = new OrderBuilder();
return builder; 
}

public void execute() {
orderBuilder.build(); // Then use order
}
}
But I think this reads very badly. Instead, will it make more sense to have a annotation for "parameter mapping strategy"? Something like

Instead of
class MyAction implements ModelDriven<Order>

have following

@BeanMappingStrategy(beanName="order") //expects OGNL in parameter names to map to bean
class MyAction {
  Order order;
}

or 

@BuilderMappingStrategy(builderName="oderBuilder") // knows that its dealing with builder, so will call build method.
class MyAction {
OrderBuilder orderBuilder;
}

What do you guys think?

Thanks,
Unmesh

_________________________________________________________________
Drag n’ drop—Get easy photo sharing with Windows Live™ Photos.

http://www.microsoft.com/india/windows/windowslive/photos.aspx

RE: Usecases for ModelDriven interface

[Martin Gainty <mg...@hotmail.com>]

I think what you're looking for is a more flexible Mapping which can be achieved via Spring

http://static.springsource.org/spring/docs/2.5.x/api/org/springframework/web/servlet/DispatcherServlet.html

which would enable you to define your own DefaultAnnotationHandlerMapping
http://static.springsource.org/spring/docs/2.5.x/api/org/springframework/web/servlet/mvc/annotation/DefaultAnnotationHandlerMapping.html
 <bean  class="org.springframework.web.servlet.mvc.annotation.DefaultAnnotationHandlerMapping">
   <property name="interceptors">
     ...
   </property>
 </bean>If your annotated class is a Web Controller then you can use Controller.htm
http://static.springframework.org/spring/docs/2.5.x/api/org/springframework/stereotype/Controller.html//Once your spring framework is achieved you can implement RequestMapping
http://static.springframework.org/spring/docs/2.5.x/api/org/springframework/web/bind/annotation/RequestMapping.html
where
Annotation for mapping web requests onto specific handler classes and/or
 handler methods. Provides consistent style between Servlet and Portlet
 environments, with the semantics adapting to the concrete environment.

 

so as you can see there is alot of flexibility with Handlers,Annotations and Controller available with Spring
Martin 
______________________________________________ 
Disclaimer and Confidentiality/Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
This message is confidential. If you should not be the intended receiver, then we ask politely to report. Each unauthorized forwarding or manufacturing of a copy is inadmissible. This message serves only for the exchange of information and has no legal binding effect. Due to the easy manipulation of emails we cannot take responsibility over the the contents.
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni.




> From: unmesh_joshi@hotmail.com
> To: user@struts.apache.org
> Subject: Usecases for ModelDriven interface
> Date: Tue, 5 May 2009 17:47:09 +0000
> 
> 
> Hi, 
> 
> 
> I am using struts2 on my current project and find ModelDriven interface very inconvenient. The intent of the interface is documented as, "it helps directly populating domain model". But if the domain model is little more complex than a simple bean, it becomes very inconvinient. e.g.
> 
> If my domain model is as follows
> 
> class Order {
> String orderNumber;
> UserInformation user;
> }
> 
> class UserInformation {
> String firstName;
> String lastName;
> Address address;
> }
> 
> class Address {
> String addressLine1;
> String city;
> String state;
> }
> 
> The problem with ModelDriven is that I have to use OGNL expressions like user.address.addressLine1 in my HTML form. While this is not a bigger issue for the simple example as above, it can be awkward for little more complex domain models. What suits better for those domain models is to have a builder, which has setters for all the parameters on the form and has responsibility to build the actual domain model objects. Something like following
> 
> class OrderBuilder {
> String orderNumber;
> String firstName;
> String lastName;
> String addressLine1;
> String city;
> String state;
>  
> public Order build() {
>   ......
> } 
> }
> 
> 
> I can offcourse use this builder as Model, fooling struts framework like following
> 
> class MyAction imeplements ModelDriven<OrderBuilder> {
> private OrderBuilder builder;
> public OrderBuilder getModel() {
> 
> builder = new OrderBuilder();
> return builder; 
> }
> 
> public void execute() {
> orderBuilder.build(); // Then use order
> }
> }
> But I think this reads very badly. Instead, will it make more sense to have a annotation for "parameter mapping strategy"? Something like
> 
> Instead of
> class MyAction implements ModelDriven<Order>
> 
> have following
> 
> @BeanMappingStrategy(beanName="order") //expects OGNL in parameter names to map to bean
> class MyAction {
>   Order order;
> }
> 
> or 
> 
> @BuilderMappingStrategy(builderName="oderBuilder") // knows that its dealing with builder, so will call build method.
> class MyAction {
> OrderBuilder orderBuilder;
> }
> 
> What do you guys think?
> 
> Thanks,
> Unmesh
> 
> _________________________________________________________________
> Drag n’ drop—Get easy photo sharing with Windows Live™ Photos.
> 
> http://www.microsoft.com/india/windows/windowslive/photos.aspx

_________________________________________________________________
Hotmail® has ever-growing storage! Don’t worry about storage limits.
http://windowslive.com/Tutorial/Hotmail/Storage?ocid=TXT_TAGLM_WL_HM_Tutorial_Storage1_052009