However that could easily be remedied because the Action can call DynaActionForm.getMap() and pass on the hashmap heart of the DynaActionForm.
It still leaves though the problem that the EJB knows nothing about what is in those hashmaps. Plus it must type-cast all the values. (Assuming as well that all the validation has been done if this was a DynaValidatorActionForm)
It would be interesting challenge, if I didn't have the suspicion that the whole of the Struts community would still frown on it.
Adam
On 03/18/2004 12:20 AM Robert Taylor wrote:
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]
-- 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]
