You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Rick R <ri...@gmail.com> on 2005/12/16 00:44:08 UTC
The Age-Old problem of validation when you have Nested Items- opinions and Dyna question
Cutting right to the chase...
I'm curious on how others handle the age-old struts problem of: "How do you
handle nested objects in an ActionForm that have non String properties that
might be editable by a user on a JSP?"
To provide a watered down example...
Imagine you go to the DB to get a List of Company objects. Each company
object in the List has nested in it a List of Division objects. Each
Division has a "date" field in it (say a startDate). You then need to
display a form that displays the companies and divisions and could allow the
user to edit the date (in a free-form text field) and submit the form.
Things work fine if you didn't have to worry about form validation - in
which case, you could just have one property in your ActionForm: List
companies; //set/get and you are done (using the List of Company value
objects). You'd display the data on the form and submit and things are nice.
However, nested sort of deep is that "date" field. If the user enters in the
date wrong we want to return to the page and display what they entered so
they can fix it. This can't be done if you just want to use the nested value
object(POJO) approach.
This above scenario is Strut's biggest weakness. (It's compounded with
BeanUtils crazy notion of also not keeping wrapper clases like Integer truly
"null" when a String is null - instead it decides to make the Integer 0).
Besides wondering how others deal with this annoying problem (other than
moving to another framework like JSF), I was wondering if maybe DyanForms
could be a solution? Can you nest them ? If so then that might be the
answer. Typically I haven't been too fond of DyanForms in the past (for a
couple of reasons), but if it could solve this issue it would definitely be
worth their use.
--
Rick Reumann
Re: The Age-Old problem of validation when you have Nested Items- opinions and Dyna question
Posted by Paul Benedict <pa...@yahoo.com>.
Rick,
I just hope you're not making the situation more complicated than it needs to be. If I have to
display a 2D list of items (like say a table), I may be using a DTO which has multiple properties.
These are all strings.
I only found nested objects to be complex when I tried to make them business objects. It never
worked successfully with simplicity for me. If you have to edit a Line Item order, for example,
have a list of DTO objects like:
class LineItem {
String id;
String name;
String price;
}
And then iterate over the list, outputting the text boxes as such. I hope this helps.
Paul
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: The Age-Old problem of validation when you have Nested Items- opinions and Dyna question
Posted by Rick R <ri...@gmail.com>.
On 12/15/05, Paul Benedict <pa...@yahoo.com> wrote:
>
>
> As I said, the problem is you're using model objects for input. Don't do
> that. Your "load" action
> should convert the specific and limit poritions of your intended user
> input into the Form;
> probably a list of Strings. In your "save" action, you convert them back
> into the model object.
You're missing what I'm saying. You can't easily do what you are saying
with nested items.
Very rarely do I ever need nested objects in Struts, in my experience. I've
> done Struts for about
> 3 years now and I think only one time I had to do it in a big business
> application. Usually, all
> the user needs to do is update a simple list; so typically you can pull
> out all your nested data
> into a simple array.
Well, my experience has been just the opposite and have been using Struts
for over three years. I'm usually dealing with business applications where
things are much more complex than you describe.. and that's been the norm
not the exception.
Later when I get back from seeing the Lion The Witch and the Wardrobe, I'll
provide even some simple cases that make much more sense to have nested
objects....
Larry if you read this.. explain the deal with the Department id situation:)
I got a run..
--
Rick
Re: The Age-Old problem of validation when you have Nested Items- opinions and Dyna question
Posted by Paul Benedict <pa...@yahoo.com>.
>> I'm concerned with having to deal with that limitation then how DO you deal with the
'model/domain/business' objects that do need to get populated? Sure in a simple form it's easy,
but real life is a different story. Many times you get back objects that are nested in
Collections...
As I said, the problem is you're using model objects for input. Don't do that. Your "load" action
should convert the specific and limit poritions of your intended user input into the Form;
probably a list of Strings. In your "save" action, you convert them back into the model object.
Very rarely do I ever need nested objects in Struts, in my experience. I've done Struts for about
3 years now and I think only one time I had to do it in a big business application. Usually, all
the user needs to do is update a simple list; so typically you can pull out all your nested data
into a simple array.
Paul
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: The Age-Old problem of validation when you have Nested Items- opinions and Dyna question
Posted by Rick R <ri...@gmail.com>.
On 12/15/05, Paul Benedict <pa...@yahoo.com> wrote:
>
> Action Forms are DTO objects. They are not your model/domain/business
> objects. Struts is the only
> framework (historical design) that forces you to use String objects in the
> Form/DTO, but that's
> not a bad thing. It's a container to accept user input, which is all from
> the Internet transmitted
> as strings. You can of course have non-string values in the form, but
> those should NEVER accept
> input -- and it's because the input needs a place to reside as Strings
> before the validator can
> validate them. Otherwise you would blow up with bad input when the
> conversion fails.
Ok, yes you aren' t telling me anything new or addressing the problem that
still needs to be solved. Sure you can state the reason of why ActionForms
should only have String properties... been there explored that... that's not
my question. I'm concerned with having to deal with that limitation then how
DO you deal with the 'model/domain/business' objects that do need to get
populated? Sure in a simple form it's easy, but real life is a different
story. Many times you get back objects that are nested in Collections and
those properties in those domain objects have to be translated somehow to a
front end representation that can update them when the form submits. Various
approaches exist to this. What is your preferred approach?
Now this will change with Struts 2.x; there is an automatic type converter
> and you can submit into
> model/domain/business objects.
I'll have to look into this. Is this feature documented anywhere other than
in the 2.0 src?
--
Rick
Re: The Age-Old problem of validation when you have Nested Items- opinions and Dyna question
Posted by Rick R <ri...@gmail.com>.
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 <hr...@gmail.com> 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 <ri...@gmail.com> wrote:
> > On 12/15/05, Hubert Rabago <hr...@gmail.com> 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: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
--
Rick
Re: The Age-Old problem of validation when you have Nested Items- opinions and Dyna question
Posted by Paul Benedict <pa...@yahoo.com>.
Action Forms are DTO objects. They are not your model/domain/business objects. Struts is the only
framework (historical design) that forces you to use String objects in the Form/DTO, but that's
not a bad thing. It's a container to accept user input, which is all from the Internet transmitted
as strings. You can of course have non-string values in the form, but those should NEVER accept
input -- and it's because the input needs a place to reside as Strings before the validator can
validate them. Otherwise you would blow up with bad input when the conversion fails.
Now this will change with Struts 2.x; there is an automatic type converter and you can submit into
model/domain/business objects. That's a good thing too because Spring, WebWork, Tapestry, JSF, and
all other modern frameworks allow this.
Paul
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: The Age-Old problem of validation when you have Nested Items- opinions and Dyna question
Posted by Hubert Rabago <hr...@gmail.com>.
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 <ri...@gmail.com> wrote:
> On 12/15/05, Hubert Rabago <hr...@gmail.com> 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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: The Age-Old problem of validation when you have Nested Items- opinions and Dyna question
Posted by Rick R <ri...@gmail.com>.
On 12/15/05, Hubert Rabago <hr...@gmail.com> 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
Re: The Age-Old problem of validation when you have Nested Items- opinions and Dyna question
Posted by Hubert Rabago <hr...@gmail.com>.
I've always used String values. Given that difference, I've seen this work:
<field property="birth" indexedListProperty="employees"
depends="required,date">
<arg0 key="employeeform.birth.displayname"/>
<var>
<var-name>datePatternStrict</var-name>
<var-value>MM/dd/yyyy</var-value>
</var>
</field>
In this case, the form bean has a collection of "employees", and each
employee has a "birth" field.
Then something like <nested:errors property="birth"/> beside the field
will show which of the many employees has the invalid date.
I have a sample app (minus the <nested> tag, though I've just tried
that and it works) somewhere you can download it if you want to see
it. That sample app actually goes one level deeper:
<field property="address.zip"
indexedListProperty="employees" depends="required,integer">
<arg0 key="employeeform.address.zip.displayname"/>
</field>
Each "employee" has an address field which is also a nested form, with
zip as an int field.
Hubert
On 12/15/05, Rick R <ri...@gmail.com> wrote:
> Cutting right to the chase...
>
> I'm curious on how others handle the age-old struts problem of: "How do you
> handle nested objects in an ActionForm that have non String properties that
> might be editable by a user on a JSP?"
>
> To provide a watered down example...
>
> Imagine you go to the DB to get a List of Company objects. Each company
> object in the List has nested in it a List of Division objects. Each
> Division has a "date" field in it (say a startDate). You then need to
> display a form that displays the companies and divisions and could allow the
> user to edit the date (in a free-form text field) and submit the form.
>
> Things work fine if you didn't have to worry about form validation - in
> which case, you could just have one property in your ActionForm: List
> companies; //set/get and you are done (using the List of Company value
> objects). You'd display the data on the form and submit and things are nice.
>
> However, nested sort of deep is that "date" field. If the user enters in the
> date wrong we want to return to the page and display what they entered so
> they can fix it. This can't be done if you just want to use the nested value
> object(POJO) approach.
>
> This above scenario is Strut's biggest weakness. (It's compounded with
> BeanUtils crazy notion of also not keeping wrapper clases like Integer truly
> "null" when a String is null - instead it decides to make the Integer 0).
>
> Besides wondering how others deal with this annoying problem (other than
> moving to another framework like JSF), I was wondering if maybe DyanForms
> could be a solution? Can you nest them ? If so then that might be the
> answer. Typically I haven't been too fond of DyanForms in the past (for a
> couple of reasons), but if it could solve this issue it would definitely be
> worth their use.
>
> --
> Rick Reumann
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: The Age-Old problem of validation when you have Nested Items- opinions and Dyna question
Posted by Paul Benedict <pa...@yahoo.com>.
I am glad you found the LazyDynaBeanForm. I hope it suits your needs.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: The Age-Old problem of validation when you have Nested Items- opinions and Dyna question
Posted by Rick R <ri...@gmail.com>.
To recap...
understand that you can do something like you mention above, but have you
tried to do that? It brings me back full circle to my original point that I
haven't found a clean solution at all. Say we are back to a list of users
and each user has multiple "addresses." You want to update all the address
information for each address including the Integer "zipCode." Are you going
to make a new object called AddressWithPropsForJustInput - even though you
need to input 99% of what's alredy in "Address" (as Strings) except for the
zip (thus duplicating 99% of what already exsists). Doing this will also
require a new Employee object that can take your
"AddressWithPropsForJustInput" so that you can populate your list of
EmployeesWitPropsJustForInput in your ActionForm. You then have to get all
this info back into a List of regular Employees - and if you didn't
lazyLists up front inside of Employee - you are going to have a nice ugly
time looping through everything and recreating objects and populating your
input fields into them.
Bottom line is it is going to be *extremely* messy - I've actually tried
using that approach as well. I've tried even embedding the value objects
into my ActionForm DTOs - for example
AddressWithPropsJustForInput {
Address address; //standard value object from domain
String zipAsString;
setAddress(Address address) { this.address = address; }
getAddress( return address; );
String setZipAsString().... etc
Another option is to recreate the backend methods to take your new
"inputOnly" objects - bypassing the transfer of the inputOnly objects to the
normal domain POJOs (value object/dto's/whatever you want to call them). I'm
not fond of this solution either.
All this being said Paul, I actually agree that what you propose will work
and it's actually all that I can come up with as well - the problem is while
i've used that approach, It is very messy - especially when you have regular
POJOs staring at your right in the face. It's the duplication of property
names and the mess involved in conversions to the nested business objects
that you need to tranform them into that is the real annoyance.
I think I'm going to try all this with DynaForms and see how that alleviates
some of the headache. Thanks though for your thoughts.
On 12/17/05, Rick R <ri...@gmail.com> wrote:
>
> oops ... don't try to tab while using gmail :) I was trying to indent my
> code by instinct using tab and hit tab and 'end' to the end of the line an
> enter:) .... caused a send. I'l continue in another email.
>
> On 12/17/05, Rick R <ri...@gmail.com> wrote:
> >
> > On 12/16/05, Paul Benedict <pa...@yahoo.com> wrote:
> > >
> > >
> > > I am not suggestign you create a new business object. I am suggesting
> > > you create a new object for input purposes. You need a transport layer
> > > between your model and the web; thus you have an ActionForm. But you need to
> > > pad your ActionForm with additional objects because of the complexity of
> > > your app.
> >
> >
> >
> > In a sense though they "do" become duplicat objects of standard POJOs
> > that you use in the backend. You keep mentioning you only need to add the
> > properties that you need for input, and sure that's fine, that might save
> > you a couple minutes of work not having to add those properties, but I'll
> > explain more about the problem with that later.
> >
> > >
> > >
> > > No. You only create properties for the values you need for INPUT. As I
> > > said in previous emails, if you have a business object with 50 properties
> > > but only need to capture input for 3, your input object only needs 3
> > > properties.
> >
> >
> >
> > I understand that you can do something like you mention above, but have
> > you tried to do that? It brings me back full circle to my original point
> > that I haven't found a clean solution at all. Say we are back to a list of
> > users and each user has multiple "addresses." You want to update all the
> > address information for each address including the Integer "zipCode." Are
> > you going to make a new object called AddressWithPropsForJustInput - even
> > though you need to input 99% of what's alredy in "Address" (as Strings)
> > except for the zip (thus duplicating 99% of what already exsists). Doing
> > this will also require a new Employee object that can take your
> > "AddressWithPropsForJustInput" so that you can populate your list of
> > EmployeesWitPropsJustForInput in your ActionForm. You then have to get all
> > this info back into a List of regular Employees - and if you didn't
> > lazyLists up front inside of Employee - you are going to have a nice ugly
> > time looping through everything and recreating objects and populating your
> > input fields into them.
> >
> > Bottom line is it is going to be *extremely* messy - I've actually tried
> > using that approach as well. I've tried even embedding the value objects
> > into my ActionForm DTOs - for example
> >
> > AddressWithPropsJustForInput {
> > Address address; //standard value object from domain
> > setAddress(..)// puts an Address object into the object. Th
> >
> >
> >
> > --
> > Rick
>
>
>
>
> --
> Rick
--
Rick
Re: The Age-Old problem of validation when you have Nested Items- opinions and Dyna question
Posted by Rick R <ri...@gmail.com>.
On 12/17/05, Martin Gainty <mg...@hotmail.com> wrote:
>
> Good Morning Rick
>
> I liked Niall Pemberton's Nested Lazy validation form solution found here
> http://www.niallp.pwp.blueyonder.co.uk/lazyactionform.html
I knew Niall would have some good stuff! Now I just have to mess around with
it... could it actually be as simple as...
<form-bean name="LazyBean" type="org.apache.commons.beanutils.LazyDynaBean"/>
//in my Action I get back for an example...
List of Foos where Foos each have a List of Bars and Bars each with
a List of Dogs.
BeanUtils.copyProperties( LazyBeanInstance, MyListOfFoos ) ?
And teh LazyBeanInstance will have in it Foos with Bars and Bars with Dogs?
If so.. that would be perfect.
I'm going to try it out.
Re: The Age-Old problem of validation when you have Nested Items- opinions and Dyna question
Posted by Martin Gainty <mg...@hotmail.com>.
Good Morning Rick
I liked Niall Pemberton's Nested Lazy validation form solution found here
http://www.niallp.pwp.blueyonder.co.uk/lazyactionform.html
Martin-
----- Original Message -----
From: "Rick R" <ri...@gmail.com>
To: "Struts Users Mailing List" <us...@struts.apache.org>
Sent: Saturday, December 17, 2005 9:10 AM
Subject: Re: The Age-Old problem of validation when you have Nested Items-
opinions and Dyna question
oops ... don't try to tab while using gmail :) I was trying to indent my
code by instinct using tab and hit tab and 'end' to the end of the line an
enter:) .... caused a send. I'l continue in another email.
On 12/17/05, Rick R <ri...@gmail.com> wrote:
>
> On 12/16/05, Paul Benedict <pa...@yahoo.com> wrote:
> >
> >
> > I am not suggestign you create a new business object. I am suggesting
> > you create a new object for input purposes. You need a transport layer
> > between your model and the web; thus you have an ActionForm. But you
> > need to
> > pad your ActionForm with additional objects because of the complexity of
> > your app.
>
>
>
> In a sense though they "do" become duplicat objects of standard POJOs that
> you use in the backend. You keep mentioning you only need to add the
> properties that you need for input, and sure that's fine, that might save
> you a couple minutes of work not having to add those properties, but I'll
> explain more about the problem with that later.
>
> >
> >
> > No. You only create properties for the values you need for INPUT. As I
> > said in previous emails, if you have a business object with 50
> > properties
> > but only need to capture input for 3, your input object only needs 3
> > properties.
>
>
>
> I understand that you can do something like you mention above, but have
> you tried to do that? It brings me back full circle to my original point
> that I haven't found a clean solution at all. Say we are back to a list
> of
> users and each user has multiple "addresses." You want to update all the
> address information for each address including the Integer "zipCode." Are
> you going to make a new object called AddressWithPropsForJustInput - even
> though you need to input 99% of what's alredy in "Address" (as Strings)
> except for the zip (thus duplicating 99% of what already exsists). Doing
> this will also require a new Employee object that can take your
> "AddressWithPropsForJustInput" so that you can populate your list of
> EmployeesWitPropsJustForInput in your ActionForm. You then have to get all
> this info back into a List of regular Employees - and if you didn't
> lazyLists up front inside of Employee - you are going to have a nice ugly
> time looping through everything and recreating objects and populating your
> input fields into them.
>
> Bottom line is it is going to be *extremely* messy - I've actually tried
> using that approach as well. I've tried even embedding the value objects
> into my ActionForm DTOs - for example
>
> AddressWithPropsJustForInput {
> Address address; //standard value object from domain
> setAddress(..)// puts an Address object into the object. Th
>
>
>
> --
> Rick
--
Rick
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: The Age-Old problem of validation when you have Nested Items- opinions and Dyna question
Posted by Rick R <ri...@gmail.com>.
oops ... don't try to tab while using gmail :) I was trying to indent my
code by instinct using tab and hit tab and 'end' to the end of the line an
enter:) .... caused a send. I'l continue in another email.
On 12/17/05, Rick R <ri...@gmail.com> wrote:
>
> On 12/16/05, Paul Benedict <pa...@yahoo.com> wrote:
> >
> >
> > I am not suggestign you create a new business object. I am suggesting
> > you create a new object for input purposes. You need a transport layer
> > between your model and the web; thus you have an ActionForm. But you need to
> > pad your ActionForm with additional objects because of the complexity of
> > your app.
>
>
>
> In a sense though they "do" become duplicat objects of standard POJOs that
> you use in the backend. You keep mentioning you only need to add the
> properties that you need for input, and sure that's fine, that might save
> you a couple minutes of work not having to add those properties, but I'll
> explain more about the problem with that later.
>
> >
> >
> > No. You only create properties for the values you need for INPUT. As I
> > said in previous emails, if you have a business object with 50 properties
> > but only need to capture input for 3, your input object only needs 3
> > properties.
>
>
>
> I understand that you can do something like you mention above, but have
> you tried to do that? It brings me back full circle to my original point
> that I haven't found a clean solution at all. Say we are back to a list of
> users and each user has multiple "addresses." You want to update all the
> address information for each address including the Integer "zipCode." Are
> you going to make a new object called AddressWithPropsForJustInput - even
> though you need to input 99% of what's alredy in "Address" (as Strings)
> except for the zip (thus duplicating 99% of what already exsists). Doing
> this will also require a new Employee object that can take your
> "AddressWithPropsForJustInput" so that you can populate your list of
> EmployeesWitPropsJustForInput in your ActionForm. You then have to get all
> this info back into a List of regular Employees - and if you didn't
> lazyLists up front inside of Employee - you are going to have a nice ugly
> time looping through everything and recreating objects and populating your
> input fields into them.
>
> Bottom line is it is going to be *extremely* messy - I've actually tried
> using that approach as well. I've tried even embedding the value objects
> into my ActionForm DTOs - for example
>
> AddressWithPropsJustForInput {
> Address address; //standard value object from domain
> setAddress(..)// puts an Address object into the object. Th
>
>
>
> --
> Rick
--
Rick
Re: The Age-Old problem of validation when you have Nested Items- opinions and Dyna question
Posted by Rick R <ri...@gmail.com>.
On 12/16/05, Paul Benedict <pa...@yahoo.com> wrote:
>
>
> I am not suggestign you create a new business object. I am suggesting you
> create a new object for input purposes. You need a transport layer between
> your model and the web; thus you have an ActionForm. But you need to pad
> your ActionForm with additional objects because of the complexity of your
> app.
In a sense though they "do" become duplicat objects of standard POJOs that
you use in the backend. You keep mentioning you only need to add the
properties that you need for input, and sure that's fine, that might save
you a couple minutes of work not having to add those properties, but I'll
explain more about the problem with that later.
>
>
> No. You only create properties for the values you need for INPUT. As I
> said in previous emails, if you have a business object with 50 properties
> but only need to capture input for 3, your input object only needs 3
> properties.
I understand that you can do something like you mention above, but have you
tried to do that? It brings me back full circle to my original point that I
haven't found a clean solution at all. Say we are back to a list of users
and each user has multiple "addresses." You want to update all the address
information for each address including the Integer "zipCode." Are you going
to make a new object called AddressWithPropsForJustInput - even though you
need to input 99% of what's alredy in "Address" (as Strings) except for the
zip (thus duplicating 99% of what already exsists). Doing this will also
require a new Employee object that can take your
"AddressWithPropsForJustInput" so that you can populate your list of
EmployeesWitPropsJustForInput in your ActionForm. You then have to get all
this info back into a List of regular Employees - and if you didn't
lazyLists up front inside of Employee - you are going to have a nice ugly
time looping through everything and recreating objects and populating your
input fields into them.
Bottom line is it is going to be *extremely* messy - I've actually tried
using that approach as well. I've tried even embedding the value objects
into my ActionForm DTOs - for example
AddressWithPropsJustForInput {
Address address; //standard value object from domain
setAddress(..)// puts an Address object into the object. Th
--
Rick
Re: The Age-Old problem of validation when you have Nested Items- opinions and Dyna question
Posted by Paul Benedict <pa...@yahoo.com>.
Rick,
> It sounds like to me you are suggesting that we'd create a "brand new" Player object that had
some String properties in it.
I am not suggestign you create a new business object. I am suggesting you create a new object for
input purposes. You need a transport layer between your model and the web; thus you have an
ActionForm. But you need to pad your ActionForm with additional objects because of the complexity
of your app.
> You are creating an identical object to the exisiting POJO where the only > difference is
changing a few of the property types (ie number or date to String).
No. You only create properties for the values you need for INPUT. As I said in previous emails, if
you have a business object with 50 properties but only need to capture input for 3, your input
object only needs 3 properties.
Paul
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: The Age-Old problem of validation when you have Nested Items- opinions and Dyna question
Posted by Rick R <ri...@gmail.com>.
On 12/16/05, Paul Benedict <pa...@yahoo.com> wrote:
>
> Rick,
>
> Do you control the requirements? It's going to be an ugly screen with that
> :)
Agreed. For that example it was more so to exaggerate a problem that does
come up when dealing with more specific situations.
In regard to the solution it seems like you were suggesting, it would
involve not only creating duplicate beans (not even ActionForms) simply to
meet the String only requirement. Populating these lists of lists of back
and forth doing domain POJO to yourStringsPOJOs would be very cumbersome
even if using BeanUtils.
While driving into work, I was thinking of how badly I got beat in my
fantasy football game this past weekend which got me thinking of another
typical example of having to use nested beans.
If you've played fantasy football before, or if you could just consider
being the manager of any sport's team, you might have to submit a weekly
lineup which involves looking at all your players and marking them 'active'
or 'bench' (real life more status' of course).
So let's imagine you were first tasked at the beginning of the season to
help out an NFL team. They needed a way to enter in their player data.
Backend returns a "Player":
Player object:
String name
Integer playingStatus; //0 - bench 1 - active. DB holds Integer
(Again in real life I'd actually probably have a nested Status object here
which would give me more info on the status, such as Integer statusCode,
String statusName)
Now we need our ActionForm to enter this data:
PlayerActionForm
String name;
*String* playingStatus
Things are fine so far. Happy developers working for the NFL team.
Next we realize that we need to create a "Weekly Team Roster" screen where
the Manager can go and set his players as 'active' or 'inactive.' He likes
to do this by just entering in a 0 or 1, doesn't want to use a drop down
list.
So we want to see...
My Team
name status
---- -------
John Doe 1
Fred Guy 0
//etc
Also imagine of course much more data, position, player address etc. So the
question in scenario two becomes "What are you going to return from your
backend to display on the screen?" Normally I'd like to return a "Team"
object which would have a List of Players nested in it, but lets just make
it more simple and return a List of Employees that we need to update from
our ActionForm. Why would you not get back a List of "Player" objects? It
makes perfect sense - except we have one slight problem - we have that
Integer value for status.
It sounds like to me you are suggesting that we'd create a "brand new"
Player object that had some String properties in it. To me, this goes
against, the whole concept of object oriented programming and code reuse.
You are creating an identical object to the exisiting POJO where the only
difference is changing a few of the property types (ie number or date to
String).
Re: The Age-Old problem of validation when you have Nested Items- opinions and Dyna question
Posted by Paul Benedict <pa...@yahoo.com>.
Rick,
Do you control the requirements? It's going to be an ugly screen with that :) Web applications
should be concerned with doing one unit of task at a time, if possible, because it does simplfy
development and help the user focus on what needs to be typed.
Still, I don't see this problem as insurmountable. As long as you don't mind having ugly screens,
you can; and what is probably goign to make your screen ugly is the requirements, which mandate
all too much input data on one screen. I think you're pigeonholed here so do the best you can.
class CompanyInput {
private Company o;
private List divisionInput;
private String inputAttr1;
private String inputAttr2;
}
class DivisionInput {
private Division o;
private List deptInput;
private String inputAttr1;
private String inputAttr2;
}
class DepartmentInput {
private Department o;
private String inputAttr1;
private String inputAttr2;
}
You just have to create an input model that reflects what you want to capture. There's nothing
really more I can do for you; you have lousy requirements so make the best of them. Break up the
input into different pages for a better time.
Paul
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: The Age-Old problem of validation when you have Nested Items- opinions and Dyna question
Posted by Rick R <ri...@gmail.com>.
Ok, this might be lengthy, but hopefully you will get my point after reading
it:)
This hypothetical I'm proposing isn't my actual use case, I'm creating an
example that is easier to work with even if not totally realistic.
The business requirement is the user needs to select a letter of alphabet
and then get back companies that start with that lettter so that they can
edit the Companies and the Divisions within each Company and within each
division be able to edit the Departments. All form ONE screen. So for
ultimate simplicity lets say it looks like:
//unkown num of companies
Company Name
Company Date
//unknown num of divisions
Division Name
Division Date
//unkown num of Departments
Deapartment Name
Department Date
All fields above are editable and all dates need to be validated to be in
correct input format.
Your domain layer already has in place several beans that it uses: Company,
Division, Department. All have String name and java.util.Date date fields.
So the user selects "letter D" from the drop down and submits.
Ok now walk me through what you would set up.
In my scenario it makes sense to make a call to the backend passing in the
letter "D" into: List getCompanies(String letter);
I'll now have in my Action a List of Companies, where each Company in the
List has a List of Divisions and within each Divison I have a List of
Departments.
Tell me how I'm going to easily set that up in my ActionForm so that I can
edit those date fields? Remember POJOs already exist that have a Date
property in them. You aren't suggesting the developer go through and create
all new POJOs with Strings in them to hold the Dates? Actually most of the
suggestions i've seen talk about addign String properties directly on the
form which in this case is impossible. You have no idea how many of each
type you would need, and then think of the work involved to put them back
into the nested objects in order to give the data back to the backend
methods for update.
Now let's even take a more mundane example. Let's take a "Person" object.
Before we even need to do any editing we have to display some users. Most
would agree that in OO programming its good to separate out responsibilities
so since a Person can have different Addresses (ie Work, Home, School, etc)
we typically have an Address object that would hold that data and maybe in
Person we'd have a Collection addresses to hold the Address objects. This
fits nicely with what our domain model gives us back when we make queries as
well. So displaying a List of Users we could also easily beneath each user
display their various addresses. Now what happens when you click on that
Person and you want to be able to edit that Person AND edit the different
addresses all from one screen? What are your properties going to be in your
PersonActionForm? In this case since it's just a one level deep nest you
could create a List of HashMaps and hold each Address info in a HashMap, but
besides that being conceptually ugly, what if your Address object also had
some other data that needed to be updated (maybe a Collection of Phone
Numbers per address?).
I'm not so fond of cracking open each value object POJO and adding
birthDateAsString properties into them and then having them do coversions to
the underlying Date birthDate properties. Although that works it's really
not a very clean solution.
Does anyone know if the newer versions of Struts, Sruts TiBo, StrutsRocky
III, handle any of this? (I've been on the dark side doing some .NET stuff
so have been out of the loop for a while, but want to get back up to speed
with the latest buzz in the struts world).
--
Rick
Re: The Age-Old problem of validation when you have Nested Items- opinions and Dyna question
Posted by Paul Benedict <pa...@yahoo.com>.
I want to add one thing to Raghu's advice:
You only need String-only DTOs at the form layer for INPUT variables only. Anything you retrieved
from the business layer can be stuck in the request as it is for display purposes, or attached
right to the form. You may want something like this in your array:
Pretend you have a class with 50 attributes. You obviously don't want "double the objects" and you
won't, because you only model the portion that belongs to your input. You could do this:
public class LineItemInputDTO {
LineItem item; // use this to display read only data
String inputAttr1;
String inputAttr2;
}
So you could create this object, as I said, in the "load" method -- and then once you're happy
with the validation in the "savE" method, you convert those input attributes back into the actual
model.
Paul
--- Raghu Kanchustambham <kr...@gmail.com> wrote:
> Have a strDate which is of type string. The setStrDate() needs to be coded
> in such a way that it sets the date attribute also which is of type Date.
>
> The getDate() which returns Date object can be used in the "business"
> layers. For example, my Hibernate mappings map to getDate and not to
> getStrDate... but my setStrDate is used at the struts form layer.
>
> While I do see the point of not mixing your business objects with DTO's, for
> most *small* applications I see it as a overhead (mostly from maintenance
> point of view) to separate them. You would end up doubling the number of
> your business objects. Atleast on the small application I started off with
> struts, I have just one or two attributes for a class with around say 10
> attributes which require this workaround. So I did rather "contaminate" my
> class with a few strXXX attributes rather than create a separate class
> (called DTOs and business objects), ofcourse contrary to the common wisdom !
> :-) I have been using this on my current *small* application and it doesnt
> seem to give any problems.
>
> The other way to not "contaminate" your business classes would be to define
> these attributes in the dyna form, do the validation on these additional
> attributes and on submit (if the validation passes) populate the business
> object (in your action class).
>
> You can choose your poison! :-) or wait for later releases of struts to take
> care of this more elegantly! :-)
>
>
> Regards,
> Raghu
>
>
>
> On 12/16/05, Rick R <ri...@gmail.com> wrote:
> >
> > Cutting right to the chase...
> >
> > I'm curious on how others handle the age-old struts problem of: "How do
> > you
> > handle nested objects in an ActionForm that have non String properties
> > that
> > might be editable by a user on a JSP?"
> >
> > To provide a watered down example...
> >
> > Imagine you go to the DB to get a List of Company objects. Each company
> > object in the List has nested in it a List of Division objects. Each
> > Division has a "date" field in it (say a startDate). You then need to
> > display a form that displays the companies and divisions and could allow
> > the
> > user to edit the date (in a free-form text field) and submit the form.
> >
> > Things work fine if you didn't have to worry about form validation - in
> > which case, you could just have one property in your ActionForm: List
> > companies; //set/get and you are done (using the List of Company value
> > objects). You'd display the data on the form and submit and things are
> > nice.
> >
> > However, nested sort of deep is that "date" field. If the user enters in
> > the
> > date wrong we want to return to the page and display what they entered so
> > they can fix it. This can't be done if you just want to use the nested
> > value
> > object(POJO) approach.
> >
> > This above scenario is Strut's biggest weakness. (It's compounded with
> > BeanUtils crazy notion of also not keeping wrapper clases like Integer
> > truly
> > "null" when a String is null - instead it decides to make the Integer 0).
> >
> > Besides wondering how others deal with this annoying problem (other than
> > moving to another framework like JSF), I was wondering if maybe DyanForms
> > could be a solution? Can you nest them ? If so then that might be the
> > answer. Typically I haven't been too fond of DyanForms in the past (for a
> > couple of reasons), but if it could solve this issue it would definitely
> > be
> > worth their use.
> >
> > --
> > Rick Reumann
> >
> >
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: The Age-Old problem of validation when you have Nested Items- opinions and Dyna question
Posted by Raghu Kanchustambham <kr...@gmail.com>.
Have a strDate which is of type string. The setStrDate() needs to be coded
in such a way that it sets the date attribute also which is of type Date.
The getDate() which returns Date object can be used in the "business"
layers. For example, my Hibernate mappings map to getDate and not to
getStrDate... but my setStrDate is used at the struts form layer.
While I do see the point of not mixing your business objects with DTO's, for
most *small* applications I see it as a overhead (mostly from maintenance
point of view) to separate them. You would end up doubling the number of
your business objects. Atleast on the small application I started off with
struts, I have just one or two attributes for a class with around say 10
attributes which require this workaround. So I did rather "contaminate" my
class with a few strXXX attributes rather than create a separate class
(called DTOs and business objects), ofcourse contrary to the common wisdom !
:-) I have been using this on my current *small* application and it doesnt
seem to give any problems.
The other way to not "contaminate" your business classes would be to define
these attributes in the dyna form, do the validation on these additional
attributes and on submit (if the validation passes) populate the business
object (in your action class).
You can choose your poison! :-) or wait for later releases of struts to take
care of this more elegantly! :-)
Regards,
Raghu
On 12/16/05, Rick R <ri...@gmail.com> wrote:
>
> Cutting right to the chase...
>
> I'm curious on how others handle the age-old struts problem of: "How do
> you
> handle nested objects in an ActionForm that have non String properties
> that
> might be editable by a user on a JSP?"
>
> To provide a watered down example...
>
> Imagine you go to the DB to get a List of Company objects. Each company
> object in the List has nested in it a List of Division objects. Each
> Division has a "date" field in it (say a startDate). You then need to
> display a form that displays the companies and divisions and could allow
> the
> user to edit the date (in a free-form text field) and submit the form.
>
> Things work fine if you didn't have to worry about form validation - in
> which case, you could just have one property in your ActionForm: List
> companies; //set/get and you are done (using the List of Company value
> objects). You'd display the data on the form and submit and things are
> nice.
>
> However, nested sort of deep is that "date" field. If the user enters in
> the
> date wrong we want to return to the page and display what they entered so
> they can fix it. This can't be done if you just want to use the nested
> value
> object(POJO) approach.
>
> This above scenario is Strut's biggest weakness. (It's compounded with
> BeanUtils crazy notion of also not keeping wrapper clases like Integer
> truly
> "null" when a String is null - instead it decides to make the Integer 0).
>
> Besides wondering how others deal with this annoying problem (other than
> moving to another framework like JSF), I was wondering if maybe DyanForms
> could be a solution? Can you nest them ? If so then that might be the
> answer. Typically I haven't been too fond of DyanForms in the past (for a
> couple of reasons), but if it could solve this issue it would definitely
> be
> worth their use.
>
> --
> Rick Reumann
>
>