I realize that having an ActionForm and a POJO with the same getters/setters is ridiculous, but please bear with me for this example. I have a Form and a POJO with Strings, Longs and Dates. The Longs and the Dates get converted into Strings when I get the data from the database using BeanUtils.copyProperties. This works great.
BeanUtils.copyProperties(userForm, user);
However, when going back, it's a different story - here's the ugly way:
SimpleDateFormat format = new SimpleDateFormat("yyyy-MM-dd");
Date dateChanged = format.parse(userForm.getDateChanged());
Date dateCreated = format.parse(userForm.getDateCreated());
user = new User(userForm.getUserId(), userForm.getPassword(),
Long.valueOf(userForm.getDesktopId()),
Long.valueOf(userForm.getCubeId()),
userForm.getCreatedBy(), dateCreated,
userForm.getChangedBy(), dateChanged);
While this works, it's ugly and a pain. I want something like the ActionForm-Value Object mapper. This mapper allows you to easily copy properties between VOs (or Hibernate Objects) and Forms, and vise-versa.
vo = FormToVOMapper.map(form, new ExampleVO());
So I could do something as simple as user = FormToVOMapper.map(userForm, new User()); I like this mapper and I used it on my last project, where it works great. However, I get the feeling that developers in the Struts Community are using something better - and I want to use it. So please, tell me what it is and lets figure out the best way to do this. Another method I've used in the past is to set the VO (or object) on the form itself, allowing for setting of Strings without copying - and setting dates on the form, to be manipulated by the setter. This framework worked great, and I was actually the happiest with it out of any of the above. Chime in and give me your opinions!
I am wondering about a few things, so thought I'd try and get some help from the best source I know - the java.blogs community. First, an update on last night. I experienced some difficulty with Hibernate (persisting child objects) and Struts (nightly build doesn't quite work right with Tiles and Modules) and gave up at 2:00 a.m. Luckily, my head cleared up this morning after a deep 4 hours of sleep and I figured out Hibernate and it appears that a fix for the Tiles/Modules problem was checked into CVS by Cedric.
Now I'm wondering if it's possible to use declared exceptions in Struts to grab all your Exceptions from the bottom up. I can do this in an Action (or even a filter) using the following:
// caught exception e
ActionErrors errors = new ActionErrors();
errors.add(ActionErrors.GLOBAL_ERROR,
new ActionError("errors.general"));
while (e != null) {
errors.add(ActionErrors.GLOBAL_ERROR,
new ActionError("errors.detail", e.getMessage()));
e = (Exception) e.getCause();
}
request.setAttribute(Globals.ERROR_KEY, errors);
Can I do this with declared exceptions? Man that would be sweet if I could - I wouldn't have to have any exception handling in my Actions. Maybe that's the easy way out, but it also makes for rapid development - and you can always add them in when you really want them. Two other things I need to do.
- I have a
java.util.Set on my User (Hibernate) object. This refers to a collection of Resume objects. When I generate my StrutsForms, I need to do something in my XDoclet template to turn a java.util.Set into a java.util.ArrayList. I don't know that I have to do this, but I've always used ArrayLists or Vectors on ActionForms for child objects.
- I am using
BeanUtils.copyProperties in a Business Delegate to transfer properties from my User object to a UserForm object. When I do this, the child objects come through as Resume objects - where I really want them to come through as ResumeForms. Is this possible using BeanUtils, or do I have to do this manually?
I should probably do some research now to try and figure this stuff out on my own - but hopefully an answer will come through while I'm doing that ;-). I'll post to the proper mailing lists if I can't figure it out by COB. BTW, if you're using Hibernate, the FAQ is awesome. I wish more OSS (or closed-source software) had documentation this good.
