This below is very interesting Hubert. I'm going to have to to give this a try tomorrow. So basically there is a way to bind all your nested objects to Dyna objects which of course can be validated as String properties even though they'll map to non-string props if validation passes. I think this might be the answer. I look forward to trying it out. Thanks.
On 12/15/05, Hubert Rabago <[EMAIL PROTECTED]> wrote: > > Ok, my fault. I focused on the validation part. > > For this part: > > Why if you already have existing code > > working great wtih iBATIS, hibernate, or EJBs should you have to try and > > re-write all you POJOs to have String properties included in the > objects. > > That would be a maintenance nightmare and not even really practical. > > ...I'll give you one guess what my response is. > > > And if you guessed "formdef" you'd be correct. > > Here's how the "address", "employee", and "company" forms were defined > in the sample app I have: > > <form name="addressForm" > beanType="formdef.plugin.example.nested.business.Address"/> > > <!-- the main business object's form bean --> > <form name="employeeForm" > beanType="formdef.plugin.example.nested.business.Employee"> > > <!-- specify that our address field map to the addressForm --> > <field property="address" formName="addressForm"/> > > <!-- add a field that's not in the business object --> > <field property="selectedButton"/> > </form> > > > <!-- form for editing the entire company --> > <form name="companyForm" > beanType="formdef.plugin.example.nested.business.Company" > formType="org.apache.struts.validator.DynaValidatorForm"> > > <!-- specify that our address field map to the addressForm --> > <field property="address" formName="addressForm"/> > > <!-- use a collection for the employees field --> > <field property="employees" type="java.util.ArrayList"> > <converter > type=" > formdef.plugin.conversion.FormCollectionConverter" > param="employeeForm"> > <set-property key="formType" value=" > java.util.ArrayList"/> > <set-property key="beanType" value=" > java.util.ArrayList"/> > </converter> > </field> > </form> > > To summarize, it says "create addressForm and give it the same fields > as my Address object", "create employeeForm and give it the same > fields as my Employee object, plus a 'selectedButton' field. Oh, and > use the 'addressForm' definition for the 'address' field", and the > same essentially for the "companyForm", except I defined "employees" > to be a list, and told the converter which form to map its elements > to, and which Collection implementation class to use. > > Hubert > > > On 12/15/05, Rick R <[EMAIL PROTECTED]> wrote: > > On 12/15/05, Hubert Rabago <[EMAIL PROTECTED]> wrote: > > > > > > I've always used String values. > > > > > > But that above is the problem - you can't always have String values > returned > > to you in nested objects from the domain-layer, backend, mid-tier, etc. > When > > you query the backend for value objects that have nested objects inside > of > > them, you can be sure those will have all String fields in them. (I > guess > > you could if you decided to rewrite the whole backend/midtier but that's > > just not feasible or a good idea. Why if you already have existing code > > working great wtih iBATIS, hibernate, or EJBs should you have to try and > > re-write all you POJOs to have String properties included in the > objects. > > That would be a maintenance nightmare and not even really practical). > > > > So the question is how do you deal with the objects that come to you > from > > the backend that do not have all String properties and you need to > update > > them from the front end. I'm yet to see a clean solution for this, but > I'm > > still on my search:) > > > > -- > > Rick > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Rick
