Re: Object-oriented encapsulation in Struts - merging Actions and ActionForms
Specifically, what would you change? David --- Dan Jacobs [EMAIL PROTECTED] wrote: [ potentially controversial topic ] Hi all, I have noticed that most of my Struts applications end up being implemented like dismembered objects. I design the controller parts of my Struts applications using object-oriented design techniques, but then I have to transform my designs into an awkward, non-object-oriented form: * What was originally encapsulated object state has to be extracted and isolated as ActionForms. * What were originally methods that acted on encapsulated object state have to become stateless processors in the form of Actions. * The Struts servlet acts like another method-turned-C-function when it resets and assigns property-values in the ActionForms. I can translate in the other direction too. If I take someone else's Struts application, I can derive an effective object model from the relationships between the Actions and ActionForms described in the struts-config.xml file. That's really useful for figuring out what's going on. There's no problem getting all of this to work, and the Struts servlet and framework do some very useful things. But the separation of the Actions from the ActionForms makes it harder to maintain the integrity of the original object-oriented designs. What I'd really like to see is a truly object-oriented approach to the controller, where the state of the web-application is encapsulated as instances of real classes (not just the equivalent of C struts) that are acted on by methods. The methods would be invoked just like Actions are currently invoked, but rather than pass behavior-less data to data-less functions, we could have methods acting on encapsulated object state. Who knows - maybe someday we could even have subclasses and inheritance and constructors and methods with method parameters. If action-mappings could map to methods invoked on named instances, Actions and ActionForms could be merged into real objects, and the object-oriented character of controller designs could be maintained. Is there any compelling reason that this shouldn't be done? I can get the object-oriented behavior I want using JPlates, but I don't want to have to duplicate all of the other contributions that Struts offers for web-applications. I use JPlates with Struts, but I'd be happier with a more object-oriented version of Struts. Dan Jacobs JPlates Inc. http://www.jplates.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Object-oriented encapsulation in Struts - merging Actions and ActionForms
The kind of change I'm suggesting is not small or incremental. It's pretty fundamental. Suppose you've got an ActionForm that represents the state of some presentation object. It has no object-oriented behavior at all. Just ways to read and write its fields. Now suppose you've got some Actions that are meant to do things based on the ActionForm. They're like C functions in that they just compute, and are not associated with any instance data. They can access the equivalent of global data from the session, but they're not really methods of objects. Now combine them. Define a class where the instance state is basically the same as what was in the ActionForm, and that defines methods that do the same things as were done by the Actions. But instead of passing an ActionForm to an Action, just invoke a method on an object. The rest of the implementation is a matter of reflection tricks, and there probably has to be some additional framework support to compensate for the lack of closures in Java, and make the methods act like objects that conform to some required interface. Does that make sense? Dan Jacobs JPlates Inc. http://www.jplates.com -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 24, 2003 8:46 AM To: Struts Users Mailing List Subject: Re: Object-oriented encapsulation in Struts - merging Actions and ActionForms Specifically, what would you change? David --- Dan Jacobs [EMAIL PROTECTED] wrote: [ potentially controversial topic ] Hi all, I have noticed that most of my Struts applications end up being implemented like dismembered objects. I design the controller parts of my Struts applications using object-oriented design techniques, but then I have to transform my designs into an awkward, non-object-oriented form: * What was originally encapsulated object state has to be extracted and isolated as ActionForms. * What were originally methods that acted on encapsulated object state have to become stateless processors in the form of Actions. * The Struts servlet acts like another method-turned-C-function when it resets and assigns property-values in the ActionForms. I can translate in the other direction too. If I take someone else's Struts application, I can derive an effective object model from the relationships between the Actions and ActionForms described in the struts-config.xml file. That's really useful for figuring out what's going on. There's no problem getting all of this to work, and the Struts servlet and framework do some very useful things. But the separation of the Actions from the ActionForms makes it harder to maintain the integrity of the original object-oriented designs. What I'd really like to see is a truly object-oriented approach to the controller, where the state of the web-application is encapsulated as instances of real classes (not just the equivalent of C struts) that are acted on by methods. The methods would be invoked just like Actions are currently invoked, but rather than pass behavior-less data to data-less functions, we could have methods acting on encapsulated object state. Who knows - maybe someday we could even have subclasses and inheritance and constructors and methods with method parameters. If action-mappings could map to methods invoked on named instances, Actions and ActionForms could be merged into real objects, and the object-oriented character of controller designs could be maintained. Is there any compelling reason that this shouldn't be done? I can get the object-oriented behavior I want using JPlates, but I don't want to have to duplicate all of the other contributions that Struts offers for web-applications. I use JPlates with Struts, but I'd be happier with a more object-oriented version of Struts. Dan Jacobs JPlates Inc. http://www.jplates.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Object-oriented encapsulation in Struts - merging Actions and ActionForms
That makes sense ...but wouldn't that break the MVC pattern by moving the Controller function into the Model? Ted Jones Maritz Inc. [EMAIL PROTECTED] http://www.maritz.com/ -Original Message- From: Dan Jacobs [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 24, 2003 10:40 AM To: [EMAIL PROTECTED]; 'Struts Users Mailing List' Subject: RE: Object-oriented encapsulation in Struts - merging Actions and ActionForms The kind of change I'm suggesting is not small or incremental. It's pretty fundamental. Suppose you've got an ActionForm that represents the state of some presentation object. It has no object-oriented behavior at all. Just ways to read and write its fields. Now suppose you've got some Actions that are meant to do things based on the ActionForm. They're like C functions in that they just compute, and are not associated with any instance data. They can access the equivalent of global data from the session, but they're not really methods of objects. Now combine them. Define a class where the instance state is basically the same as what was in the ActionForm, and that defines methods that do the same things as were done by the Actions. But instead of passing an ActionForm to an Action, just invoke a method on an object. The rest of the implementation is a matter of reflection tricks, and there probably has to be some additional framework support to compensate for the lack of closures in Java, and make the methods act like objects that conform to some required interface. Does that make sense? Dan Jacobs JPlates Inc. http://www.jplates.com -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 24, 2003 8:46 AM To: Struts Users Mailing List Subject: Re: Object-oriented encapsulation in Struts - merging Actions and ActionForms Specifically, what would you change? David --- Dan Jacobs [EMAIL PROTECTED] wrote: [ potentially controversial topic ] Hi all, I have noticed that most of my Struts applications end up being implemented like dismembered objects. I design the controller parts of my Struts applications using object-oriented design techniques, but then I have to transform my designs into an awkward, non-object-oriented form: * What was originally encapsulated object state has to be extracted and isolated as ActionForms. * What were originally methods that acted on encapsulated object state have to become stateless processors in the form of Actions. * The Struts servlet acts like another method-turned-C-function when it resets and assigns property-values in the ActionForms. I can translate in the other direction too. If I take someone else's Struts application, I can derive an effective object model from the relationships between the Actions and ActionForms described in the struts-config.xml file. That's really useful for figuring out what's going on. There's no problem getting all of this to work, and the Struts servlet and framework do some very useful things. But the separation of the Actions from the ActionForms makes it harder to maintain the integrity of the original object-oriented designs. What I'd really like to see is a truly object-oriented approach to the controller, where the state of the web-application is encapsulated as instances of real classes (not just the equivalent of C struts) that are acted on by methods. The methods would be invoked just like Actions are currently invoked, but rather than pass behavior-less data to data-less functions, we could have methods acting on encapsulated object state. Who knows - maybe someday we could even have subclasses and inheritance and constructors and methods with method parameters. If action-mappings could map to methods invoked on named instances, Actions and ActionForms could be merged into real objects, and the object-oriented character of controller designs could be maintained. Is there any compelling reason that this shouldn't be done? I can get the object-oriented behavior I want using JPlates, but I don't want to have to duplicate all of the other contributions that Struts offers for web-applications. I use JPlates with Struts, but I'd be happier with a more object-oriented version of Struts. Dan Jacobs JPlates Inc. http://www.jplates.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Confidentiality Warning: This e-mail contains information
RE: Object-oriented encapsulation in Struts - merging Actions and ActionForms
So you want to combine ActionForm and Action to put the behavior with the data? How would you handle the case where Actions are responding to requests without an associated ActionForm? It's true that ActionForm and Action break encapsulation but this may be an acceptable tradeoff. Thanks for bringing this up; I'll think about it some more and get back to you. David --- Dan Jacobs [EMAIL PROTECTED] wrote: The kind of change I'm suggesting is not small or incremental. It's pretty fundamental. Suppose you've got an ActionForm that represents the state of some presentation object. It has no object-oriented behavior at all. Just ways to read and write its fields. Now suppose you've got some Actions that are meant to do things based on the ActionForm. They're like C functions in that they just compute, and are not associated with any instance data. They can access the equivalent of global data from the session, but they're not really methods of objects. Now combine them. Define a class where the instance state is basically the same as what was in the ActionForm, and that defines methods that do the same things as were done by the Actions. But instead of passing an ActionForm to an Action, just invoke a method on an object. The rest of the implementation is a matter of reflection tricks, and there probably has to be some additional framework support to compensate for the lack of closures in Java, and make the methods act like objects that conform to some required interface. Does that make sense? Dan Jacobs JPlates Inc. http://www.jplates.com -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 24, 2003 8:46 AM To: Struts Users Mailing List Subject: Re: Object-oriented encapsulation in Struts - merging Actions and ActionForms Specifically, what would you change? David --- Dan Jacobs [EMAIL PROTECTED] wrote: [ potentially controversial topic ] Hi all, I have noticed that most of my Struts applications end up being implemented like dismembered objects. I design the controller parts of my Struts applications using object-oriented design techniques, but then I have to transform my designs into an awkward, non-object-oriented form: * What was originally encapsulated object state has to be extracted and isolated as ActionForms. * What were originally methods that acted on encapsulated object state have to become stateless processors in the form of Actions. * The Struts servlet acts like another method-turned-C-function when it resets and assigns property-values in the ActionForms. I can translate in the other direction too. If I take someone else's Struts application, I can derive an effective object model from the relationships between the Actions and ActionForms described in the struts-config.xml file. That's really useful for figuring out what's going on. There's no problem getting all of this to work, and the Struts servlet and framework do some very useful things. But the separation of the Actions from the ActionForms makes it harder to maintain the integrity of the original object-oriented designs. What I'd really like to see is a truly object-oriented approach to the controller, where the state of the web-application is encapsulated as instances of real classes (not just the equivalent of C struts) that are acted on by methods. The methods would be invoked just like Actions are currently invoked, but rather than pass behavior-less data to data-less functions, we could have methods acting on encapsulated object state. Who knows - maybe someday we could even have subclasses and inheritance and constructors and methods with method parameters. If action-mappings could map to methods invoked on named instances, Actions and ActionForms could be merged into real objects, and the object-oriented character of controller designs could be maintained. Is there any compelling reason that this shouldn't be done? I can get the object-oriented behavior I want using JPlates, but I don't want to have to duplicate all of the other contributions that Struts offers for web-applications. I use JPlates with Struts, but I'd be happier with a more object-oriented version of Struts. Dan Jacobs JPlates Inc. http://www.jplates.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http
RE: Object-oriented encapsulation in Struts - merging Actions and ActionForms
The MVC design pattern is an object-oriented design pattern. It is not inconsistent with object-oriented encapsulation! A Struts ActionForm is not part the model in an MVC application. It's really just an odd combination of the dismembered state of the controller and a dismembered partial state of the view. The model, for most Struts applications, is back in the EJB tier. Take a look at the link at http://www.jplates.com about scriptlets. It talks a lot about this common misunderstanding. Separation of *independent* concerns is a driving force behind a lot of object-oriented design patterns. But separation of object-state from the methods that should manage that state is a violation of object-oriented encapsulation. Dan Jacobs JPlates Inc. http://www.jplates.com -Original Message- From: Jones, Ted [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 24, 2003 10:50 AM To: Struts Users Mailing List Cc: [EMAIL PROTECTED] Subject: RE: Object-oriented encapsulation in Struts - merging Actions and ActionForms That makes sense ...but wouldn't that break the MVC pattern by moving the Controller function into the Model? Ted Jones Maritz Inc. [EMAIL PROTECTED] http://www.maritz.com/ -Original Message- From: Dan Jacobs [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 24, 2003 10:40 AM To: [EMAIL PROTECTED]; 'Struts Users Mailing List' Subject: RE: Object-oriented encapsulation in Struts - merging Actions and ActionForms The kind of change I'm suggesting is not small or incremental. It's pretty fundamental. Suppose you've got an ActionForm that represents the state of some presentation object. It has no object-oriented behavior at all. Just ways to read and write its fields. Now suppose you've got some Actions that are meant to do things based on the ActionForm. They're like C functions in that they just compute, and are not associated with any instance data. They can access the equivalent of global data from the session, but they're not really methods of objects. Now combine them. Define a class where the instance state is basically the same as what was in the ActionForm, and that defines methods that do the same things as were done by the Actions. But instead of passing an ActionForm to an Action, just invoke a method on an object. The rest of the implementation is a matter of reflection tricks, and there probably has to be some additional framework support to compensate for the lack of closures in Java, and make the methods act like objects that conform to some required interface. Does that make sense? Dan Jacobs JPlates Inc. http://www.jplates.com -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 24, 2003 8:46 AM To: Struts Users Mailing List Subject: Re: Object-oriented encapsulation in Struts - merging Actions and ActionForms Specifically, what would you change? David --- Dan Jacobs [EMAIL PROTECTED] wrote: [ potentially controversial topic ] Hi all, I have noticed that most of my Struts applications end up being implemented like dismembered objects. I design the controller parts of my Struts applications using object-oriented design techniques, but then I have to transform my designs into an awkward, non-object-oriented form: * What was originally encapsulated object state has to be extracted and isolated as ActionForms. * What were originally methods that acted on encapsulated object state have to become stateless processors in the form of Actions. * The Struts servlet acts like another method-turned-C-function when it resets and assigns property-values in the ActionForms. I can translate in the other direction too. If I take someone else's Struts application, I can derive an effective object model from the relationships between the Actions and ActionForms described in the struts-config.xml file. That's really useful for figuring out what's going on. There's no problem getting all of this to work, and the Struts servlet and framework do some very useful things. But the separation of the Actions from the ActionForms makes it harder to maintain the integrity of the original object-oriented designs. What I'd really like to see is a truly object-oriented approach to the controller, where the state of the web-application is encapsulated as instances of real classes (not just the equivalent of C struts) that are acted on by methods. The methods would be invoked just like Actions are currently invoked, but rather than pass behavior-less data to data-less functions, we could have methods acting on encapsulated object state. Who knows - maybe someday we could even have subclasses and inheritance and constructors and methods with method
RE: Object-oriented encapsulation in Struts - merging Actions and ActionForms
It's perfectly reasonable to have classes that don't have instance variables, though in most cases they're of limited utility. An Action without an ActionForm would correspond to such a class. Dan Jacobs JPlates Inc. http://www.jplates.com -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 24, 2003 11:06 AM To: [EMAIL PROTECTED] Subject: RE: Object-oriented encapsulation in Struts - merging Actions and ActionForms So you want to combine ActionForm and Action to put the behavior with the data? How would you handle the case where Actions are responding to requests without an associated ActionForm? It's true that ActionForm and Action break encapsulation but this may be an acceptable tradeoff. Thanks for bringing this up; I'll think about it some more and get back to you. David --- Dan Jacobs [EMAIL PROTECTED] wrote: The kind of change I'm suggesting is not small or incremental. It's pretty fundamental. Suppose you've got an ActionForm that represents the state of some presentation object. It has no object-oriented behavior at all. Just ways to read and write its fields. Now suppose you've got some Actions that are meant to do things based on the ActionForm. They're like C functions in that they just compute, and are not associated with any instance data. They can access the equivalent of global data from the session, but they're not really methods of objects. Now combine them. Define a class where the instance state is basically the same as what was in the ActionForm, and that defines methods that do the same things as were done by the Actions. But instead of passing an ActionForm to an Action, just invoke a method on an object. The rest of the implementation is a matter of reflection tricks, and there probably has to be some additional framework support to compensate for the lack of closures in Java, and make the methods act like objects that conform to some required interface. Does that make sense? Dan Jacobs JPlates Inc. http://www.jplates.com -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 24, 2003 8:46 AM To: Struts Users Mailing List Subject: Re: Object-oriented encapsulation in Struts - merging Actions and ActionForms Specifically, what would you change? David --- Dan Jacobs [EMAIL PROTECTED] wrote: [ potentially controversial topic ] Hi all, I have noticed that most of my Struts applications end up being implemented like dismembered objects. I design the controller parts of my Struts applications using object-oriented design techniques, but then I have to transform my designs into an awkward, non-object-oriented form: * What was originally encapsulated object state has to be extracted and isolated as ActionForms. * What were originally methods that acted on encapsulated object state have to become stateless processors in the form of Actions. * The Struts servlet acts like another method-turned-C-function when it resets and assigns property-values in the ActionForms. I can translate in the other direction too. If I take someone else's Struts application, I can derive an effective object model from the relationships between the Actions and ActionForms described in the struts-config.xml file. That's really useful for figuring out what's going on. There's no problem getting all of this to work, and the Struts servlet and framework do some very useful things. But the separation of the Actions from the ActionForms makes it harder to maintain the integrity of the original object-oriented designs. What I'd really like to see is a truly object-oriented approach to the controller, where the state of the web-application is encapsulated as instances of real classes (not just the equivalent of C struts) that are acted on by methods. The methods would be invoked just like Actions are currently invoked, but rather than pass behavior-less data to data-less functions, we could have methods acting on encapsulated object state. Who knows - maybe someday we could even have subclasses and inheritance and constructors and methods with method parameters. If action-mappings could map to methods invoked on named instances, Actions and ActionForms could be merged into real objects, and the object-oriented character of controller designs could be maintained. Is there any compelling reason that this shouldn't be done? I can get the object-oriented behavior I want using JPlates, but I don't want to have to duplicate all of the other contributions that Struts
RE: Object-oriented encapsulation in Struts - merging Actions and ActionForms
Dan, You could treat the ActionForm similar to Transfer Objects, which is a completely valid pattern. Furthermore, they are self-contained in the sense that they know how to validate and reset themselves. Actions have a one to many relationship with ActionForms, since there is one Action servicing multiple requests. This in itself does not break any encapsulation rules. What you are suggesting would imply creating a new Action(Form) for every request, and I'm not sure that Struts would remain as performant. Your point about partial view states and partial controller states is relevant, but it is probably more related to HTTP limitations as a stateless protocol. I haven't look at jplates yet, so please bear with me. thanks -jaafar -Original Message- From: Dan Jacobs [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 24, 2003 12:52 PM To: 'Jones, Ted'; 'Struts Users Mailing List' Cc: [EMAIL PROTECTED] Subject: RE: Object-oriented encapsulation in Struts - merging Actions and ActionForms The MVC design pattern is an object-oriented design pattern. It is not inconsistent with object-oriented encapsulation! A Struts ActionForm is not part the model in an MVC application. It's really just an odd combination of the dismembered state of the controller and a dismembered partial state of the view. The model, for most Struts applications, is back in the EJB tier. Take a look at the link at http://www.jplates.com about scriptlets. It talks a lot about this common misunderstanding. Separation of *independent* concerns is a driving force behind a lot of object-oriented design patterns. But separation of object-state from the methods that should manage that state is a violation of object-oriented encapsulation. Dan Jacobs JPlates Inc. http://www.jplates.com -Original Message- From: Jones, Ted [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 24, 2003 10:50 AM To: Struts Users Mailing List Cc: [EMAIL PROTECTED] Subject: RE: Object-oriented encapsulation in Struts - merging Actions and ActionForms That makes sense ...but wouldn't that break the MVC pattern by moving the Controller function into the Model? Ted Jones Maritz Inc. [EMAIL PROTECTED] http://www.maritz.com/ -Original Message- From: Dan Jacobs [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 24, 2003 10:40 AM To: [EMAIL PROTECTED]; 'Struts Users Mailing List' Subject: RE: Object-oriented encapsulation in Struts - merging Actions and ActionForms The kind of change I'm suggesting is not small or incremental. It's pretty fundamental. Suppose you've got an ActionForm that represents the state of some presentation object. It has no object-oriented behavior at all. Just ways to read and write its fields. Now suppose you've got some Actions that are meant to do things based on the ActionForm. They're like C functions in that they just compute, and are not associated with any instance data. They can access the equivalent of global data from the session, but they're not really methods of objects. Now combine them. Define a class where the instance state is basically the same as what was in the ActionForm, and that defines methods that do the same things as were done by the Actions. But instead of passing an ActionForm to an Action, just invoke a method on an object. The rest of the implementation is a matter of reflection tricks, and there probably has to be some additional framework support to compensate for the lack of closures in Java, and make the methods act like objects that conform to some required interface. Does that make sense? Dan Jacobs JPlates Inc. http://www.jplates.com -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 24, 2003 8:46 AM To: Struts Users Mailing List Subject: Re: Object-oriented encapsulation in Struts - merging Actions and ActionForms Specifically, what would you change? David --- Dan Jacobs [EMAIL PROTECTED] wrote: [ potentially controversial topic ] Hi all, I have noticed that most of my Struts applications end up being implemented like dismembered objects. I design the controller parts of my Struts applications using object-oriented design techniques, but then I have to transform my designs into an awkward, non-object-oriented form: * What was originally encapsulated object state has to be extracted and isolated as ActionForms. * What were originally methods that acted on encapsulated object state have to become stateless processors in the form of Actions. * The Struts servlet acts like another method-turned-C-function when it resets and assigns property-values in the ActionForms. I can translate in the other direction too. If I take someone else's Struts application, I can derive an effective object model from the relationships between
Re: Object-oriented encapsulation in Struts - merging Actions and ActionForms
- Original Message - From: Dan Jacobs [EMAIL PROTECTED] To: [EMAIL PROTECTED]; 'Struts Users Mailing List' [EMAIL PROTECTED] Sent: Tuesday, June 24, 2003 10:39 AM Subject: RE: Object-oriented encapsulation in Struts - merging Actions and ActionForms The kind of change I'm suggesting is not small or incremental. It's pretty fundamental. Suppose you've got an ActionForm that represents the state of some presentation object. It has no object-oriented behavior at all. Just ways to read and write its fields. The designed behaviors of form beans (instances of ActionForm) are the same as data buffers on web forms. Now suppose you've got some Actions that are meant to do things based on the ActionForm. They're like C functions in that they just compute, and are not associated with any instance data. They can access the equivalent of global data from the session, but they're not really methods of objects. The designed behaviors of actions are to operate the data buffers with environment data. Now combine them. Define a class where the instance state is basically the same as what was in the ActionForm, and that defines methods that do the same things as were done by the Actions. But instead of passing an ActionForm to an Action, just invoke a method on an object. There is nothing in the action classes that prevents you from creating your faviorable objects in your faviorable MVC patterns with your faviorable methods. The hard question is that how can I describe this idea as a *fundamental* advance to the Struts framework? Thanks Craig for giving us so much room to innovate within the framework. The rest of the implementation is a matter of reflection tricks, and there probably has to be some additional framework support to compensate for the lack of closures in Java, and make the methods act like objects that conform to some required interface. Does that make sense? Dan Jacobs JPlates Inc. http://www.jplates.com Jing -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 24, 2003 8:46 AM To: Struts Users Mailing List Subject: Re: Object-oriented encapsulation in Struts - merging Actions and ActionForms Specifically, what would you change? David --- Dan Jacobs [EMAIL PROTECTED] wrote: [ potentially controversial topic ] Hi all, I have noticed that most of my Struts applications end up being implemented like dismembered objects. I design the controller parts of my Struts applications using object-oriented design techniques, but then I have to transform my designs into an awkward, non-object-oriented form: * What was originally encapsulated object state has to be extracted and isolated as ActionForms. * What were originally methods that acted on encapsulated object state have to become stateless processors in the form of Actions. * The Struts servlet acts like another method-turned-C-function when it resets and assigns property-values in the ActionForms. I can translate in the other direction too. If I take someone else's Struts application, I can derive an effective object model from the relationships between the Actions and ActionForms described in the struts-config.xml file. That's really useful for figuring out what's going on. There's no problem getting all of this to work, and the Struts servlet and framework do some very useful things. But the separation of the Actions from the ActionForms makes it harder to maintain the integrity of the original object-oriented designs. What I'd really like to see is a truly object-oriented approach to the controller, where the state of the web-application is encapsulated as instances of real classes (not just the equivalent of C struts) that are acted on by methods. The methods would be invoked just like Actions are currently invoked, but rather than pass behavior-less data to data-less functions, we could have methods acting on encapsulated object state. Who knows - maybe someday we could even have subclasses and inheritance and constructors and methods with method parameters. If action-mappings could map to methods invoked on named instances, Actions and ActionForms could be merged into real objects, and the object-oriented character of controller designs could be maintained. Is there any compelling reason that this shouldn't be done? I can get the object-oriented behavior I want using JPlates, but I don't want to have to duplicate all of the other contributions that Struts offers for web-applications. I use JPlates with Struts, but I'd be happier with a more object-oriented version of Struts. Dan Jacobs JPlates Inc. http://www.jplates.com
RE: Object-oriented encapsulation in Struts - merging Actions and ActionForms
Hi Jaafar, I agree with some of your points, but not all. If you replace the old concept of ActionForm with a new controller-object concept, where the controller object encapsulates aspects of the session state and the behavior relevant to manipulating that state, then you only create a new controller object at the points where the old system would create an ActionForm. You want the object's state to persist across multiple requests. I also agree that the root cause of a lot of difficulty is trying to build interactive, stateful behavior on top of HTTP. But given that we have HttpSession objects and session-cookies, etc., there is no reason why we shouldn't use good object-oriented programming practices for every aspect of our web-based MVC applications. JPlates provides that for the view parts, and Struts can do so for the controller. Even though I've been working with JPlates for a long time now, I'm still finding that I have to continually un-learn a lot of bad habits in order to make proper use of object-oriented design patterns in web-apps. Dan Jacobs JPlates Inc. http://www.jplates.com -Original Message- From: El Harouchi, Jaafar [IT] [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 24, 2003 12:09 PM To: 'Struts Users Mailing List' Subject: RE: Object-oriented encapsulation in Struts - merging Actions and ActionForms Dan, You could treat the ActionForm similar to Transfer Objects, which is a completely valid pattern. Furthermore, they are self-contained in the sense that they know how to validate and reset themselves. Actions have a one to many relationship with ActionForms, since there is one Action servicing multiple requests. This in itself does not break any encapsulation rules. What you are suggesting would imply creating a new Action(Form) for every request, and I'm not sure that Struts would remain as performant. Your point about partial view states and partial controller states is relevant, but it is probably more related to HTTP limitations as a stateless protocol. I haven't look at jplates yet, so please bear with me. thanks -jaafar -Original Message- From: Dan Jacobs [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 24, 2003 12:52 PM To: 'Jones, Ted'; 'Struts Users Mailing List' Cc: [EMAIL PROTECTED] Subject: RE: Object-oriented encapsulation in Struts - merging Actions and ActionForms The MVC design pattern is an object-oriented design pattern. It is not inconsistent with object-oriented encapsulation! A Struts ActionForm is not part the model in an MVC application. It's really just an odd combination of the dismembered state of the controller and a dismembered partial state of the view. The model, for most Struts applications, is back in the EJB tier. Take a look at the link at http://www.jplates.com about scriptlets. It talks a lot about this common misunderstanding. Separation of *independent* concerns is a driving force behind a lot of object-oriented design patterns. But separation of object-state from the methods that should manage that state is a violation of object-oriented encapsulation. Dan Jacobs JPlates Inc. http://www.jplates.com -Original Message- From: Jones, Ted [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 24, 2003 10:50 AM To: Struts Users Mailing List Cc: [EMAIL PROTECTED] Subject: RE: Object-oriented encapsulation in Struts - merging Actions and ActionForms That makes sense ...but wouldn't that break the MVC pattern by moving the Controller function into the Model? Ted Jones Maritz Inc. [EMAIL PROTECTED] http://www.maritz.com/ -Original Message- From: Dan Jacobs [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 24, 2003 10:40 AM To: [EMAIL PROTECTED]; 'Struts Users Mailing List' Subject: RE: Object-oriented encapsulation in Struts - merging Actions and ActionForms The kind of change I'm suggesting is not small or incremental. It's pretty fundamental. Suppose you've got an ActionForm that represents the state of some presentation object. It has no object-oriented behavior at all. Just ways to read and write its fields. Now suppose you've got some Actions that are meant to do things based on the ActionForm. They're like C functions in that they just compute, and are not associated with any instance data. They can access the equivalent of global data from the session, but they're not really methods of objects. Now combine them. Define a class where the instance state is basically the same as what was in the ActionForm, and that defines methods that do the same things as were done by the Actions. But instead of passing an ActionForm to an Action, just invoke a method on an object. The rest of the implementation is a matter of reflection tricks, and there probably has to be some additional framework support
RE: Object-oriented encapsulation in Struts - merging Actions and ActionForms
I've never used it but I believe that the WebWork framework (http://sourceforge.net/projects/opensymphony) is designed in just this way. The action is basically just a JavaBean with an additional execute method. -Original Message- From: Dan Jacobs [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 24, 2003 8:22 AM To: [EMAIL PROTECTED] Subject: Object-oriented encapsulation in Struts - merging Actions and ActionForms [ potentially controversial topic ] Hi all, I have noticed that most of my Struts applications end up being implemented like dismembered objects. I design the controller parts of my Struts applications using object-oriented design techniques, but then I have to transform my designs into an awkward, non-object-oriented form: * What was originally encapsulated object state has to be extracted and isolated as ActionForms. * What were originally methods that acted on encapsulated object state have to become stateless processors in the form of Actions. * The Struts servlet acts like another method-turned-C-function when it resets and assigns property-values in the ActionForms. I can translate in the other direction too. If I take someone else's Struts application, I can derive an effective object model from the relationships between the Actions and ActionForms described in the struts-config.xml file. That's really useful for figuring out what's going on. There's no problem getting all of this to work, and the Struts servlet and framework do some very useful things. But the separation of the Actions from the ActionForms makes it harder to maintain the integrity of the original object-oriented designs. What I'd really like to see is a truly object-oriented approach to the controller, where the state of the web-application is encapsulated as instances of real classes (not just the equivalent of C struts) that are acted on by methods. The methods would be invoked just like Actions are currently invoked, but rather than pass behavior-less data to data-less functions, we could have methods acting on encapsulated object state. Who knows - maybe someday we could even have subclasses and inheritance and constructors and methods with method parameters. If action-mappings could map to methods invoked on named instances, Actions and ActionForms could be merged into real objects, and the object-oriented character of controller designs could be maintained. Is there any compelling reason that this shouldn't be done? I can get the object-oriented behavior I want using JPlates, but I don't want to have to duplicate all of the other contributions that Struts offers for web-applications. I use JPlates with Struts, but I'd be happier with a more object-oriented version of Struts. Dan Jacobs JPlates Inc. http://www.jplates.com - 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]
