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]
