Adam, its frowned upon to pass a web tier object (XXXXActionForm) into the business tier. I believe a widely used technique is to use BeanUtils to copy the properties from the XXXXActionForm to a DTO (a Domain Object) which can be passed to the business tier.
robert > -----Original Message----- > From: Adam Hardy [mailto:[EMAIL PROTECTED] > Sent: Wednesday, March 17, 2004 5:57 PM > To: Struts Users Mailing List > Subject: Re: action - delegate - facade > > > Great book. Thanks for the link. > > I think I need more knowledge of xdoclet before I make my mind up > though. This offers alot to mull over. Plus I'm also quite keen to use > faster, quicker patterns. > > I use dynaactionforms in struts almost exclusively and regarding this > Data Transfer Hashmap, it irritates me that the data must be transferred > out of one hashmap into another. > > In fact it would be ideal to be able to transfer the data in the > dynaactionform right down the line to the entity bean. > > The data elements of each form are primarily defined in the > struts-config.xml, so I can't see a clean way of telling the entity bean > (or any other object) how to get the data out. > > > > > On 03/17/2004 11:33 PM [EMAIL PROTECTED] wrote: > >>Actually this is a pattern mentioned in "EJB Design Patterns - Advanced > >>Patterns Processes and Idioms" called Data Transfer HashMap. You can > >>download the pdf from TheServerSide.com. It's a pretty good read. The > >>book goes into detail on the pros and cons of this pattern. > >> > > > > > > Well... it wasn't my intention to implement a software pattern :) (I am > > kidding :) form-beans does the same job - I think - but mixes form input > > data with form build data - again, feel free to criticize, afterall I am > > still new with Struts). > > > > > > We already discussed this... but here goes for the rest of the mailing > > list: > > > > - It surely saved me some time > > (I dont have to define on one XML file the beans I need and after that > > execute something to automatically generate the java beans - you have to > > be more carefull though, since you may only encounter some bugs on > > runtime... unless you use strutstestcase/junit) > > > > - made a great work decoupling the presentation from business logic > > (just like with form-beans) > > > > - I dont get confused about what is the user input data and what is the > > data to help build the user form > > > > - it also had another side effect: much less lines for xml configuration > > file... but more files per application (I can live with this :) ) > > > > - it seems easier to reuse "view-beans"/"form-beans" when they are > > decoupled... but i will need more time/experience to support this > > > > > > Thank you for the document. I will read it very carefully and see if > > there is another challenge waiting outside this framework. > > > > Pedro Salgado > > > > > >>http://www.theserverside.com/books/wiley/EJBDesignPatterns/downloads/ejbdesignpatterns.pdf > >> > >> > >>robert > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > struts 1.1 + tomcat 5.0.16 + java 1.4.2 > Linux 2.4.20 Debian > > > --------------------------------------------------------------------- > 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]
