You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Rick Reumann <ma...@reumann.net> on 2002/12/12 19:16:37 UTC

Best way to handle this in Struts/MVC ?

For all of my forms I have an appropriate DynaValidatorForm bean
defined in my struts-config file. This form eventually populates a
bean (Data Transfer Object) that corresponds to the form bean but with
the correct data types (ie java.util.Date birthDate vs String
birthDate ).

The question I have is when generating a List to display the beans is
it really that bad to use the actual Data Transfer objects beans in
the display (vs a List of the DynaFormBeans)? The reason I ask is it
seems like a lot of overhead to convert a Collection of data transfer
objects into a whole new collection of DynaFormBeans, especially if
the List is quite large. The problem though is if you use the DTOs you
have to code in those beans proper formats for displaying such things
as Dates.

How do others handle this situation?

Thanks,

-- 

Rick
mailto:maillist@reumann.net


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Best way to handle this in Struts/MVC ?

Posted by Eddie Bush <ek...@swbell.net>.
The JSTL offers formatting tags ... and it is a standard.  Requires 
Servlet Spec 2.3.

Rick Reumann wrote:

>On Thursday, December 12, 2002, 1:43:49 PM, Andy wrote:
>
>AK> I put data storage beans that need to be displayed into the
>AK> request or session and use bean:write and logic:iterate on the
>AK> JSP. I don't see the sense in creating extra objects targeted to
>AK> display; just keeping the get/set methods generic (return a Date,
>AK> not a formatted Date String) should be enough.
>
>    That's normally exactly what I do as well. I just heard all this
>    about not having your business objects end up in the presentation
>    layer so I was concerned about the danger. I guess if this
>    business object was an EJB that persisted on another server there
>    could be problems but I'm not in that scenario, although I do want
>    to do things "to standard" (whatever that is:)
>    
>AK> For date formatting, I use the datetime custom tags for dates
>AK> (http://jakarta.apache.org/taglibs/doc/datetime-doc/intro.html) - a caveat
>AK> the format tag uses long values so if your obj has a method Date getDate()
>AK> the property in the tag should be "date.time" (which will call the Date
>AK> obj's getTime() method that returns a long).
>
>    Cool. I'll have to check that out.  Thanks.
>
>  
>

-- 
Eddie Bush





--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re[2]: Best way to handle this in Struts/MVC ?

Posted by Rick Reumann <ma...@reumann.net>.
On Thursday, December 12, 2002, 1:43:49 PM, Andy wrote:

AK> I put data storage beans that need to be displayed into the
AK> request or session and use bean:write and logic:iterate on the
AK> JSP. I don't see the sense in creating extra objects targeted to
AK> display; just keeping the get/set methods generic (return a Date,
AK> not a formatted Date String) should be enough.

    That's normally exactly what I do as well. I just heard all this
    about not having your business objects end up in the presentation
    layer so I was concerned about the danger. I guess if this
    business object was an EJB that persisted on another server there
    could be problems but I'm not in that scenario, although I do want
    to do things "to standard" (whatever that is:)
    
AK> For date formatting, I use the datetime custom tags for dates
AK> (http://jakarta.apache.org/taglibs/doc/datetime-doc/intro.html) - a caveat
AK> the format tag uses long values so if your obj has a method Date getDate()
AK> the property in the tag should be "date.time" (which will call the Date
AK> obj's getTime() method that returns a long).

    Cool. I'll have to check that out.  Thanks.

-- 
Rick


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


RE: Best way to handle this in Struts/MVC ?

Posted by Andy Kriger <ak...@greaterthanone.com>.
I put data storage beans that need to be displayed into the request or
session and use bean:write and logic:iterate on the JSP. I don't see the
sense in creating extra objects targeted to display; just keeping the
get/set methods generic (return a Date, not a formatted Date String) should
be enough.

For date formatting, I use the datetime custom tags for dates
(http://jakarta.apache.org/taglibs/doc/datetime-doc/intro.html) - a caveat
the format tag uses long values so if your obj has a method Date getDate()
the property in the tag should be "date.time" (which will call the Date
obj's getTime() method that returns a long).

For number formatting, I use my own custom tag (that wraps
java.text.DecimalFormat).

-----Original Message-----
From: Rick Reumann [mailto:maillist@reumann.net]
Sent: Thursday, December 12, 2002 13:17
To: Struts List
Cc: model struts
Subject: Best way to handle this in Struts/MVC ?


For all of my forms I have an appropriate DynaValidatorForm bean
defined in my struts-config file. This form eventually populates a
bean (Data Transfer Object) that corresponds to the form bean but with
the correct data types (ie java.util.Date birthDate vs String
birthDate ).

The question I have is when generating a List to display the beans is
it really that bad to use the actual Data Transfer objects beans in
the display (vs a List of the DynaFormBeans)? The reason I ask is it
seems like a lot of overhead to convert a Collection of data transfer
objects into a whole new collection of DynaFormBeans, especially if
the List is quite large. The problem though is if you use the DTOs you
have to code in those beans proper formats for displaying such things
as Dates.

How do others handle this situation?

Thanks,

--

Rick
mailto:maillist@reumann.net


--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>