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

[Eddie Bush]

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:   
For additional commands, e-mail: 

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

[Andy Kriger]

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:[EMAIL PROTECTED]]
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:[EMAIL PROTECTED]


--
To unsubscribe, e-mail:

For additional commands, e-mail:




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

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

[Wendy Smoak]

> 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?

I'm not clear on your issue... when would you need a list of *Form* beans?
I'm generally working with a single Form in scope.  (But I don't use
Dyna-anythings yet.)

I don't know if it's an official pattern, but I've heard it called "Custom
Data Transfer Objects".  IOW, if all you're doing is presenting a read-only
page of items, from which the user will pick one and go off and edit it,
then just get the data out and into some format from which it's easy to
display.

I have a 'dto' package which has the beans that are really intended to
transport data in both directions.  Then I have 'dto.custom' in which all
the classes are named with "View" in the name.  These are only for display.
In the custom package, all the dates are just Strings, since I never have to
worry about validating them.  I also put "description" fields in, rather
than just the codes that are stored in the database, because I need to
display things like "NM - No Mail". 

HTH, not sure I'm on the same page though. :)

-- 
Wendy Smoak
Applications Systems Analyst, Sr.
Arizona State University PA Information Resources Management