I just did something like this and found it to be somewhat cumbersome. :) To create a type converter that does primary key -> entity lookups, the converter needs to have access to a Hibernate session - preferrably the same session that the action will use. Also, to set the location on the employee, the employee has to be set in the action before the new Location instance is assigned to it. This is a bit tricky since the Employee instance probably is loaded when the action is executed (which is after the parameters have been set). This is the way I made it work (using HibernateSessionAware component "pattern" ):
1. Configure the interceptor stack so that the component interceptor is executed before the parameter interceptor
2. When the component interceptor calls setHibernateSession(), put the session into the action context
3. Create two type converters, one to translate from employee key to Employee and one to translate from location key to Location. The converters can access the Hibernate session from the action context since the component interceptor is executed before the converters will be. Since this is the same session as the action will use, there won't be any trouble with lazy loading and cglib proxies (if you use those).
4. Remove the action's employee key property (which I assume you have in place) and replace them with "real" get/setEmployee(Employee)
This will make ensure that any property set on the model at any depth will be automagically persisted, but it feels "wrong". Too complicated, I guess. Editing "not-so-shallow" data models (like this one) and at the same time avoid using temporary property holders in the actions (e.g a location id property which is then translated when the action is executed) is hard. Or at least there aren't any eye catching elegant solutions to it.
Even if this example had only been about editing primitive (or primitive wrappers) properties of the Employee instance there would have been trouble. The simplest approach is to instanciate a temporary instance of the Employee class in the action and let the interceptors set the values to that instance, but then you'll have to copy the properties manually when the action executed later. (a beanutils library will help in some cases, but what about nulls and transient instances?).
The PetSoar example does not provide any pointers - it does manual copying and avoids this issue. Some debate on this subject would be very welcome! If we get a good and simple pattern for this, it would be a killer feature.
One last point BTW. The type conversion doco states that it's a bad idea to do database lookups. Can someone elaborate, please? :)
Cheers,
Dag
Jason Carreira wrote:
You're going to need a type converter which can convert from a String to a Location object... Location could possibly be implemented usnig the PersistentEnum pattern in Hibernate, otherwise you'll have to either:
A) do a lookup to the database to load the Location object for the city (you seem to be passing the city as the value)
B) Maybe your locations collection already has all of the Location objects and you can just look one up there to set
So after you implement your custom converter, you can look at
http://wiki.opensymphony.com/space/Type+Conversion for how type
conversion per-Action can be handled.
You can also create a file named xwork-conversion.properties in the root
of your classpath with registrations for default type conversion types.
Jason
-----Original Message-----
From: Donnerstag, Juergen [mailto:[EMAIL PROTECTED] Sent: Sunday, January 25, 2004 12:59 PM
To: [EMAIL PROTECTED]
Subject: [OS-webwork] select tag
I'm using webwork2 and hibernate and I have a question regarding the select tag. I checked the archives already, but did not find an answer, which is why I send this request for help.
I have a class Employee and a class Location. Both classes are defined in *.hbm.xml files and I can read and write data to these tables. Given an employee I retrieve its location simply by employee.getLocation().
I have designed a simple web form to input employee data and a dropdown select box to select the location. The list is initally filled with all locations (name of the city) from the database plus an empty one to cover the cases where there is no location yet assigned to an employee. Even pre-selecting already existing relations to a location works. However I've found no way yet to modify the location related to an employee. I can't figure out where webwork stores the selected value. My preferred solution would be. The attributes list and listKey identify the object (of class Location) and assigns that object (employee.setLocation(location)) to the employee. But that seems not to work. Any idea or solution?
<@ww.select label="'Location'" name="'employee.location'" value="employee.location.id" list="locations" listKey="id" listValue="city" />
thanks Juergen
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________
Opensymphony-webwork mailing list [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
