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?
> -----Original Message----- > From: Per Mellqvist [mailto:[EMAIL PROTECTED] > Sent: Friday, November 14, 2003 2:04 PM > To: '[EMAIL PROTECTED]' > Subject: RE: [OS-webwork] Component object setting > > > The ComponentInterceptor as implemented today provides a > reasonable implementation of IoC. It will I'm sure work very > well to provide actions with instances of DAO's or maybe > Hibernate Sessions and such. > > However there is a separate, but perhaps slightly related > issue that ComponentInterceptor "almost" solves. For the sake > of simplicity I will express this in terms of web > applications, although I suspect that the concept might be > transferable to a general XWork discussion. > > Many web applications use the http session to store Data > Transfer Objects between requests. For example the > application might load a UserDTO from the database in one > action, present some of it's values in a jsp form that the > user can edit, and finally write back the new state of the > UserDTO to the database in the next action. > > A way of dealing with this without using the http session > would be to write out all the values to the form (perhaps > using hidden tags for some data), and then let webwork copy > all values into a new instance of the UserDTO with the > ParameterInterceptor. Making sure all the fields of the > object are in some way present in the jsp becomes tedious and > bug prone when the DTO contains a lot of fields and maybe a > graph of connected object (let's say a couple of AddressDTO > instances). > > Jason suggests saving the DTO objects in the http session > manually. This is essentially how our web applications have > been implemented in the past. The problem with this approach > is that in a large application it becomes difficult to get a > good idea of what is stored in the http session throughout > the application. Also looking at a single action you can not > tell what it expects to be present in the session without > reading all the code for that action. > > These are issues that would be solved by moving the session > related code to an interceptor. The interceptor could examine > the interfaces that the action implements to determine what > fields of the action to set with objects from the session, > and what fields to write back to the session after the action > completes. This would also allow programmers to easily > identify what each action expects from the session. > > An xml configuration file could contain any extra information > necessary, which would also provide a single location where > programmers could see everything that the application puts in > the session. > > OK, so you're starting to get my drift. Session scope > components in webwork allready provide almost all of this, > except writing back the state of the action field to the > session in the interceptor's after() method. > > Perhaps some more tweaks would be benefitial as far as > configuration options in components.xml etc, but this is the > basic idea. > > If someone feels that this is conceptually a completely > different beast from what components are today then maybe > this should be a separate interceptor, config file etc. But > as far as I can see this is not incompatible with the general > idea of components and the IoC in webwork today. > > Since we are on a tight schedule we will most likely take a > stab at this ourselves at Tradedoubler. But of course we > would prefer something like this in the official webwork > release rather than having our own custom behaviour. > > What do other people think? Is this a valid idea? > > // Per Mellqvist > > -----Original Message----- > From: Jason Carreira [mailto:[EMAIL PROTECTED] > Sent: Friday, November 14, 2003 3:48 PM > To: [EMAIL PROTECTED] > Subject: RE: [OS-webwork] Component object setting > > The ComponentInterceptor will create and store your component > in the Session. It will not pick up the fact that you've > created a new one and put it into your Action. > > I think we're talking about a persistent object here, right? > IMO this is not a good fit for a component. A good component > would be something like a DAO which will load and save > objects for you, not the objects themselves. > > For doing this kind of editing, you're going to want to save > your Objects in the Session manually. You could make your > Action ModelDriven and have something like this: > > Public Object getModel() { > Map session = ActionContext.getContext().getSession(); > MyObject obj = session.get(MY_OBJECT_KEY); > if (obj == null) { > obj = // get an object or create a new one > session.put(MY_OBJECT_KEY); > } > return obj; > } > > Then form fields will be set on the obj... > > Jason > > > > ------------------------------------------------------- > 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 ------------------------------------------------------- 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
