In an initial implementation it would be OK to receive an "empty" DTO (whatever comes out of the default constructor), with the first request to the action.
Obviously the DTO will in most cases be loaded from the database based on some input from the user, so this part would be a good fit for normal action code. When the flow moves on to a different part of the application logic it would also be nice to be able to cleanup the session. In a more advanced implementation maybe this could be defined on an action or action-alias level. Which session scoped DTOs each action expects to receive, and which ones it should set in the session after action invocation. That way my initial action that loads the DTO from the database would only be configured to set the DTO in the session (not receive one), While the following action might both receive and set the DTO. Finally the last action in this application flow would only receive and not set the DTO I don't know. Haven't thought this all the way through yet. It is hard to find a good balance between ease of use and power of configuration. // Per Mellqvist -----Original Message----- From: Jason Carreira [mailto:[EMAIL PROTECTED] Sent: Friday, November 14, 2003 8:15 PM To: [EMAIL PROTECTED] Subject: RE: [OS-webwork] Component object setting I think that this is a very interesting idea, but the problem is that of object creation... For an Update use-case like this, you don't want to create a NEW DTO, you want to load one from your persistence manager. How do you supply this object factory? ------------------------------------------------------- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
