Re: ActionForm and Transfer Object
By having a TO in my form bean , I still use validate and reset methods. e.g. Check validity of user.getName() in validate method Where my jsp field is UserForm has getUser() and setUser() methods And as far as TOs are concerned they are auto-generated during build process - Original Message - From: "Yves Sy" <[EMAIL PROTECTED]> To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]> Sent: Thursday, August 26, 2004 1:16 PM Subject: RE: ActionForm and Transfer Object The problem with that approach is you'll end up putting your validation code in your TO and you'll have to write your own error handling routine too. If you use ActionForms, you can save time by taking advantage of Struts' error handling mechanism via the validate() method and checkbox handling via the reset() method. Regards, -Yves- > -Original Message- > From: Deepak [mailto:[EMAIL PROTECTED] > Sent: Thursday, August 26, 2004 3:23 PM > To: Struts Users Mailing List > Subject: Re: ActionForm and Transfer Object > > I like passing a TO into the ActionForm so it gets updated by the jsp > submission and is ready for being sent back over to the business tier. > > - Original Message - > From: "Leandro Melo" <[EMAIL PROTECTED]> > To: "Struts Users Mailing List" <[EMAIL PROTECTED]> > Sent: Wednesday, August 25, 2004 11:26 PM > Subject: Re: ActionForm and Transfer Object > > > > Sure Rick, and "where should me do it" might be a good > > discussion (like the one that we`re all going on right > > now). > > > > A few months ago i had a similar discussion in a > > forum. > > Is someone is interested to hear more opinions, here > > it is > > > http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=5 8&t= > 002880 > > > > > > > > --- Rick Reumann <[EMAIL PROTECTED]> escreveu: > > > Leandro Melo wrote: > > > > Rick, > > > > i agree with you, i also use BeanUtils to populate > > > my > > > > forms. > > > > But, this doesn't go far way from having your > > > > ActionForms dependent on your TOs (or CustomTOs, > > > > doesn' t matter). > > > > > > Well I wouldn't say they are 'dependent' on each > > > other except that it > > > makes it easier if the property names match. Think > > > about it, at some > > > point you are always going to have some sort of > > > binding match up going > > > on. Something somewhere along the line has to bind a > > > request parameter > > > name (which is just a key in a Map) to the real > > > business object > > > property. You can devise different ways to do this > > > and look at how other > > > frameworks handle it, but somewhere this has to be > > > done. > > > > > > -- > > > Rick > > > > > > > > - > > > To unsubscribe, e-mail: > > > [EMAIL PROTECTED] > > > For additional commands, e-mail: > > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > ___ > > Yahoo! Acesso Grátis - navegue de graça com conexão de qualidade! > > http://br.acesso.yahoo.com/ > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: ActionForm and Transfer Object
The problem with that approach is you'll end up putting your validation code in your TO and you'll have to write your own error handling routine too. If you use ActionForms, you can save time by taking advantage of Struts' error handling mechanism via the validate() method and checkbox handling via the reset() method. Regards, -Yves- > -Original Message- > From: Deepak [mailto:[EMAIL PROTECTED] > Sent: Thursday, August 26, 2004 3:23 PM > To: Struts Users Mailing List > Subject: Re: ActionForm and Transfer Object > > I like passing a TO into the ActionForm so it gets updated by the jsp > submission and is ready for being sent back over to the business tier. > > - Original Message - > From: "Leandro Melo" <[EMAIL PROTECTED]> > To: "Struts Users Mailing List" <[EMAIL PROTECTED]> > Sent: Wednesday, August 25, 2004 11:26 PM > Subject: Re: ActionForm and Transfer Object > > > > Sure Rick, and "where should me do it" might be a good > > discussion (like the one that we`re all going on right > > now). > > > > A few months ago i had a similar discussion in a > > forum. > > Is someone is interested to hear more opinions, here > > it is > > > http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=5 8&t= > 002880 > > > > > > > > --- Rick Reumann <[EMAIL PROTECTED]> escreveu: > > > Leandro Melo wrote: > > > > Rick, > > > > i agree with you, i also use BeanUtils to populate > > > my > > > > forms. > > > > But, this doesn't go far way from having your > > > > ActionForms dependent on your TOs (or CustomTOs, > > > > doesn' t matter). > > > > > > Well I wouldn't say they are 'dependent' on each > > > other except that it > > > makes it easier if the property names match. Think > > > about it, at some > > > point you are always going to have some sort of > > > binding match up going > > > on. Something somewhere along the line has to bind a > > > request parameter > > > name (which is just a key in a Map) to the real > > > business object > > > property. You can devise different ways to do this > > > and look at how other > > > frameworks handle it, but somewhere this has to be > > > done. > > > > > > -- > > > Rick > > > > > > > > - > > > To unsubscribe, e-mail: > > > [EMAIL PROTECTED] > > > For additional commands, e-mail: > > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > ___ > > Yahoo! Acesso Grátis - navegue de graça com conexão de qualidade! > > http://br.acesso.yahoo.com/ > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ActionForm and Transfer Object
I like passing a TO into the ActionForm so it gets updated by the jsp submission and is ready for being sent back over to the business tier. - Original Message - From: "Leandro Melo" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> Sent: Wednesday, August 25, 2004 11:26 PM Subject: Re: ActionForm and Transfer Object > Sure Rick, and "where should me do it" might be a good > discussion (like the one that we`re all going on right > now). > > A few months ago i had a similar discussion in a > forum. > Is someone is interested to hear more opinions, here > it is > http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=58&t= 002880 > > > > --- Rick Reumann <[EMAIL PROTECTED]> escreveu: > > Leandro Melo wrote: > > > Rick, > > > i agree with you, i also use BeanUtils to populate > > my > > > forms. > > > But, this doesn't go far way from having your > > > ActionForms dependent on your TOs (or CustomTOs, > > > doesn' t matter). > > > > Well I wouldn't say they are 'dependent' on each > > other except that it > > makes it easier if the property names match. Think > > about it, at some > > point you are always going to have some sort of > > binding match up going > > on. Something somewhere along the line has to bind a > > request parameter > > name (which is just a key in a Map) to the real > > business object > > property. You can devise different ways to do this > > and look at how other > > frameworks handle it, but somewhere this has to be > > done. > > > > -- > > Rick > > > > > - > > To unsubscribe, e-mail: > > [EMAIL PROTECTED] > > For additional commands, e-mail: > > [EMAIL PROTECTED] > > > > > > > > > > ___ > Yahoo! Acesso Grátis - navegue de graça com conexão de qualidade! > http://br.acesso.yahoo.com/ > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ActionForm and Transfer Object
Sure Rick, and "where should me do it" might be a good discussion (like the one that we`re all going on right now). A few months ago i had a similar discussion in a forum. Is someone is interested to hear more opinions, here it is http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=58&t=002880 --- Rick Reumann <[EMAIL PROTECTED]> escreveu: > Leandro Melo wrote: > > Rick, > > i agree with you, i also use BeanUtils to populate > my > > forms. > > But, this doesn't go far way from having your > > ActionForms dependent on your TOs (or CustomTOs, > > doesn' t matter). > > Well I wouldn't say they are 'dependent' on each > other except that it > makes it easier if the property names match. Think > about it, at some > point you are always going to have some sort of > binding match up going > on. Something somewhere along the line has to bind a > request parameter > name (which is just a key in a Map) to the real > business object > property. You can devise different ways to do this > and look at how other > frameworks handle it, but somewhere this has to be > done. > > -- > Rick > > - > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > ___ Yahoo! Acesso Grátis - navegue de graça com conexão de qualidade! http://br.acesso.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ActionForm and Transfer Object
Leandro Melo wrote: Rick, i agree with you, i also use BeanUtils to populate my forms. But, this doesn't go far way from having your ActionForms dependent on your TOs (or CustomTOs, doesn' t matter). Well I wouldn't say they are 'dependent' on each other except that it makes it easier if the property names match. Think about it, at some point you are always going to have some sort of binding match up going on. Something somewhere along the line has to bind a request parameter name (which is just a key in a Map) to the real business object property. You can devise different ways to do this and look at how other frameworks handle it, but somewhere this has to be done. -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ActionForm and Transfer Object
Sebastian Ho wrote: I thought of putting the TO in session as well to prevent another DB call. This will work but if you are using a decent persistence mechanism another call to your backend layer will have the results of that query cached so the performance hit is extremely minimal. And unless the db call was some extremely complex long query, I wouldn't even worry about one extra DB call to populate the TO before doing the update (there are probably a lot more other things that will slow down an app than that DB call). I still think this solution is the cleanest and easiest to implement: //in update dispatch action or update action: TransferObject to = BackendEnd.getMyTransferObject(..); MyForm myForm = (MyForm)form; BeanUtils.copyProperties( to, myForm); BackEnd.doUpdate( to ); -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: ActionForm and Transfer Object
> -Original Message- > From: Joe Hertz [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 25, 2004 9:22 AM > To: 'Struts Users Mailing List' > Subject: RE: ActionForm and Transfer Object > > > > > 1) If you have a page which will update field A, but have > > > field B as hidden, > > > and while the user on this screen is on the phone, someone > > > else updates > > > field B, when the user saves his record, the other guy's > > > field B will be > > > overwritten. > > > > You have this race condition with the fields you are allowing > > to be changed as well. It's a well known problem, with > > several solutions. It's not jsut a problem with hidden fields. > > Oh, absolutely. Didn't try to imply otherwise, but in this > case, it's really > bad. It's the back door into the whole app. I don't see it as anymore of a security risk, and somewhat less, then allowing users to edit fields. The user has to go to a lot of trouble to spoof the app with hidden fields, as opposed to text fields. If they are going to that level of trouble, hidden fields are the least of your concerncs. Every field is vulnerable, hidden or not. If I use hidden fields, I typically still add them into the validation, and the business logic still treats the object as if the whole thing was exposed, not just pieces. If I'm really paranoid, I'll use a session attribute to store the original. I really don't like hitting the DB anymore then necessary. YMMV. If I have a business requirement that a user can only access certain fields, then I'll hit the DB again in the Business layer to do that check. > > Yes, youre letting the user update everything regardless of state, but > because of putting the current data into hidden fields, youre > ALSO letting > him see what the fields are to update (including their current values, > regardless of what he's supposed to be able to see). > > So even if you checked the state before you updated > everything from what the > html had (why you would do this, and not use the current > database state, I > don't know), you'd still be letting the user see everything. > By not checking > at all, youre now potentially giving him complete front end > access to your > database. > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: ActionForm and Transfer Object
> > 1) If you have a page which will update field A, but have > > field B as hidden, > > and while the user on this screen is on the phone, someone > > else updates > > field B, when the user saves his record, the other guy's > > field B will be > > overwritten. > > You have this race condition with the fields you are allowing > to be changed as well. It's a well known problem, with > several solutions. It's not jsut a problem with hidden fields. Oh, absolutely. Didn't try to imply otherwise, but in this case, it's really bad. It's the back door into the whole app. Yes, youre letting the user update everything regardless of state, but because of putting the current data into hidden fields, youre ALSO letting him see what the fields are to update (including their current values, regardless of what he's supposed to be able to see). So even if you checked the state before you updated everything from what the html had (why you would do this, and not use the current database state, I don't know), you'd still be letting the user see everything. By not checking at all, youre now potentially giving him complete front end access to your database. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: ActionForm and Transfer Object
> -Original Message- > From: Sebastian Ho [mailto:[EMAIL PROTECTED] > Sent: Tuesday, August 24, 2004 11:22 PM > To: Struts Users Mailing List > Subject: ActionForm and Transfer Object > > > Hi > > People have been telling me that ActionForm should not be dependent on > your TO. Simple because actionForm is for presentation and TO for your > business requirement. Sounds logical and right way to go. > > Now that I started developing using struts, it is actually not that > simple. > > Say I retrieve a TO from database and convert it into a actionForm for > display. In this case I have 4 fields for my actionForm but > 10 in my TO. > (6 are not needed for display). A user updates the 4 fields and the > action convert those into TO. In this case, the other 6 fields will be > reset to null(or empty) in my database! > > To prevent this, I actually need to use hidden fields in my > JSP or some > other ugly solutions in my Action class. They are still dependent on > each others afterall. > > Is there a solution to this or I am missing something here? Not really. The problem isn't struts. It's the way the web works as opposed to a gui. If you want to keep from having to make the second DB call, and avoid hidden fields, put the original TO in session, and use that instead of the DB call. Course, when you're done with it, null it out. > > Thanks > > Sebastian Ho > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: ActionForm and Transfer Object
> -Original Message- > From: Joe Hertz [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 25, 2004 8:51 AM > To: 'Struts Users Mailing List' > Subject: RE: ActionForm and Transfer Object > > > Seems to me that the issue is in how you go about hitting the > database with > your TO. > > Basically I'm +1 on "solution #2". > > Typically the only hidden html field I use routinely is for > the key of the > record. > > If you put all of the "not being updated fields" into the html, youre > creating potential problems. > > 1) If you have a page which will update field A, but have > field B as hidden, > and while the user on this screen is on the phone, someone > else updates > field B, when the user saves his record, the other guy's > field B will be > overwritten. You have this race condition with the fields you are allowing to be changed as well. It's a well known problem, with several solutions. It's not jsut a problem with hidden fields. > > 2) People can potentially just view source on the html and > discover how to > directly manipulate the database in ways you may or may not want. > > > -Original Message- > > From: Leandro Melo [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, August 25, 2004 10:18 AM > > To: Struts Users Mailing List > > Subject: Re: ActionForm and Transfer Object > > > > > > Rick, > > i agree with you, i also use BeanUtils to populate my > > forms. > > But, this doesn't go far way from having your > > ActionForms dependent on your TOs (or CustomTOs, > > doesn' t matter). > > As Sebastian said, i've heard a lot that TOs should > > mirror or shouldn't be coupled to your ActionForms, > > but i really don't how it's possible to build a very > > modular architecture without this coupling. > > > > > > > > > > --- Rick Reumann <[EMAIL PROTECTED]> escreveu: > > > Sebastian Ho wrote: > > > > > > > > > > > Say I retrieve a TO from database and convert it > > > into a actionForm for > > > > display. In this case I have 4 fields for my > > > actionForm but 10 in my TO. > > > > (6 are not needed for display). A user updates the > > > 4 fields and the > > > > action convert those into TO. In this case, the > > > other 6 fields will be > > > > reset to null(or empty) in my database! > > > > > > > > To prevent this, I actually need to use hidden > > > fields in my JSP or some > > > > other ugly solutions in my Action class. They are > > > still dependent on > > > > each others afterall. > > > > > > You can handle this several ways... > > > > > > For example, one solution is you create a > > > TransferObject that refers to > > > only the fields you care about - in this case the 4 > > > fields you > > > mentioned. So your call to the business layer would > > > return that > > > TransferObject and you could then convert that > > > easily to your form > > > (using BeanUtils). Then going back the other way > > > your business layer > > > would take as an arguemnt the same type of > > > TransferObject. > > > > > > I actually don't prefer the above, though, because > > > say later on you > > > decide you want to add another field to your form > > > now your backend has > > > to worry about handling a new object with different > > > fields. > > > > > > I think the best solution is to simply make another > > > call to get back the > > > initial TO from the db, then simply use BeanUtils to > > > populate that TO > > > with the form fields. It will only set the fields in > > > which it has the > > > same names for so your other data will be fine. > > > > > > So it looks like... > > > > > > TransferObject to = > > > BackendEnd.getMyTransferObject(..); > > > MyForm myForm = (MyForm)form; > > > BeanUtils.copyProperties( to, myForm); > > > BackEnd.doUpdate( to ); > > > > > > Pretty simple I think. Just make sure your > > > ActionForm doesn't contain > > > properties that you don't care about editing > > > otherwise it will > > > over-write the TO properties. If the JSP form is > > > going to be very > > > dyanmic, as in it will sometimes have some > > >
RE: ActionForm and Transfer Object
Seems to me that the issue is in how you go about hitting the database with your TO. Basically I'm +1 on "solution #2". Typically the only hidden html field I use routinely is for the key of the record. If you put all of the "not being updated fields" into the html, youre creating potential problems. 1) If you have a page which will update field A, but have field B as hidden, and while the user on this screen is on the phone, someone else updates field B, when the user saves his record, the other guy's field B will be overwritten. 2) People can potentially just view source on the html and discover how to directly manipulate the database in ways you may or may not want. > -Original Message- > From: Leandro Melo [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 25, 2004 10:18 AM > To: Struts Users Mailing List > Subject: Re: ActionForm and Transfer Object > > > Rick, > i agree with you, i also use BeanUtils to populate my > forms. > But, this doesn't go far way from having your > ActionForms dependent on your TOs (or CustomTOs, > doesn' t matter). > As Sebastian said, i've heard a lot that TOs should > mirror or shouldn't be coupled to your ActionForms, > but i really don't how it's possible to build a very > modular architecture without this coupling. > > > > > --- Rick Reumann <[EMAIL PROTECTED]> escreveu: > > Sebastian Ho wrote: > > > > > > > > Say I retrieve a TO from database and convert it > > into a actionForm for > > > display. In this case I have 4 fields for my > > actionForm but 10 in my TO. > > > (6 are not needed for display). A user updates the > > 4 fields and the > > > action convert those into TO. In this case, the > > other 6 fields will be > > > reset to null(or empty) in my database! > > > > > > To prevent this, I actually need to use hidden > > fields in my JSP or some > > > other ugly solutions in my Action class. They are > > still dependent on > > > each others afterall. > > > > You can handle this several ways... > > > > For example, one solution is you create a > > TransferObject that refers to > > only the fields you care about - in this case the 4 > > fields you > > mentioned. So your call to the business layer would > > return that > > TransferObject and you could then convert that > > easily to your form > > (using BeanUtils). Then going back the other way > > your business layer > > would take as an arguemnt the same type of > > TransferObject. > > > > I actually don't prefer the above, though, because > > say later on you > > decide you want to add another field to your form > > now your backend has > > to worry about handling a new object with different > > fields. > > > > I think the best solution is to simply make another > > call to get back the > > initial TO from the db, then simply use BeanUtils to > > populate that TO > > with the form fields. It will only set the fields in > > which it has the > > same names for so your other data will be fine. > > > > So it looks like... > > > > TransferObject to = > > BackendEnd.getMyTransferObject(..); > > MyForm myForm = (MyForm)form; > > BeanUtils.copyProperties( to, myForm); > > BackEnd.doUpdate( to ); > > > > Pretty simple I think. Just make sure your > > ActionForm doesn't contain > > properties that you don't care about editing > > otherwise it will > > over-write the TO properties. If the JSP form is > > going to be very > > dyanmic, as in it will sometimes have some > > properties and sometimes have > > others, then you will have to use more complex > > 'tricks' such as using > > hidden variables.. or I'd just prefer to manually > > set the TO fields in > > the Action. > > > > -- > > Rick > > > > > - > > To unsubscribe, e-mail: > > [EMAIL PROTECTED] > > For additional commands, e-mail: > > [EMAIL PROTECTED] > > > > > > > > > > ___ > Yahoo! Acesso Grátis - navegue de graça com conexão de qualidade! > http://br.acesso.yahoo.com/ > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ActionForm and Transfer Object
I have been trying out a new solution to this "age-old" conundrum. I have a UserContainer implements Map object in the Session object. The UserContainer object implements the Map as indicated in my http://wiki.apache.org/struts/StrutsCatalogInstrumentableForms, except that the UserContainer does not extend ActionForm. I populate and de-poplulate the UserContainer in the model for each request as indicated in a workflow. This is particularly easy to employ with the BeanMap implementation that can be instrumented. Michael Leandro Melo wrote: Rick, i agree with you, i also use BeanUtils to populate my forms. But, this doesn't go far way from having your ActionForms dependent on your TOs (or CustomTOs, doesn' t matter). As Sebastian said, i've heard a lot that TOs should mirror or shouldn't be coupled to your ActionForms, but i really don't how it's possible to build a very modular architecture without this coupling. --- Rick Reumann <[EMAIL PROTECTED]> escreveu: Sebastian Ho wrote: Say I retrieve a TO from database and convert it into a actionForm for display. In this case I have 4 fields for my actionForm but 10 in my TO. (6 are not needed for display). A user updates the 4 fields and the action convert those into TO. In this case, the other 6 fields will be reset to null(or empty) in my database! To prevent this, I actually need to use hidden fields in my JSP or some other ugly solutions in my Action class. They are still dependent on each others afterall. You can handle this several ways... For example, one solution is you create a TransferObject that refers to only the fields you care about - in this case the 4 fields you mentioned. So your call to the business layer would return that TransferObject and you could then convert that easily to your form (using BeanUtils). Then going back the other way your business layer would take as an arguemnt the same type of TransferObject. I actually don't prefer the above, though, because say later on you decide you want to add another field to your form now your backend has to worry about handling a new object with different fields. I think the best solution is to simply make another call to get back the initial TO from the db, then simply use BeanUtils to populate that TO with the form fields. It will only set the fields in which it has the same names for so your other data will be fine. So it looks like... TransferObject to = BackendEnd.getMyTransferObject(..); MyForm myForm = (MyForm)form; BeanUtils.copyProperties( to, myForm); BackEnd.doUpdate( to ); Pretty simple I think. Just make sure your ActionForm doesn't contain properties that you don't care about editing otherwise it will over-write the TO properties. If the JSP form is going to be very dyanmic, as in it will sometimes have some properties and sometimes have others, then you will have to use more complex 'tricks' such as using hidden variables.. or I'd just prefer to manually set the TO fields in the Action. -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ___ Yahoo! Acesso Grátis - navegue de graça com conexão de qualidade! http://br.acesso.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ActionForm and Transfer Object
Rick, i agree with you, i also use BeanUtils to populate my forms. But, this doesn't go far way from having your ActionForms dependent on your TOs (or CustomTOs, doesn' t matter). As Sebastian said, i've heard a lot that TOs should mirror or shouldn't be coupled to your ActionForms, but i really don't how it's possible to build a very modular architecture without this coupling. --- Rick Reumann <[EMAIL PROTECTED]> escreveu: > Sebastian Ho wrote: > > > > > Say I retrieve a TO from database and convert it > into a actionForm for > > display. In this case I have 4 fields for my > actionForm but 10 in my TO. > > (6 are not needed for display). A user updates the > 4 fields and the > > action convert those into TO. In this case, the > other 6 fields will be > > reset to null(or empty) in my database! > > > > To prevent this, I actually need to use hidden > fields in my JSP or some > > other ugly solutions in my Action class. They are > still dependent on > > each others afterall. > > You can handle this several ways... > > For example, one solution is you create a > TransferObject that refers to > only the fields you care about - in this case the 4 > fields you > mentioned. So your call to the business layer would > return that > TransferObject and you could then convert that > easily to your form > (using BeanUtils). Then going back the other way > your business layer > would take as an arguemnt the same type of > TransferObject. > > I actually don't prefer the above, though, because > say later on you > decide you want to add another field to your form > now your backend has > to worry about handling a new object with different > fields. > > I think the best solution is to simply make another > call to get back the > initial TO from the db, then simply use BeanUtils to > populate that TO > with the form fields. It will only set the fields in > which it has the > same names for so your other data will be fine. > > So it looks like... > > TransferObject to = > BackendEnd.getMyTransferObject(..); > MyForm myForm = (MyForm)form; > BeanUtils.copyProperties( to, myForm); > BackEnd.doUpdate( to ); > > Pretty simple I think. Just make sure your > ActionForm doesn't contain > properties that you don't care about editing > otherwise it will > over-write the TO properties. If the JSP form is > going to be very > dyanmic, as in it will sometimes have some > properties and sometimes have > others, then you will have to use more complex > 'tricks' such as using > hidden variables.. or I'd just prefer to manually > set the TO fields in > the Action. > > -- > Rick > > - > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > ___ Yahoo! Acesso Grátis - navegue de graça com conexão de qualidade! http://br.acesso.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ActionForm and Transfer Object
If you make TO part of your form, life will be much easier.
e.g.
public class PlayerDetailsForm extends ValidatorForm {
private PlayerDetailsTO mPlayer;
public void setPlayerDetails(PlayerDetailsTO player) {
mPlayer = player;
}
public PlayerDetailsTO getPlayerDetails() {
return mPlayer;
}
}
- Original Message -
From: "Sebastian Ho" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
Sent: Wednesday, August 25, 2004 11:52 AM
Subject: ActionForm and Transfer Object
> Hi
>
> People have been telling me that ActionForm should not be dependent on
> your TO. Simple because actionForm is for presentation and TO for your
> business requirement. Sounds logical and right way to go.
>
> Now that I started developing using struts, it is actually not that
> simple.
>
> Say I retrieve a TO from database and convert it into a actionForm for
> display. In this case I have 4 fields for my actionForm but 10 in my TO.
> (6 are not needed for display). A user updates the 4 fields and the
> action convert those into TO. In this case, the other 6 fields will be
> reset to null(or empty) in my database!
>
> To prevent this, I actually need to use hidden fields in my JSP or some
> other ugly solutions in my Action class. They are still dependent on
> each others afterall.
>
> Is there a solution to this or I am missing something here?
>
> Thanks
>
> Sebastian Ho
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: ActionForm and Transfer Object
I don't really like the first solution. Second solution sounds promising but there's an extra call. But thats still better than the first solution or using hidden fields in JSP. I thought of putting the TO in session as well to prevent another DB call. But that will make everything very confusing and complex on the web tier.. Still looking for an ideal solution. This problem is quite common I think, someone here must have a best practices for this so I am waiting for one.. Thanks Rick. Sebastian Ho On Wed, 2004-08-25 at 14:39, Rick Reumann wrote: > Sebastian Ho wrote: > > > > > Say I retrieve a TO from database and convert it into a actionForm for > > display. In this case I have 4 fields for my actionForm but 10 in my TO. > > (6 are not needed for display). A user updates the 4 fields and the > > action convert those into TO. In this case, the other 6 fields will be > > reset to null(or empty) in my database! > > > > To prevent this, I actually need to use hidden fields in my JSP or some > > other ugly solutions in my Action class. They are still dependent on > > each others afterall. > > You can handle this several ways... > > For example, one solution is you create a TransferObject that refers to > only the fields you care about - in this case the 4 fields you > mentioned. So your call to the business layer would return that > TransferObject and you could then convert that easily to your form > (using BeanUtils). Then going back the other way your business layer > would take as an arguemnt the same type of TransferObject. > > I actually don't prefer the above, though, because say later on you > decide you want to add another field to your form now your backend has > to worry about handling a new object with different fields. > > I think the best solution is to simply make another call to get back the > initial TO from the db, then simply use BeanUtils to populate that TO > with the form fields. It will only set the fields in which it has the > same names for so your other data will be fine. > > So it looks like... > > TransferObject to = BackendEnd.getMyTransferObject(..); > MyForm myForm = (MyForm)form; > BeanUtils.copyProperties( to, myForm); > BackEnd.doUpdate( to ); > > Pretty simple I think. Just make sure your ActionForm doesn't contain > properties that you don't care about editing otherwise it will > over-write the TO properties. If the JSP form is going to be very > dyanmic, as in it will sometimes have some properties and sometimes have > others, then you will have to use more complex 'tricks' such as using > hidden variables.. or I'd just prefer to manually set the TO fields in > the Action. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ActionForm and Transfer Object
Hi, I think the usual convention of not using ActionForm in Business tier is to separate these tiers. This helps to reduce business tier dependency on Web tier. I read a design pattern and modified it to my needs . Here is what i do. 1. Make a tagging interface like AppForm which is generalized . All the actionForm classes extend ActionForm and implement AppForm. Now When i pass it to business tier i simply accept AppForm . Then i can type cast it to required class in business tier . I used it to simply prevent seeing ActionForm in Business tier . I don't know whether it is good idea. but i really wanted to get rid of the hassle in moving values across form and TO. If some other framework , ( other than struts) there will be some way to get value from screens and we will make all those object also implement AppForm . Now one can say that at that time we will make a tagging interface ActionForm . it is ok. but Still it will make it look like a badly written code. ciao Sebastian Ho wrote: Hi People have been telling me that ActionForm should not be dependent on your TO. Simple because actionForm is for presentation and TO for your business requirement. Sounds logical and right way to go. Now that I started developing using struts, it is actually not that simple. Say I retrieve a TO from database and convert it into a actionForm for display. In this case I have 4 fields for my actionForm but 10 in my TO. (6 are not needed for display). A user updates the 4 fields and the action convert those into TO. In this case, the other 6 fields will be reset to null(or empty) in my database! To prevent this, I actually need to use hidden fields in my JSP or some other ugly solutions in my Action class. They are still dependent on each others afterall. Is there a solution to this or I am missing something here? Thanks Sebastian Ho - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ActionForm and Transfer Object
Sebastian Ho wrote: Say I retrieve a TO from database and convert it into a actionForm for display. In this case I have 4 fields for my actionForm but 10 in my TO. (6 are not needed for display). A user updates the 4 fields and the action convert those into TO. In this case, the other 6 fields will be reset to null(or empty) in my database! To prevent this, I actually need to use hidden fields in my JSP or some other ugly solutions in my Action class. They are still dependent on each others afterall. You can handle this several ways... For example, one solution is you create a TransferObject that refers to only the fields you care about - in this case the 4 fields you mentioned. So your call to the business layer would return that TransferObject and you could then convert that easily to your form (using BeanUtils). Then going back the other way your business layer would take as an arguemnt the same type of TransferObject. I actually don't prefer the above, though, because say later on you decide you want to add another field to your form now your backend has to worry about handling a new object with different fields. I think the best solution is to simply make another call to get back the initial TO from the db, then simply use BeanUtils to populate that TO with the form fields. It will only set the fields in which it has the same names for so your other data will be fine. So it looks like... TransferObject to = BackendEnd.getMyTransferObject(..); MyForm myForm = (MyForm)form; BeanUtils.copyProperties( to, myForm); BackEnd.doUpdate( to ); Pretty simple I think. Just make sure your ActionForm doesn't contain properties that you don't care about editing otherwise it will over-write the TO properties. If the JSP form is going to be very dyanmic, as in it will sometimes have some properties and sometimes have others, then you will have to use more complex 'tricks' such as using hidden variables.. or I'd just prefer to manually set the TO fields in the Action. -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ActionForm and Transfer Object
Hi People have been telling me that ActionForm should not be dependent on your TO. Simple because actionForm is for presentation and TO for your business requirement. Sounds logical and right way to go. Now that I started developing using struts, it is actually not that simple. Say I retrieve a TO from database and convert it into a actionForm for display. In this case I have 4 fields for my actionForm but 10 in my TO. (6 are not needed for display). A user updates the 4 fields and the action convert those into TO. In this case, the other 6 fields will be reset to null(or empty) in my database! To prevent this, I actually need to use hidden fields in my JSP or some other ugly solutions in my Action class. They are still dependent on each others afterall. Is there a solution to this or I am missing something here? Thanks Sebastian Ho - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
