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
