Re: Theoretical debate
Hookom, Jacob wrote: You threw me for a loop with replying so late to that email-- It just comes down to giving the developer the ability to scale their own layers with JSF like you said below. If I want ActionForms, then I will have JSF update request/session scope beans that are only for the view. If I want something simpler, then I can have JSF update my business beans themselves. JSP->View Logic/Beans->Business Logic/Beans JSP->Business Logic/Beans PS: Craig, did you get my email to Ed Burns and yourself about a new, faster JSF-specific EL implementation for JSF RI? I did indeed. I'm sure Ed will look at it next week, after Sun returns to operation from our shutdown this week. Best Regards, Jacob Hookom Craig -Original Message- From: Craig McClanahan [mailto:[EMAIL PROTECTED] Sent: Thursday, July 08, 2004 7:35 PM To: Struts Users Mailing List Subject: Re: Theoretical debate Hookom, Jacob wrote: Look at JSF, do you have actions? No, JSF just updates your POJO beans and calls methods on them. Why have an ActionForm or have to create all of these Actions that are simply getter/setter adapters? Please don't be too quick to retort to my supposed anti-struts mindset, but there are other frameworks out there that allow direct interaction with my business objects and don't require a heck of a lot of framework specific coding. (Coming into this discussion late, but figured that my experience on both the Struts and JSF side of things might provide some illuminating food for thought :-) It's instructive, first, to go back to the beginning of Struts development (just over four years ago), and recall why an ActionForm exists in the first place. The only reason we created that abstraction was to deal with some pesky real world problems in designing webapps ... primarily dealing with conversion (where we really punted ... see below), validation, and little things like maintaining the state of checkboxes. Because Struts doesn't have any "user interface component" concept, dealing with those things had to go somewhere -- and a common abstraction at least made it easy to understand. Therefore, the recommended design pattern for a Struts based app becomes: - An ActionForm per input , normally with String-based properties (so you can redisplay invalid input the way users expect you to). - A set of validation rules that are applied for you on the server side, and optionally also on the client side. - If a validation error occurs, Struts takes care of redisplaying the page (with error messages) - If validation succeeds, the application Action is responsibe for performing conversions of the String valued things in the ActionForm to match the underlying model data types, typically by copying them in to DTO/VO type objects and passing them to business logic (although, as others have pointed out, lots of Struts developers have skipped this extra layer). With JSF, the component model takes care of all the responsibilities that Struts uses an ActionForm for, so you don't need one any more. Indeed, I anticipate people will choose one or more (they aren't mutually exclusive) of at least three different styles for building JSF-based webapps: (1) You can bind individual *components* to backing bean properties, similar to how ASP.Net "code behind files" work. This will be most comfortable to VB developers, and is useful when you need to programmatically modify component properties. (2) You can bind component *values* directly to properties in your backing bean, and then provide the business logic as action methods in the same class. Because the components take care of conversion, you're free to use model-oriented data types for such properties, so you don't need to worry about explicit conversion any more. This style will appear to Struts developers like a combination of an Action and an ActionForm in the same class, and will also appeal to the crowd that likes O-O encapsulation :-). (3) You can bind component *values* directly to properties on a VO/DTO object, and bind action events to methods on a separate bean that will either perform the logic directly or delegate to a business logic class. This style will feel more like traditional Struts separated ActionForm and Action classes, but the Action won't have as much to do. It's also a great way to build a webapp on top of existing application infrastructure that provides resuabe VO/DTO and business logic classes already. I believe that all three approaches are valid -- which one you take for a particular application function depends on your use case for that function. You don't have to be exclusive, either. Combine them where it makes sense. Craig McClanahan - To
Re: Theoretical debate
At 11:24 PM 7/8/2004, you wrote: If you've "cheated" on the separation of concerns issues in your existing app, this is going to seem harder. Boy, HOWDIE! This is so often the case. The whole reason for separation of concerns just jumps out at us during these situations. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Theoretical debate
I've been working on an example with AOP on the Controller and View Objects. I have a set of Objects that support the view with controller methods. These methods are supported by aspects to handle exceptions, caching, and chaining of method calls. In result, it's taking an application layer and providing compile time support for the same kind of features that Struts provides-- but slightly faster and framework independent with AspectJ. -Original Message- From: Mike Duffy [mailto:[EMAIL PROTECTED] Sent: Thursday, July 08, 2004 11:10 PM To: Struts Users Mailing List Subject: Re: Theoretical debate One aspect of JSF which I find troubling is, "With JSF, the component model takes care of all the responsibilities that Struts uses an ActionForm form, so you don't need one any more." Most of the JSF examples I've studied use method (2) from Craig's list below: "You can bind component *values* directly to properties in your backing bean, and then provide the business logic as action methods in the same class." As an example of this approach see, Developing Web Interfaces with JSF, http://www.fawcette.com/javapro/2004_01/magazine/features/cschalk/default.as px IMHO, mixing business logic in the backing bean is not a great design. I like the clean separation provided by the Struts action class. Method (3) from Craig's list below seems like a viable solution: "You can bind component *values* directly to properties on a VO/DTO object, and bind action events to methods on a separate bean that will either perform the logic directly or delegate to a business logic class." I've read most of the major articles on JSF. I have not seen method (3) implemented as an example. Does anyone have a link that they can send showing the implementation of method (3)? Does anyone know if there will be a reference implementation for JSF using method (3)? I think it would increase the acceptance of JSF in the Struts community if such a reference implementation was available. Thanks. Mike --- Craig McClanahan <[EMAIL PROTECTED]> wrote: > Hookom, Jacob wrote: > > >Look at JSF, do you have actions? No, JSF just updates your POJO beans and > >calls methods on them. Why have an ActionForm or have to create all of > >these Actions that are simply getter/setter adapters? Please don't be too > >quick to retort to my supposed anti-struts mindset, but there are other > >frameworks out there that allow direct interaction with my business objects > >and don't require a heck of a lot of framework specific coding. > > > > > > > (Coming into this discussion late, but figured that my experience on > both the Struts and JSF side of things might provide some illuminating > food for thought :-) > > It's instructive, first, to go back to the beginning of Struts > development (just over four years ago), and recall why an ActionForm > exists in the first place. The only reason we created that abstraction > was to deal with some pesky real world problems in designing webapps ... > primarily dealing with conversion (where we really punted ... see > below), validation, and little things like maintaining the state of > checkboxes. Because Struts doesn't have any "user interface component" > concept, dealing with those things had to go somewhere -- and a common > abstraction at least made it easy to understand. > > Therefore, the recommended design pattern for a Struts based app becomes: > > - An ActionForm per input , normally with > String-based properties (so you can redisplay > invalid input the way users expect you to). > > - A set of validation rules that are applied for you > on the server side, and optionally also on the > client side. > > - If a validation error occurs, Struts takes care > of redisplaying the page (with error messages) > > - If validation succeeds, the application Action > is responsibe for performing conversions of the > String valued things in the ActionForm to match > the underlying model data types, typically by > copying them in to DTO/VO type objects and > passing them to business logic (although, as others > have pointed out, lots of Struts developers have > skipped this extra layer). > > With JSF, the component model takes care of all the responsibilities > that Struts uses an ActionForm for, so you don't need one any more. > Indeed, I anticipate people will choose one or more (they aren't > mutually exclusive) of at least three different styles for building > JSF-based webapps: > > (1) You can bind individual *components* to backing bean properties, > similar to how ASP.Net "code behind files" work. This will > be most comfort
RE: Theoretical debate
You threw me for a loop with replying so late to that email-- It just comes down to giving the developer the ability to scale their own layers with JSF like you said below. If I want ActionForms, then I will have JSF update request/session scope beans that are only for the view. If I want something simpler, then I can have JSF update my business beans themselves. JSP->View Logic/Beans->Business Logic/Beans JSP->Business Logic/Beans PS: Craig, did you get my email to Ed Burns and yourself about a new, faster JSF-specific EL implementation for JSF RI? Best Regards, Jacob Hookom -Original Message- From: Craig McClanahan [mailto:[EMAIL PROTECTED] Sent: Thursday, July 08, 2004 7:35 PM To: Struts Users Mailing List Subject: Re: Theoretical debate Hookom, Jacob wrote: >Look at JSF, do you have actions? No, JSF just updates your POJO beans and >calls methods on them. Why have an ActionForm or have to create all of >these Actions that are simply getter/setter adapters? Please don't be too >quick to retort to my supposed anti-struts mindset, but there are other >frameworks out there that allow direct interaction with my business objects >and don't require a heck of a lot of framework specific coding. > > > (Coming into this discussion late, but figured that my experience on both the Struts and JSF side of things might provide some illuminating food for thought :-) It's instructive, first, to go back to the beginning of Struts development (just over four years ago), and recall why an ActionForm exists in the first place. The only reason we created that abstraction was to deal with some pesky real world problems in designing webapps ... primarily dealing with conversion (where we really punted ... see below), validation, and little things like maintaining the state of checkboxes. Because Struts doesn't have any "user interface component" concept, dealing with those things had to go somewhere -- and a common abstraction at least made it easy to understand. Therefore, the recommended design pattern for a Struts based app becomes: - An ActionForm per input , normally with String-based properties (so you can redisplay invalid input the way users expect you to). - A set of validation rules that are applied for you on the server side, and optionally also on the client side. - If a validation error occurs, Struts takes care of redisplaying the page (with error messages) - If validation succeeds, the application Action is responsibe for performing conversions of the String valued things in the ActionForm to match the underlying model data types, typically by copying them in to DTO/VO type objects and passing them to business logic (although, as others have pointed out, lots of Struts developers have skipped this extra layer). With JSF, the component model takes care of all the responsibilities that Struts uses an ActionForm for, so you don't need one any more. Indeed, I anticipate people will choose one or more (they aren't mutually exclusive) of at least three different styles for building JSF-based webapps: (1) You can bind individual *components* to backing bean properties, similar to how ASP.Net "code behind files" work. This will be most comfortable to VB developers, and is useful when you need to programmatically modify component properties. (2) You can bind component *values* directly to properties in your backing bean, and then provide the business logic as action methods in the same class. Because the components take care of conversion, you're free to use model-oriented data types for such properties, so you don't need to worry about explicit conversion any more. This style will appear to Struts developers like a combination of an Action and an ActionForm in the same class, and will also appeal to the crowd that likes O-O encapsulation :-). (3) You can bind component *values* directly to properties on a VO/DTO object, and bind action events to methods on a separate bean that will either perform the logic directly or delegate to a business logic class. This style will feel more like traditional Struts separated ActionForm and Action classes, but the Action won't have as much to do. It's also a great way to build a webapp on top of existing application infrastructure that provides resuabe VO/DTO and business logic classes already. I believe that all three approaches are valid -- which one you take for a particular application function depends on your use case for that function. You don't have to be exclusive, either. Combine them where it makes sense. Craig McClanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Theoretical debate
Mike Duffy wrote: One aspect of JSF which I find troubling is, "With JSF, the component model takes care of all the responsibilities that Struts uses an ActionForm form, so you don't need one any more." Most of the JSF examples I've studied use method (2) from Craig's list below: "You can bind component *values* directly to properties in your backing bean, and then provide the business logic as action methods in the same class." As an example of this approach see, Developing Web Interfaces with JSF, http://www.fawcette.com/javapro/2004_01/magazine/features/cschalk/default.aspx IMHO, mixing business logic in the backing bean is not a great design. I like the clean separation provided by the Struts action class. Spring's front end web framework also doesn't have the concept of an ActionForm and you can bind your VO to the form fields. I love this idea (Overall, I haven't found Spring's web framework component to be much benefit over Struts, though). I think the concept of an ActionForm is over-kill and a waste. Binding a VO to the front end, though, doesn't mean you are "mixing business logic in the backing bean." There are intermediate steps (injected filters, etc) that will do the conversions and actually binding, similar to what you have to do anyway in an Action class using BeanUtils or else manually setting your VO from ActionForm fields. -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Theoretical debate
> JSF takes care of conversion > problems, and redisplay in case of conversion errors, for you. indeed, converters are a BIG-plus in JSF the DateTimeConverter allows you to use java.util.Date in a BackingBean. enter in textfield: 12/06/2004 and java.util.Date got created... on the other side the output, i case of presenting a date so you got your date like '12/06/2004' instead of [EMAIL PROTECTED] ;-) btw. you can create your own converters e.g for a telephone-nr class Telephone -country -city -yournummer give that converter a delimiter and some logic, on what digit is what so you might enter '+1.410.803.2258' and your Telephone-Object is created... same for output... btw. if your converter has attributes, keep in mind, that you need to implement stateholder-Interface... okay... before i turn too much offtopic... regards Matthias > As a trivial example, assume you have a bean "mybean" that has an > input/output int property named "mycount" that you want to > render in a > JSF-based JSP page. It is trivially simple: > > > > works fine. The String->int and int->String conversions > (including any > errors that occur) are handled totally by JSF. Your business > logic can > assume that, if was invoked, there were no conversion or > validation errors. > > Craig > > > > >--- Craig McClanahan <[EMAIL PROTECTED]> wrote: > > > > > >>Hookom, Jacob wrote: > >> > >> > >> > >>>Look at JSF, do you have actions? No, JSF just updates your POJO > >>>beans and calls methods on them. Why have an ActionForm > or have to > >>>create all of these Actions that are simply getter/setter > adapters? > >>>Please don't be too quick to retort to my supposed anti-struts > >>>mindset, but there are other frameworks out there that > allow direct > >>>interaction with my business objects and don't require a heck of a > >>>lot of framework specific coding. > >>> > >>> > >>> > >>> > >>> > >>(Coming into this discussion late, but figured that my experience on > >>both the Struts and JSF side of things might provide some > illuminating > >>food for thought :-) > >> > >>It's instructive, first, to go back to the beginning of Struts > >>development (just over four years ago), and recall why an > ActionForm > >>exists in the first place. The only reason we created that > abstraction > >>was to deal with some pesky real world problems in > designing webapps ... > >>primarily dealing with conversion (where we really punted ... see > >>below), validation, and little things like maintaining the state of > >>checkboxes. Because Struts doesn't have any "user > interface component" > >>concept, dealing with those things had to go somewhere -- > and a common > >>abstraction at least made it easy to understand. > >> > >>Therefore, the recommended design pattern for a Struts based app > >>becomes: > >> > >>- An ActionForm per input , normally with > >> String-based properties (so you can redisplay > >> invalid input the way users expect you to). > >> > >>- A set of validation rules that are applied for you > >> on the server side, and optionally also on the > >> client side. > >> > >>- If a validation error occurs, Struts takes care > >> of redisplaying the page (with error messages) > >> > >>- If validation succeeds, the application Action > >> is responsibe for performing conversions of the > >> String valued things in the ActionForm to match > >> the underlying model data types, typically by > >> copying them in to DTO/VO type objects and > >> passing them to business logic (although, as others > >> have pointed out, lots of Struts developers have > >> skipped this extra layer). > >> > >>With JSF, the component model takes care of all the responsibilities > >>that Struts uses an ActionForm for, so you don't need one > any more. > >>Indeed, I anticipate people will choose one or more (they aren't > >>mutually exclusive) of at least three different styles for building > >>JSF-based webapps: > >> > >>(1) You can bind individual *components* to backing bean properties, > >> similar to how ASP.Net "code behind files" work. This will > >> be most comfortable to VB developers, and is useful when > >> you need to programmatically modify component properties. > >> > >>(2) You can bind component *values* directly to properties in your > >> backing bean, and then provide the business logic as > action methods > >> in the same class. Because the components take care > of conversion, > >> you're free to use model-oriented data types for such > properties, > >> so you don't need to worry about explicit conversion any more. > >> This style will appear to Struts developers like a > combination of an > >> Action and an ActionForm in the same class, and will > also appeal to > >> the crowd that likes O-O encapsulation :-). > >> > >>(3) You can bind component *values* directly to properties > on a VO/DTO > >>
Re: Theoretical debate
Mike Duffy wrote: One aspect of JSF which I find troubling is, "With JSF, the component model takes care of all the responsibilities that Struts uses an ActionForm form, so you don't need one any more." Most of the JSF examples I've studied use method (2) from Craig's list below: "You can bind component *values* directly to properties in your backing bean, and then provide the business logic as action methods in the same class." As an example of this approach see, Developing Web Interfaces with JSF, http://www.fawcette.com/javapro/2004_01/magazine/features/cschalk/default.aspx IMHO, mixing business logic in the backing bean is not a great design. I like the clean separation provided by the Struts action class. Method (3) from Craig's list below seems like a viable solution: "You can bind component *values* directly to properties on a VO/DTO object, and bind action events to methods on a separate bean that will either perform the logic directly or delegate to a business logic class." I've read most of the major articles on JSF. I have not seen method (3) implemented as an example. Does anyone have a link that they can send showing the implementation of method (3)? Does anyone know if there will be a reference implementation for JSF using method (3)? I think it would increase the acceptance of JSF in the Struts community if such a reference implementation was available. Thanks. Mike I don't have any JSF-specific examples to point to (JSF is too new for that), but the basic principle is pretty obvious: if you were going to create a type (2) application, simply create a type (3) application instead. If you've "cheated" on the separation of concerns issues in your existing app, this is going to seem harder. If you have existing VO/DTO objects, the path is relatively simple: use a value binding expression on the "value" attribute of your input components to bind directly to the model property expressed by your VO/DTO object. For example, assume that you have an integer property named "count" on your VO/DTO object. In the past, Struts would encourage you to create a Strring property on your form bean, to deal with the fact that users might actually type "1a3" instead of "123" in this field. JSF deals with that sort of issue for you, so that you can safely bind the "value" attribute" of your input component directly to an int property of your VO/DTO bean ... no muss, no fuss. JSF takes care of conversion problems, and redisplay in case of conversion errors, for you. As a trivial example, assume you have a bean "mybean" that has an input/output int property named "mycount" that you want to render in a JSF-based JSP page. It is trivially simple: works fine. The String->int and int->String conversions (including any errors that occur) are handled totally by JSF. Your business logic can assume that, if was invoked, there were no conversion or validation errors. Craig --- Craig McClanahan <[EMAIL PROTECTED]> wrote: Hookom, Jacob wrote: Look at JSF, do you have actions? No, JSF just updates your POJO beans and calls methods on them. Why have an ActionForm or have to create all of these Actions that are simply getter/setter adapters? Please don't be too quick to retort to my supposed anti-struts mindset, but there are other frameworks out there that allow direct interaction with my business objects and don't require a heck of a lot of framework specific coding. (Coming into this discussion late, but figured that my experience on both the Struts and JSF side of things might provide some illuminating food for thought :-) It's instructive, first, to go back to the beginning of Struts development (just over four years ago), and recall why an ActionForm exists in the first place. The only reason we created that abstraction was to deal with some pesky real world problems in designing webapps ... primarily dealing with conversion (where we really punted ... see below), validation, and little things like maintaining the state of checkboxes. Because Struts doesn't have any "user interface component" concept, dealing with those things had to go somewhere -- and a common abstraction at least made it easy to understand. Therefore, the recommended design pattern for a Struts based app becomes: - An ActionForm per input , normally with String-based properties (so you can redisplay invalid input the way users expect you to). - A set of validation rules that are applied for you on the server side, and optionally also on the client side. - If a validation error occurs, Struts takes care of redisplaying the page (with error messages) - If validation succeeds, the application Action is responsibe for performing conversions of the String valued things in the ActionForm to match the underlying model data types, typically by copying them in to DTO/VO type objects and passing them to business logic (although, as others have pointed out, lots of St
Re: Theoretical debate
One aspect of JSF which I find troubling is, "With JSF, the component model takes care of all the responsibilities that Struts uses an ActionForm form, so you don't need one any more." Most of the JSF examples I've studied use method (2) from Craig's list below: "You can bind component *values* directly to properties in your backing bean, and then provide the business logic as action methods in the same class." As an example of this approach see, Developing Web Interfaces with JSF, http://www.fawcette.com/javapro/2004_01/magazine/features/cschalk/default.aspx IMHO, mixing business logic in the backing bean is not a great design. I like the clean separation provided by the Struts action class. Method (3) from Craig's list below seems like a viable solution: "You can bind component *values* directly to properties on a VO/DTO object, and bind action events to methods on a separate bean that will either perform the logic directly or delegate to a business logic class." I've read most of the major articles on JSF. I have not seen method (3) implemented as an example. Does anyone have a link that they can send showing the implementation of method (3)? Does anyone know if there will be a reference implementation for JSF using method (3)? I think it would increase the acceptance of JSF in the Struts community if such a reference implementation was available. Thanks. Mike --- Craig McClanahan <[EMAIL PROTECTED]> wrote: > Hookom, Jacob wrote: > > >Look at JSF, do you have actions? No, JSF just updates your POJO beans and > >calls methods on them. Why have an ActionForm or have to create all of > >these Actions that are simply getter/setter adapters? Please don't be too > >quick to retort to my supposed anti-struts mindset, but there are other > >frameworks out there that allow direct interaction with my business objects > >and don't require a heck of a lot of framework specific coding. > > > > > > > (Coming into this discussion late, but figured that my experience on > both the Struts and JSF side of things might provide some illuminating > food for thought :-) > > It's instructive, first, to go back to the beginning of Struts > development (just over four years ago), and recall why an ActionForm > exists in the first place. The only reason we created that abstraction > was to deal with some pesky real world problems in designing webapps ... > primarily dealing with conversion (where we really punted ... see > below), validation, and little things like maintaining the state of > checkboxes. Because Struts doesn't have any "user interface component" > concept, dealing with those things had to go somewhere -- and a common > abstraction at least made it easy to understand. > > Therefore, the recommended design pattern for a Struts based app becomes: > > - An ActionForm per input , normally with > String-based properties (so you can redisplay > invalid input the way users expect you to). > > - A set of validation rules that are applied for you > on the server side, and optionally also on the > client side. > > - If a validation error occurs, Struts takes care > of redisplaying the page (with error messages) > > - If validation succeeds, the application Action > is responsibe for performing conversions of the > String valued things in the ActionForm to match > the underlying model data types, typically by > copying them in to DTO/VO type objects and > passing them to business logic (although, as others > have pointed out, lots of Struts developers have > skipped this extra layer). > > With JSF, the component model takes care of all the responsibilities > that Struts uses an ActionForm for, so you don't need one any more. > Indeed, I anticipate people will choose one or more (they aren't > mutually exclusive) of at least three different styles for building > JSF-based webapps: > > (1) You can bind individual *components* to backing bean properties, > similar to how ASP.Net "code behind files" work. This will > be most comfortable to VB developers, and is useful when > you need to programmatically modify component properties. > > (2) You can bind component *values* directly to properties in your > backing bean, and then provide the business logic as action methods > in the same class. Because the components take care of conversion, > you're free to use model-oriented data types for such properties, > so you don't need to worry about explicit conversion any more. > This style will appear to Struts developers like a combination of an > Action and an ActionForm in the same class, and will also appeal to > the crowd that likes O-O encapsulation :-). > > (3) You can bind component *values* directly to properties on a VO/DTO > object, and bind action events to methods on a separate bean that will > either perform the logic directly or delegate to a business logic > class. > Thi
Re: Theoretical debate
Hookom, Jacob wrote: Look at JSF, do you have actions? No, JSF just updates your POJO beans and calls methods on them. Why have an ActionForm or have to create all of these Actions that are simply getter/setter adapters? Please don't be too quick to retort to my supposed anti-struts mindset, but there are other frameworks out there that allow direct interaction with my business objects and don't require a heck of a lot of framework specific coding. (Coming into this discussion late, but figured that my experience on both the Struts and JSF side of things might provide some illuminating food for thought :-) It's instructive, first, to go back to the beginning of Struts development (just over four years ago), and recall why an ActionForm exists in the first place. The only reason we created that abstraction was to deal with some pesky real world problems in designing webapps ... primarily dealing with conversion (where we really punted ... see below), validation, and little things like maintaining the state of checkboxes. Because Struts doesn't have any "user interface component" concept, dealing with those things had to go somewhere -- and a common abstraction at least made it easy to understand. Therefore, the recommended design pattern for a Struts based app becomes: - An ActionForm per input , normally with String-based properties (so you can redisplay invalid input the way users expect you to). - A set of validation rules that are applied for you on the server side, and optionally also on the client side. - If a validation error occurs, Struts takes care of redisplaying the page (with error messages) - If validation succeeds, the application Action is responsibe for performing conversions of the String valued things in the ActionForm to match the underlying model data types, typically by copying them in to DTO/VO type objects and passing them to business logic (although, as others have pointed out, lots of Struts developers have skipped this extra layer). With JSF, the component model takes care of all the responsibilities that Struts uses an ActionForm for, so you don't need one any more. Indeed, I anticipate people will choose one or more (they aren't mutually exclusive) of at least three different styles for building JSF-based webapps: (1) You can bind individual *components* to backing bean properties, similar to how ASP.Net "code behind files" work. This will be most comfortable to VB developers, and is useful when you need to programmatically modify component properties. (2) You can bind component *values* directly to properties in your backing bean, and then provide the business logic as action methods in the same class. Because the components take care of conversion, you're free to use model-oriented data types for such properties, so you don't need to worry about explicit conversion any more. This style will appear to Struts developers like a combination of an Action and an ActionForm in the same class, and will also appeal to the crowd that likes O-O encapsulation :-). (3) You can bind component *values* directly to properties on a VO/DTO object, and bind action events to methods on a separate bean that will either perform the logic directly or delegate to a business logic class. This style will feel more like traditional Struts separated ActionForm and Action classes, but the Action won't have as much to do. It's also a great way to build a webapp on top of existing application infrastructure that provides resuabe VO/DTO and business logic classes already. I believe that all three approaches are valid -- which one you take for a particular application function depends on your use case for that function. You don't have to be exclusive, either. Combine them where it makes sense. Craig McClanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Theoretical debate
Thanks for a very interesting thread. An elucidation of many of the topics in this thread can be found in Ted Husted's book, Struts in Action; especially see chapter 5, Coping with Action Forms. It is very tempting when you first come to Struts to do a great deal of processing in the Action classes, especially if the application is "simple". However, this approach is not optimal for the long term. We try to keep our Action classes as thin as possible. The Action classes are used primarily as controllers; business logic processing takes place in worker classes or factory classes. Also, we use our business model classes simply as data transfer objects to pass data between different components of the system. This is contrary to pure object-oriented design (i.e., objects have both state and behavior); however, this approach leads to a more modular and extensible system (many components can act on the same business model data). There have been other threads in this newsgroup discussing the pros and cons of Struts vs JSF. There is definitely overlap in the two frameworks with JSF going beyond Struts to create a component model that can be applied to the web. In my judgment, the promise of JSF will be realized when advanced tools greatly simply the process of creating applications. The "Sun Java Studio Creator" (http://wwws.sun.com/software/products/jscreator/), formerly known as "Project Rave", will be worth evaluating. Actually, if Sun gets this right, it will be incredibly cool. If we knew the "inside game" at Sun, I think the story would be that they decided to develop a system to compete against the MS Visual Studio tools, and in making that decision they realized they needed a robust, extensible framework. JSF is being created for the "Sun Java Studio Creator". Hopefully, this will be good for us all. Mike --- "Pilgrim, Peter" <[EMAIL PROTECTED]> wrote: > > > -Original Message- > > From: mike [mailto:[EMAIL PROTECTED] > > Sent: 18 June 2004 15:31 > > To: Struts Users Mailing List; [EMAIL PROTECTED] > > Subject: Re: Theoretical debate > > > > > > At 07:18 AM 6/18/2004, Bill Schneider wrote: > > > > >Form beans can be thought of as a special case of DTOs: they are the > > >argument the client (web browser) passes to the remote > > method call (HTTP > > >POST). So passing form beans directly to business logic is _almost_ > > >reasonable, putting the dependency issue aside for now (form > > beans have to > > >extend ActionForm). > > > > > >The difference is, form beans are a model of the /user > > input/, and since > > >there may be invalid inputs (for example: "asdfjkjkd" in a > > field that's > > >supposed to be numeric) form bean fields often need to be > > Strings when the > > >corresponding field in a "real" DTO would be a Date or Integer. > > > > > >To deal with this, I've used a tool called XSnapshot (just > > released to > > >SourceForge: http://xsnapshot.sourceforge.net) to generate > > form beans and > > >other DTOs from XDoclet tags in a POJO data model. That way you get > > >_both_ real DTOs and Form Beans without writing all the > > classes by hand, > > >and you can copy between DTOs and form beans with > > BeanUtils.copyProperties. > > > > > >-- Bill > > >-- > > >Bill Schneider > > >Chief Architect > > > > I don't think we should be thinking of action forms as DTOs. > > DTOs or VOs > > have a special use and a special problem that they are meant to > > solve. Action forms are related to an entirely different set > > of issues > > about data farming. I don't think we can put the dependency issue > > aside. That is really the whole point of frameworks like > > Struts. If you > > can put the dependency issues aside, you probably don't need > > Struts. If > > you don't need a hammer, that is not a critique of a hammer. > > Likewise, > > Struts has an objective and, with clear areas that could be > > improved, does > > that really well. There is a good reason that Struts is so > > successful. Craig is a sweetheart, but that is not the > > reason for the > > success of Struts. > > > > I think that a lot of the problems people have with > > repetitive programming > > is not the fault of the framework but the failure to use > > coding techniques > > that are readily available, such as dynamic proxies. > &g
RE: Theoretical debate
> -Original Message- > From: mike [mailto:[EMAIL PROTECTED] > Sent: 18 June 2004 15:31 > To: Struts Users Mailing List; [EMAIL PROTECTED] > Subject: Re: Theoretical debate > > > At 07:18 AM 6/18/2004, Bill Schneider wrote: > > >Form beans can be thought of as a special case of DTOs: they are the > >argument the client (web browser) passes to the remote > method call (HTTP > >POST). So passing form beans directly to business logic is _almost_ > >reasonable, putting the dependency issue aside for now (form > beans have to > >extend ActionForm). > > > >The difference is, form beans are a model of the /user > input/, and since > >there may be invalid inputs (for example: "asdfjkjkd" in a > field that's > >supposed to be numeric) form bean fields often need to be > Strings when the > >corresponding field in a "real" DTO would be a Date or Integer. > > > >To deal with this, I've used a tool called XSnapshot (just > released to > >SourceForge: http://xsnapshot.sourceforge.net) to generate > form beans and > >other DTOs from XDoclet tags in a POJO data model. That way you get > >_both_ real DTOs and Form Beans without writing all the > classes by hand, > >and you can copy between DTOs and form beans with > BeanUtils.copyProperties. > > > >-- Bill > >-- > >Bill Schneider > >Chief Architect > > I don't think we should be thinking of action forms as DTOs. > DTOs or VOs > have a special use and a special problem that they are meant to > solve. Action forms are related to an entirely different set > of issues > about data farming. I don't think we can put the dependency issue > aside. That is really the whole point of frameworks like > Struts. If you > can put the dependency issues aside, you probably don't need > Struts. If > you don't need a hammer, that is not a critique of a hammer. > Likewise, > Struts has an objective and, with clear areas that could be > improved, does > that really well. There is a good reason that Struts is so > successful. Craig is a sweetheart, but that is not the > reason for the > success of Struts. > > I think that a lot of the problems people have with > repetitive programming > is not the fault of the framework but the failure to use > coding techniques > that are readily available, such as dynamic proxies. > > Michael > > Yes I could not agree more. This why Commons BeanUtils and PropertyUtils was invented. It sound like people have an itch for a mapping properties that converts ActionForm (Dyna also) to a Value Object. Convert me X into Y whilst copying the attributes as best I can from X to Y. Sounds like a very old OO problem: Morphing Eclispe into Round Rectangle into a Triangle. I wonder. -- Peter Pilgrim Operations/IT - Credit Suisse First Boston, 10 South Colonnade, London E14 4QJ, United Kingdom Tel: +44 (0)207 883 4447 == This message is for the sole use of the intended recipient. If you received this message in error please delete it and notify us. If this message was misdirected, CSFB does not waive any confidentiality or privilege. CSFB retains and monitors electronic communications sent through its network. Instructions transmitted over this system are not binding on CSFB until they are confirmed by us. Message transmission is not guaranteed to be secure. == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Theoretical debate
--- Frank Zammetti <[EMAIL PROTECTED]> wrote: > I know what your saying, it's the way I do things as well, doing very > little work in the Actions aside from tossing values around and calling > subordinate classes to do the real work. > > But doesn't that in a sense support the idea of an application being > services cobbled together? In practice, it is. To me, though, the way I approach the implementation is heavily influenced by my mindset while working out the design in theory. For instance, with the mindset that the business logic tier *is the application* and that the presentation tier is just a necessary add-on, my DTOs will hold Date fields instead of strings containing date-formatted values, and I'd have the Action objects bending over for the business tier, and not the other way around. In my mindset, the Actions aren't calling subordinate classes, they themselves are the subordinates, re reporting to their superiors which they serve. If my mindset is that the app is a set of web requests that work to meet the requirements, I probably wouldn't hesitate passing ActionForm objects all the way to the data management tier. My point is, how I look at the design, and how I preach it to my teammates, can still influence the implementation. > In that mindset, I can see some logic to saying something like Crysalis is > on a better path because your simplifying things a bit by essentially > removing a layer. This is where my mindset affects the implementation. In my mind, the web tier has no business calling my domain objects directly. They all have to go through my façade. It's the façade which knows what's happening and sees the big picture. If the business rule changes, it's the business tier that changes. If I suddenly have to expose a feature for another application, it can talk to my façade. It's just a different mindset for me. > Also, please no one get the idea that I'm saying Struts is anything but > good, or that I'm saying we shouldn't be doing things the way we are doing > them now. My point in starting this thread was just to point what I thought > was an interesting way to look at things that I hadn't considered before, > at least not precisely. If anything, much of the responses I've read have > reinforced my belief that what we're doing now in Struts is generally pretty > good. I am a big believer in the services model of development, have been > for a number of years now (although I'm not so sure the current forms of > this methodology are spot on just yet), so discussions of things like this > are always of interest to me. > > Frank In my case, I just wanna state that I too am interested in these discussions. I know my messages can sometimes be read as trying to start an argument instead of participating in the discussion. Let it be known that it's really the latter. I'm open to ideas, and I'm always looking for ways to improve how I approach the design of applications, web or not. Hubert __ Do you Yahoo!? Yahoo! Mail is new and improved - Check it out! http://promotions.yahoo.com/new_mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Theoretical debate
On point 2, I'm not sure I agree with that. Thinking of one particular application I've recently completed, the business layer is quite losely-coupled from the Struts portion, and I can say that with absolutely certainty because in fact I converted it FROM another framework (a custom job) TO Struts, and didn't have to touch the underlying business classes at all. That being said, the application, while overall pretty well-architected, was doing a lot of data type conversions in the Actions before delegating to the business layer. I mean, it's very simplistic code so it's not a huge problem, but I think we'd all agree that by using DTOs you can better handle this issue. For example, in my DTO I might have a setDollarAmount() method that accepts a String (since that's what I'm getting from the view) and convert it to a BigDecimal internally before being passed to the business layer. That's a nice thing, cleans up the Actions and puts code closer to where it "should" be. But I don't think NOT doing this ties you to Struts, or any other framework, as a rule. I would agree that it's EASIER to be tied by not using DTOs because it's easier to do things that do tie you to it. Frank From: [EMAIL PROTECTED] Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> Subject: RE: Theoretical debate Date: Fri, 18 Jun 2004 10:19:23 -0400 1. This sounds like your test code (assuming you have some) is tightly coupled with Struts. You may or may not care. 2. Not using DTO/VO means that your business layer is tightly coupled with Struts. This may or may not be a problem should you decide to use a different controller framework. 3. I'm guessing you're NOT using EJBs, otherwise, they would be tightly coupled with Struts... Dennis "Frank Zammetti" <[EMAIL PROTECTED]> 06/18/2004 09:42 AM Please respond to "Struts Users Mailing List" <[EMAIL PROTECTED]> To [EMAIL PROTECTED] cc Subject RE: Theoretical debate You know, kind of off-topic, but you remind me of a conversation I had with someone at work here, maybe you guys would have some input... I know what various patterns tell us we should do, but in practice... you guys of course have your ActionForms that transfer data from the view to the control layer... do you then have Data Transfer Objects, or Value Objects, or whatever terms you want to use, to hand off to your model layer? In other words, do you get data IN via ActionForm to an Action, then transfer all that data to another Data Transfer Object, then pass that off to some subordinate class to do the actual processing? I ask because most of the Struts apps I've seen don't bother with the DTO's, they just pass the ActionForm to the subordinate classes, or else pass them as parameters. It seems that regardless of what literature is telling is we should do, in practice (GENERALLY), people don't bother with the DTO's. Have I just looked at the wrong apps? What are most people doing in this regard? Frank >From: "Brian Lee" <[EMAIL PROTECTED]> >Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: RE: Theoretical debate >Date: Thu, 17 Jun 2004 16:54:26 -0400 > >I think struts' concept of separating your actions from your data is >admirable and should be followed. The concept of your value/transfer >objects (basically the form) also having business logic sounds acceptable >at first but rapidly becomes a nightmare when you try to use the same >value/transfer objects in multiple processes. > >I think it's a generally accepted practice that separating data from logic >is a "Good Thing"(tm). > >BAL > >>From: "Hookom, Jacob" <[EMAIL PROTECTED]> >>To: 'Struts Users Mailing List' <[EMAIL PROTECTED]> >>Subject: RE: Theoretical debate >>Date: Thu, 17 Jun 2004 14:57:31 -0500 >> >>I completely agree with what Crysalis is trying to push, also a framework >>called VRaptor (vraptor.org) also pushes the same idea of moving away from >>the procedural weight that Struts promotes. >> >>Look at JSF, do you have actions? No, JSF just updates your POJO beans and >>calls methods on them. Why have an ActionForm or have to create all of >>these Actions that are simply getter/setter adapters? Please don't be too >>quick to retort to my supposed anti-struts mindset, but there are other >>frameworks out there that allow direct interaction with my business >>objects >>and don't require a heck of a lot of framework specific coding. >> >>--- >> >>Example: >>To have a multi-page form with JSF, I just create
Re: Theoretical debate
At 07:18 AM 6/18/2004, Bill Schneider wrote: Form beans can be thought of as a special case of DTOs: they are the argument the client (web browser) passes to the remote method call (HTTP POST). So passing form beans directly to business logic is _almost_ reasonable, putting the dependency issue aside for now (form beans have to extend ActionForm). The difference is, form beans are a model of the /user input/, and since there may be invalid inputs (for example: "asdfjkjkd" in a field that's supposed to be numeric) form bean fields often need to be Strings when the corresponding field in a "real" DTO would be a Date or Integer. To deal with this, I've used a tool called XSnapshot (just released to SourceForge: http://xsnapshot.sourceforge.net) to generate form beans and other DTOs from XDoclet tags in a POJO data model. That way you get _both_ real DTOs and Form Beans without writing all the classes by hand, and you can copy between DTOs and form beans with BeanUtils.copyProperties. -- Bill -- Bill Schneider Chief Architect I don't think we should be thinking of action forms as DTOs. DTOs or VOs have a special use and a special problem that they are meant to solve. Action forms are related to an entirely different set of issues about data farming. I don't think we can put the dependency issue aside. That is really the whole point of frameworks like Struts. If you can put the dependency issues aside, you probably don't need Struts. If you don't need a hammer, that is not a critique of a hammer. Likewise, Struts has an objective and, with clear areas that could be improved, does that really well. There is a good reason that Struts is so successful. Craig is a sweetheart, but that is not the reason for the success of Struts. I think that a lot of the problems people have with repetitive programming is not the fault of the framework but the failure to use coding techniques that are readily available, such as dynamic proxies. Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Theoretical debate
+1 A lot of this discussion seems like it involves uses that don't need
the levels of abstraction a true enterprise site must have.
At 07:19 AM 6/18/2004, [EMAIL PROTECTED] wrote:
1. This sounds like your test code (assuming you have some) is tightly
coupled with Struts. You may or may not care.
2. Not using DTO/VO means that your business layer is tightly coupled with
Struts. This may or may not be a problem should you decide to use a
different controller framework.
3. I'm guessing you're NOT using EJBs, otherwise, they would be tightly
coupled with Struts...
Dennis
"Frank Zammetti" <[EMAIL PROTECTED]>
06/18/2004 09:42 AM
Please respond to
"Struts Users Mailing List" <[EMAIL PROTECTED]>
To
[EMAIL PROTECTED]
cc
Subject
RE: Theoretical debate
You know, kind of off-topic, but you remind me of a conversation I had with
someone at work here, maybe you guys would have some input...
I know what various patterns tell us we should do, but in practice... you
guys of course have your ActionForms that transfer data from the view to the
control layer... do you then have Data Transfer Objects, or Value Objects,
or whatever terms you want to use, to hand off to your model layer?
In other words, do you get data IN via ActionForm to an Action, then
transfer all that data to another Data Transfer Object, then pass that off
to some subordinate class to do the actual processing?
I ask because most of the Struts apps I've seen don't bother with the DTO's,
they just pass the ActionForm to the subordinate classes, or else pass them
as parameters. It seems that regardless of what literature is telling is we
should do, in practice (GENERALLY), people don't bother with the DTO's.
Have I just looked at the wrong apps? What are most people doing in this
regard?
Frank
>From: "Brian Lee" <[EMAIL PROTECTED]>
>Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: RE: Theoretical debate
>Date: Thu, 17 Jun 2004 16:54:26 -0400
>
>I think struts' concept of separating your actions from your data is
>admirable and should be followed. The concept of your value/transfer
>objects (basically the form) also having business logic sounds acceptable
>at first but rapidly becomes a nightmare when you try to use the same
>value/transfer objects in multiple processes.
>
>I think it's a generally accepted practice that separating data from logic
>is a "Good Thing"(tm).
>
>BAL
>
>>From: "Hookom, Jacob" <[EMAIL PROTECTED]>
>>To: 'Struts Users Mailing List' <[EMAIL PROTECTED]>
>>Subject: RE: Theoretical debate
>>Date: Thu, 17 Jun 2004 14:57:31 -0500
>>
>>I completely agree with what Crysalis is trying to push, also a framework
>>called VRaptor (vraptor.org) also pushes the same idea of moving away from
>>the procedural weight that Struts promotes.
>>
>>Look at JSF, do you have actions? No, JSF just updates your POJO beans and
>>calls methods on them. Why have an ActionForm or have to create all of
>>these Actions that are simply getter/setter adapters? Please don't be too
>>quick to retort to my supposed anti-struts mindset, but there are other
>>frameworks out there that allow direct interaction with my business
>>objects
>>and don't require a heck of a lot of framework specific coding.
>>
>>---
>>
>>Example:
>>To have a multi-page form with JSF, I just create a bean that sits in
>>Session scope that has a series of getters and setters. JSF will also
>>allow
>>me to pre-set relationships to other objects at creation time. Then, when
>>I'm ready to submit the multi-page form, I just put in the jsp
>>#{myFormBean.submit}. No action mappings, only a managed bean entry.
>>
>>With Struts, I have to create an ActionForm objects (can't just use a
>>business object I already have), and then create separate Action objects
>>to
>>manipulate that ActionForm.
>>
>>---
>>
>>-Jacob Hookom
>>
>>-Original Message-
>>From: Frank Zammetti [mailto:[EMAIL PROTECTED]
>>Sent: Thursday, June 17, 2004 2:29 PM
>>To: [EMAIL PROTECTED]
>>Subject: Theoretical debate
>>
>>Last night I was Googling for something and I stumbled across the Crysalis
>>framework. I was actualyl intrigued by the underlying premise of it and I
>>wanted to see what others thought about it.
>>
>>In a nutshell and in my own words, Crysalis
>>(http://chrysalis.sourceforge.net/) has the underlying idea that when you
>>develop in most MVC frameworks, Struts chief among them, you are actually
>>doing something unnatural and in a w
> Re: Theoretical debate
I ask because most of the Struts apps I've seen don't bother with the DTO's, they just pass the ActionForm to the subordinate classes, or else pass them as parameters. It seems that regardless of what literature is telling is we should do, in practice (GENERALLY), people don't bother with the DTO's. Have I just looked at the wrong apps? What are most people doing in this regard? Form beans can be thought of as a special case of DTOs: they are the argument the client (web browser) passes to the remote method call (HTTP POST). So passing form beans directly to business logic is _almost_ reasonable, putting the dependency issue aside for now (form beans have to extend ActionForm). The difference is, form beans are a model of the /user input/, and since there may be invalid inputs (for example: "asdfjkjkd" in a field that's supposed to be numeric) form bean fields often need to be Strings when the corresponding field in a "real" DTO would be a Date or Integer. To deal with this, I've used a tool called XSnapshot (just released to SourceForge: http://xsnapshot.sourceforge.net) to generate form beans and other DTOs from XDoclet tags in a POJO data model. That way you get _both_ real DTOs and Form Beans without writing all the classes by hand, and you can copy between DTOs and form beans with BeanUtils.copyProperties. -- Bill -- Bill Schneider Chief Architect Vecna Technologies 5004 Lehigh Rd., Suite B College Park, MD 20740 [EMAIL PROTECTED] t: 301-864-7594 f: 301-699-3180 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Theoretical debate
1. This sounds like your test code (assuming
you have some) is tightly coupled with Struts. You may or may not
care.
2. Not using DTO/VO means that your
business layer is tightly coupled with Struts. This may or may not
be a problem should you decide to use a different controller framework.
3. I'm guessing you're NOT using EJBs,
otherwise, they would be tightly coupled with Struts...
Dennis
"Frank Zammetti"
<[EMAIL PROTECTED]>
06/18/2004 09:42 AM
Please respond to
"Struts Users Mailing List" <[EMAIL PROTECTED]>
To
[EMAIL PROTECTED]
cc
Subject
RE: Theoretical debate
You know, kind of off-topic, but you remind me of
a conversation I had with
someone at work here, maybe you guys would have some input...
I know what various patterns tell us we should do, but in practice... you
guys of course have your ActionForms that transfer data from the view to
the
control layer... do you then have Data Transfer Objects, or Value Objects,
or whatever terms you want to use, to hand off to your model layer?
In other words, do you get data IN via ActionForm to an Action, then
transfer all that data to another Data Transfer Object, then pass that
off
to some subordinate class to do the actual processing?
I ask because most of the Struts apps I've seen don't bother with the DTO's,
they just pass the ActionForm to the subordinate classes, or else pass
them
as parameters. It seems that regardless of what literature is telling
is we
should do, in practice (GENERALLY), people don't bother with the DTO's.
Have I just looked at the wrong apps? What are most people doing
in this
regard?
Frank
>From: "Brian Lee" <[EMAIL PROTECTED]>
>Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: RE: Theoretical debate
>Date: Thu, 17 Jun 2004 16:54:26 -0400
>
>I think struts' concept of separating your actions from your data is
>admirable and should be followed. The concept of your value/transfer
>objects (basically the form) also having business logic sounds acceptable
>at first but rapidly becomes a nightmare when you try to use the same
>value/transfer objects in multiple processes.
>
>I think it's a generally accepted practice that separating data from
logic
>is a "Good Thing"(tm).
>
>BAL
>
>>From: "Hookom, Jacob" <[EMAIL PROTECTED]>
>>To: 'Struts Users Mailing List' <[EMAIL PROTECTED]>
>>Subject: RE: Theoretical debate
>>Date: Thu, 17 Jun 2004 14:57:31 -0500
>>
>>I completely agree with what Crysalis is trying to push, also a
framework
>>called VRaptor (vraptor.org) also pushes the same idea of moving
away from
>>the procedural weight that Struts promotes.
>>
>>Look at JSF, do you have actions? No, JSF just updates your POJO
beans and
>>calls methods on them. Why have an ActionForm or have to
create all of
>>these Actions that are simply getter/setter adapters? Please
don't be too
>>quick to retort to my supposed anti-struts mindset, but there are
other
>>frameworks out there that allow direct interaction with my business
>>objects
>>and don't require a heck of a lot of framework specific coding.
>>
>>---
>>
>>Example:
>>To have a multi-page form with JSF, I just create a bean that sits
in
>>Session scope that has a series of getters and setters. JSF
will also
>>allow
>>me to pre-set relationships to other objects at creation time.
Then, when
>>I'm ready to submit the multi-page form, I just put in the jsp
>>#{myFormBean.submit}. No action mappings, only a managed
bean entry.
>>
>>With Struts, I have to create an ActionForm objects (can't just
use a
>>business object I already have), and then create separate Action
objects
>>to
>>manipulate that ActionForm.
>>
>>---
>>
>>-Jacob Hookom
>>
>>-Original Message-
>>From: Frank Zammetti [mailto:[EMAIL PROTECTED]
>>Sent: Thursday, June 17, 2004 2:29 PM
>>To: [EMAIL PROTECTED]
>>Subject: Theoretical debate
>>
>>Last night I was Googling for something and I stumbled across the
Crysalis
>>framework. I was actualyl intrigued by the underlying premise
of it and I
>>wanted to see what others thought about it.
>>
>>In a nutshell and in my own words, Crysalis
>>(http://chrysalis.sourceforge.net/) has the underlying idea that
when you
>>develop in most MVC frameworks, Struts chief among them, you are
actually
>>doi
RE: Theoretical debate
I agree with this.
I tend to find myself passing parameters to business services rather than
DTOs.
I do it for simplicity. If i use an ActionForm then you either have to add
things like getNumberAsInt as getNumber returns a string, or do the integer
parsing in the action. You then have to retrieve stuff from the ActionForm
bean, and put it into
So, it seems pretty much pointless putting stuff into DTOs to then take them
out in the service/DAO.
Another potential "bad practice" i tend to use is to merge DAOs with
Business Objects. I dont see the need for separate objects, especially when
using OJB you can just create a BaseBusinessObject that includes most of the
DAO code, and extend this. I also tend to double these up as DTOs where i
need to use them.
Daniel.
> -Original Message-
> From: Frank Zammetti [mailto:[EMAIL PROTECTED]
> Sent: 18 June 2004 14:43
> To: [EMAIL PROTECTED]
> Subject: RE: Theoretical debate
>
>
> You know, kind of off-topic, but you remind me of a conversation
> I had with
> someone at work here, maybe you guys would have some input...
>
> I know what various patterns tell us we should do, but in practice... you
> guys of course have your ActionForms that transfer data from the
> view to the
> control layer... do you then have Data Transfer Objects, or Value
> Objects,
> or whatever terms you want to use, to hand off to your model layer?
>
> In other words, do you get data IN via ActionForm to an Action, then
> transfer all that data to another Data Transfer Object, then pass
> that off
> to some subordinate class to do the actual processing?
>
> I ask because most of the Struts apps I've seen don't bother with
> the DTO's,
> they just pass the ActionForm to the subordinate classes, or else
> pass them
> as parameters. It seems that regardless of what literature is
> telling is we
> should do, in practice (GENERALLY), people don't bother with the DTO's.
>
> Have I just looked at the wrong apps? What are most people doing in this
> regard?
>
> Frank
>
> >From: "Brian Lee" <[EMAIL PROTECTED]>
> >Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
> >To: [EMAIL PROTECTED]
> >Subject: RE: Theoretical debate
> >Date: Thu, 17 Jun 2004 16:54:26 -0400
> >
> >I think struts' concept of separating your actions from your data is
> >admirable and should be followed. The concept of your value/transfer
> >objects (basically the form) also having business logic sounds
> acceptable
> >at first but rapidly becomes a nightmare when you try to use the same
> >value/transfer objects in multiple processes.
> >
> >I think it's a generally accepted practice that separating data
> from logic
> >is a "Good Thing"(tm).
> >
> >BAL
> >
> >>From: "Hookom, Jacob" <[EMAIL PROTECTED]>
> >>To: 'Struts Users Mailing List' <[EMAIL PROTECTED]>
> >>Subject: RE: Theoretical debate
> >>Date: Thu, 17 Jun 2004 14:57:31 -0500
> >>
> >>I completely agree with what Crysalis is trying to push, also a
> framework
> >>called VRaptor (vraptor.org) also pushes the same idea of
> moving away from
> >>the procedural weight that Struts promotes.
> >>
> >>Look at JSF, do you have actions? No, JSF just updates your
> POJO beans and
> >>calls methods on them. Why have an ActionForm or have to create all of
> >>these Actions that are simply getter/setter adapters? Please
> don't be too
> >>quick to retort to my supposed anti-struts mindset, but there are other
> >>frameworks out there that allow direct interaction with my business
> >>objects
> >>and don't require a heck of a lot of framework specific coding.
> >>
> >>---
> >>
> >>Example:
> >>To have a multi-page form with JSF, I just create a bean that sits in
> >>Session scope that has a series of getters and setters. JSF will also
> >>allow
> >>me to pre-set relationships to other objects at creation time.
> Then, when
> >>I'm ready to submit the multi-page form, I just put in the jsp
> >>#{myFormBean.submit}. No action mappings, only a managed bean entry.
> >>
> >>With Struts, I have to create an ActionForm objects (can't just use a
> >>business object I already have), and then create separate
> Action objects
> >>to
> >>manipulate that ActionForm.
> >>
> >>---
> >>
> >>-Jacob Hookom
> >>
> >>-Original Message-
> >>From: Frank Zammetti [mailto:[E
RE: Theoretical debate
At 06:42 AM 6/18/2004, Frank Zammetti wrote: You know, kind of off-topic, but you remind me of a conversation I had with someone at work here, maybe you guys would have some I ask because most of the Struts apps I've seen don't bother with the DTO's, they just pass the ActionForm to the subordinate classes, or else pass them as parameters. It seems that regardless of what literature is telling is we should do, in practice (GENERALLY), people don't bother with the DTO's. Have I just looked at the wrong apps? What are most people doing in this regard? Frank I don't know what people are doing on the whole. I do know that if people are not using DTOs, DAOs, VOs, etc. they are missing the boat. The initial work is paid off in volumes. Also, people don't use enough reflection. I think that the level of sophistication out there is a lot less than we imagine. For my money, the emphasis on IDEs suggests this. Good frameworks, hopefully, take us away from the IDE approach. Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Theoretical debate
For me, it's more so the same argument for changes in EJB 3.0 -- which will just allow you to use POJO objects for persistence and transactions as provided by the framework itself. People argue that EJB is too complex and doing simple operations takes 6 classes when other frameworks like Hibernate will work with what you've got for objects. I don't think it's an issue of abstraction, I can create all the POJO facades I want until my fingers bleed in order to create separation between my view/front controller and my application logic, all non-framework specific of course. In summary, EJB 3.0 and JSF are pushing to accommodate your existing objects. IMHO, if I'm spending more time writing adapter code for the Struts framework then spending time on my core business objects I have to write anyways, then maybe it's good too look at alternative frameworks. -Original Message- From: Frank Zammetti [mailto:[EMAIL PROTECTED] Sent: Friday, June 18, 2004 8:37 AM To: [EMAIL PROTECTED] Subject: RE: Theoretical debate I know what your saying, it's the way I do things as well, doing very little work in the Actions aside from tossing values around and calling subordinate classes to do the real work. But doesn't that in a sense support the idea of an application being services cobbled together? What I mean is that the Struts portion of your application is really what is forming the application, if by application we mean the coherent whole set of pages that make up a larger system. In a sense, if you have that ShoppingCart object without it's methods, let's say as an EJB, on it's own it's not an application, it's when you make use of it from an Action that it becomes part of an application. Think of it this way... If you have a collection of EJB's that you call your "application", I would argue that's not correct, the application is really only formed when you have a layer above it, maybe a bunch of Struts Actions, that call on the services of those EJB's to form a whole application. In that mindset, I can see some logic to saying something like Crysalis is on a better path because your simplifying things a bit by essentially removing a layer. I think we're all conditioned to think that ADDING layers of abstaction is a good thing, but I wonder if that's not in a great many cases just added extra layers of complexity that we don't really need. That's why I made that statement about services. I mean, the whole Web Services movement, when taken to it's logical conclusion, tells us that we should be building applications by cobbling together a number of losely-coupled service requests, that taken together form a larger application. That's kind of the whole point of WS. Also, please no one get the idea that I'm saying Struts is anything but good, or that I'm saying we shouldn't be doing things the way we are doing them now. My point in starting this thread was just to point what I thought was an interesting way to look at things that I hadn't considered before, at least not precisely. If anything, much of the responses I've read have reinforced my belief that what we're doing now in Struts is generally pretty good. I am a big believer in the services model of development, have been for a number of years now (although I'm not so sure the current forms of this methodology are spot on just yet), so discussions of things like this are always of interest to me. Frank >From: Hubert Rabago <[EMAIL PROTECTED]> >Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]> >To: Struts Users Mailing List <[EMAIL PROTECTED]> >Subject: RE: Theoretical debate >Date: Thu, 17 Jun 2004 13:29:27 -0700 (PDT) > > > > From: Frank Zammetti [mailto:[EMAIL PROTECTED] > > Most likely you would have a ShoppingCart class with a number of >methods >in it, > > things like addItem(), removeItem(), totalPrice(), etc. > >I follow this design on my applications, on the *business logic* tier. >On that tier (whether I implement it as EJBs or POJOs), I would have an >actual business object that would have these methods. >I tend to look at Struts as a necessary add-on to the application to give >it a web front end. >To me, my web application isn't "a collection of services that are executed >to form a coherent larger application", rather it's just an interface >to the actual application that runs on the server. > > > --- "Hookom, Jacob" <[EMAIL PROTECTED]> wrote: > > With Struts, I have to create an ActionForm objects (can't just use a > > business object I already have), and then create separate Action >objects >to > >Because of the way I view my app, I have no problem separatin
RE: Theoretical debate
At 06:36 AM 6/18/2004, Frank Zammetti wrote: In that mindset, I can see some logic to saying something like Crysalis is on a better path because your simplifying things a bit by essentially removing a layer. I think we're all conditioned to think that ADDING layers of abstaction is a good thing, but I wonder if that's not in a great many cases just added extra layers of complexity that we don't really need. I think that this is closer the issues involved, while over stating the simplicity of Faces. Faces may have less indirection, but I don't think it is a picture of simplicity. I see no reason why it should be either. For my money, I am open to anything, but I find that Struts really can deliver more than promised if used right. Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Theoretical debate
Not all websites have sophisticated needs. The multitiered website is unnecessary if you only have your photo and a story about you in the fifth grade. However, Actions are not "procedural weight" if you want to observe MVC principles for good reasons. The design principles of OO programming could be viewed as procedural weight too. At 04:58 AM 6/18/2004, Pilgrim, Peter wrote: > -Original Message- > From: Hookom, Jacob [mailto:[EMAIL PROTECTED] > Sent: 17 June 2004 20:58 > To: 'Struts Users Mailing List' > Subject: RE: Theoretical debate > > > I completely agree with what Crysalis is trying to push, also > a framework > called VRaptor (vraptor.org) also pushes the same idea of > moving away from > the procedural weight that Struts promotes. > > Look at JSF, do you have actions? No, JSF just updates your > POJO beans and > calls methods on them. Why have an ActionForm or have to > create all of > these Actions that are simply getter/setter adapters? Please Can't you use DispatchAction or LookupDispatchAction? What if your Action is not a simple getter or setter adapter? If you need to call a Business Delegate or perform some customer specifier validation for input or make a series of call outs then you cannot easily say Struts is wrong. The Action is where you bind the presentation tier and the business logic tier. > don't be too > quick to retort to my supposed anti-struts mindset, but there > are other > frameworks out there that allow direct interaction with my > business objects > and don't require a heck of a lot of framework specific coding. > I think what you are alluding to is a generic XML action controller that you can bind using yet another XML configuration file. If you can build such a beast and sell it to the mindshare then the world is your ... -- Peter Pilgrim Operations/IT - Credit Suisse First Boston, 10 South Colonnade, London E14 4QJ, United Kingdom Tel: +44 (0)207 883 4447 == This message is for the sole use of the intended recipient. If you received this message in error please delete it and notify us. If this message was misdirected, CSFB does not waive any confidentiality or privilege. CSFB retains and monitors electronic communications sent through its network. Instructions transmitted over this system are not binding on CSFB until they are confirmed by us. Message transmission is not guaranteed to be secure. == - 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]
RE: Theoretical debate
You know, kind of off-topic, but you remind me of a conversation I had with
someone at work here, maybe you guys would have some input...
I know what various patterns tell us we should do, but in practice... you
guys of course have your ActionForms that transfer data from the view to the
control layer... do you then have Data Transfer Objects, or Value Objects,
or whatever terms you want to use, to hand off to your model layer?
In other words, do you get data IN via ActionForm to an Action, then
transfer all that data to another Data Transfer Object, then pass that off
to some subordinate class to do the actual processing?
I ask because most of the Struts apps I've seen don't bother with the DTO's,
they just pass the ActionForm to the subordinate classes, or else pass them
as parameters. It seems that regardless of what literature is telling is we
should do, in practice (GENERALLY), people don't bother with the DTO's.
Have I just looked at the wrong apps? What are most people doing in this
regard?
Frank
From: "Brian Lee" <[EMAIL PROTECTED]>
Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: RE: Theoretical debate
Date: Thu, 17 Jun 2004 16:54:26 -0400
I think struts' concept of separating your actions from your data is
admirable and should be followed. The concept of your value/transfer
objects (basically the form) also having business logic sounds acceptable
at first but rapidly becomes a nightmare when you try to use the same
value/transfer objects in multiple processes.
I think it's a generally accepted practice that separating data from logic
is a "Good Thing"(tm).
BAL
From: "Hookom, Jacob" <[EMAIL PROTECTED]>
To: 'Struts Users Mailing List' <[EMAIL PROTECTED]>
Subject: RE: Theoretical debate
Date: Thu, 17 Jun 2004 14:57:31 -0500
I completely agree with what Crysalis is trying to push, also a framework
called VRaptor (vraptor.org) also pushes the same idea of moving away from
the procedural weight that Struts promotes.
Look at JSF, do you have actions? No, JSF just updates your POJO beans and
calls methods on them. Why have an ActionForm or have to create all of
these Actions that are simply getter/setter adapters? Please don't be too
quick to retort to my supposed anti-struts mindset, but there are other
frameworks out there that allow direct interaction with my business
objects
and don't require a heck of a lot of framework specific coding.
---
Example:
To have a multi-page form with JSF, I just create a bean that sits in
Session scope that has a series of getters and setters. JSF will also
allow
me to pre-set relationships to other objects at creation time. Then, when
I'm ready to submit the multi-page form, I just put in the jsp
#{myFormBean.submit}. No action mappings, only a managed bean entry.
With Struts, I have to create an ActionForm objects (can't just use a
business object I already have), and then create separate Action objects
to
manipulate that ActionForm.
---
-Jacob Hookom
-Original Message-
From: Frank Zammetti [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 17, 2004 2:29 PM
To: [EMAIL PROTECTED]
Subject: Theoretical debate
Last night I was Googling for something and I stumbled across the Crysalis
framework. I was actualyl intrigued by the underlying premise of it and I
wanted to see what others thought about it.
In a nutshell and in my own words, Crysalis
(http://chrysalis.sourceforge.net/) has the underlying idea that when you
develop in most MVC frameworks, Struts chief among them, you are actually
doing something unnatural and in a way at odds with basic OOP design.
Think about a shopping cart example... If you were going to write that in
straight Java, not for the web or anything, how would you model it? Most
likely you would have a ShoppingCart class with a number of methods in it,
things like addItem(), removeItem(), totalPrice(), etc.
In Struts, although you aren't FORCED to, what you GENERALLY do is create
three different Action classes like addItemAction, removeItemAction and
totalPriceAction, and each is called in response to a form submission.
But isn't it kind of odd that your object model isn't following what you
probably think in your head is the right way, i.e., one class with
multiple
related methods? Proper encapsulation and all that jazz, right?
Well, Crysalis does just that. It's controller elements are regular Java
classes with multiple methods. What you wind up with is something that
resembles Remote Procedure Calls instead of numerous servlets as
controllers.
In other words, you would create the ShoppingCart object just as I
described
above, with all three methods. Then, when you submit a form, the action
is
something along the lines of "ShoppingCart.addItem.cmd". ShoppingCart is
the class to execute, addItem the me
RE: Theoretical debate
I know what your saying, it's the way I do things as well, doing very little work in the Actions aside from tossing values around and calling subordinate classes to do the real work. But doesn't that in a sense support the idea of an application being services cobbled together? What I mean is that the Struts portion of your application is really what is forming the application, if by application we mean the coherent whole set of pages that make up a larger system. In a sense, if you have that ShoppingCart object without it's methods, let's say as an EJB, on it's own it's not an application, it's when you make use of it from an Action that it becomes part of an application. Think of it this way... If you have a collection of EJB's that you call your "application", I would argue that's not correct, the application is really only formed when you have a layer above it, maybe a bunch of Struts Actions, that call on the services of those EJB's to form a whole application. In that mindset, I can see some logic to saying something like Crysalis is on a better path because your simplifying things a bit by essentially removing a layer. I think we're all conditioned to think that ADDING layers of abstaction is a good thing, but I wonder if that's not in a great many cases just added extra layers of complexity that we don't really need. That's why I made that statement about services. I mean, the whole Web Services movement, when taken to it's logical conclusion, tells us that we should be building applications by cobbling together a number of losely-coupled service requests, that taken together form a larger application. That's kind of the whole point of WS. Also, please no one get the idea that I'm saying Struts is anything but good, or that I'm saying we shouldn't be doing things the way we are doing them now. My point in starting this thread was just to point what I thought was an interesting way to look at things that I hadn't considered before, at least not precisely. If anything, much of the responses I've read have reinforced my belief that what we're doing now in Struts is generally pretty good. I am a big believer in the services model of development, have been for a number of years now (although I'm not so sure the current forms of this methodology are spot on just yet), so discussions of things like this are always of interest to me. Frank From: Hubert Rabago <[EMAIL PROTECTED]> Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]> To: Struts Users Mailing List <[EMAIL PROTECTED]> Subject: RE: Theoretical debate Date: Thu, 17 Jun 2004 13:29:27 -0700 (PDT) > From: Frank Zammetti [mailto:[EMAIL PROTECTED] > Most likely you would have a ShoppingCart class with a number of methods in it, > things like addItem(), removeItem(), totalPrice(), etc. I follow this design on my applications, on the *business logic* tier. On that tier (whether I implement it as EJBs or POJOs), I would have an actual business object that would have these methods. I tend to look at Struts as a necessary add-on to the application to give it a web front end. To me, my web application isn't "a collection of services that are executed to form a coherent larger application", rather it's just an interface to the actual application that runs on the server. --- "Hookom, Jacob" <[EMAIL PROTECTED]> wrote: > With Struts, I have to create an ActionForm objects (can't just use a > business object I already have), and then create separate Action objects to Because of the way I view my app, I have no problem separating my view of the objects in my interface and my app's business objects. I fully understand the need for separate ActionForm objects (users work with untyped string values, my business tier works with typed values, the Action object goes in between). Still, I don't like having to create string-ified counterparts of my business objects. That's how the FormDef project began ( http://www.rabago.net/struts/formdef and http://formdef.dev.java.net/ ). I haven't tried JSF yet, but I don't think I want my business tier objects "contaminated" with presentation-tier specifics, such as the callback methods JSF needs on their managed beans. > > Any thoughts? > > Frank > Hubert __ Do you Yahoo!? Yahoo! Mail is new and improved - Check it out! http://promotions.yahoo.com/new_mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ FREE pop-up blocking with the new MSN Toolbar get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Theoretical debate
I describe this in more detail in the book, but my take on this is that Struts and JSF are focused on different parts of the application. They also overlap in some areas, however, which is probably the cause for this endless discussion. In particular, I've noticed that a simple "hello world" application with two screens (paint form and respond to POST) looks very similar in JSF and Struts, at least on the surface: - Form beans are "model objects" in JSF - both Struts and JSF have their own tag library for defining HTML form fields. (at first glance the main advantage of JSF is having validation inline with HTML form tags) - you have FacesServlet instead of ActionServlet - navigation rules instead of action-forwards - ApplicationHandlers and EventListeners instead of Actions JSF has a much more robust component and event handling model, though, which makes it more like a "real" GUI framework to work with. (Struts is almost like a base case of JSF, with only one type of event.) The advantage is that JSF is better suited for dealing with more complex UIs where you have lots of components with independent state to manage. Here's one example of something that should be much easier with JSF than Struts: Imagine a page with three sortable tables. When you click a header on table #1, the page reloads, re-sorting table #1. But the current sorting on tables #2 and #3 should remain constant. This is obviously possible with Struts, but requires you to futz with URL vars somewhere or rely on session scope. JSF insulates you one layer from all that, providing component state management as part of the framework. The _disadvantage_ to JSF is that when your UI is *simple* (closer to hello-world in complexity), JSF seems to be more work to deal with. I've found that the insulation from the details of HTTP/request-response makes doing simple things much more difficult, while Struts is more gentle-slope. You don't have to use Tiles and Validator right away, and there's an obvious, easy path to migrate an ad-hoc/Model 1 servlet or JSP to Struts. -- Bill -- Bill Schneider Chief Architect Vecna Technologies, Inc. 5004 Lehigh Road, Suite B College Park, MD 20740 [EMAIL PROTECTED] t: 301-864-7594 f: 301-699-3180 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Theoretical debate
> -Original Message- > From: Hookom, Jacob [mailto:[EMAIL PROTECTED] > Sent: 17 June 2004 20:58 > To: 'Struts Users Mailing List' > Subject: RE: Theoretical debate > > > I completely agree with what Crysalis is trying to push, also > a framework > called VRaptor (vraptor.org) also pushes the same idea of > moving away from > the procedural weight that Struts promotes. > > Look at JSF, do you have actions? No, JSF just updates your > POJO beans and > calls methods on them. Why have an ActionForm or have to > create all of > these Actions that are simply getter/setter adapters? Please Can't you use DispatchAction or LookupDispatchAction? What if your Action is not a simple getter or setter adapter? If you need to call a Business Delegate or perform some customer specifier validation for input or make a series of call outs then you cannot easily say Struts is wrong. The Action is where you bind the presentation tier and the business logic tier. > don't be too > quick to retort to my supposed anti-struts mindset, but there > are other > frameworks out there that allow direct interaction with my > business objects > and don't require a heck of a lot of framework specific coding. > I think what you are alluding to is a generic XML action controller that you can bind using yet another XML configuration file. If you can build such a beast and sell it to the mindshare then the world is your ... -- Peter Pilgrim Operations/IT - Credit Suisse First Boston, 10 South Colonnade, London E14 4QJ, United Kingdom Tel: +44 (0)207 883 4447 == This message is for the sole use of the intended recipient. If you received this message in error please delete it and notify us. If this message was misdirected, CSFB does not waive any confidentiality or privilege. CSFB retains and monitors electronic communications sent through its network. Instructions transmitted over this system are not binding on CSFB until they are confirmed by us. Message transmission is not guaranteed to be secure. == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Theoretical debate
I personally think struts is spot on. I think it does follow Java & OO principles, and many J2EE patterns. My struts apps generally consist of DAOs which handle simple methods, and some services which handle more complex operations. These interact with beans which are persisted using OJB. The actions (and jsps) provide the view layer. All my actions do is parse submitted data, and call methods in services/DAOs. I would not be atall happy at providing direct access to services due to lack of validation/security checks. Some of my actions are quite big, providing multi level checks on data. This whole idea of "transparent" access to beans/services scares me. It reminds me of CGI programming, and all the security problems that came with it. Web apps are very different to traditional apps. With traditional apps the user has no access to variables being passed between the user interface and service layer. With webapps they can do anythign they like to data that gets as far as them. Eg. Say a users looks at their list of transactions, and clicks on a link to view details: "getTransaction.do?transactionId=753" The user can change the url to "=750" and try to access someone elses transaction. The first thing a struts app should do is load transaction 753, and see who it belongs to. If it doesnt belong to the user (who is probably recorded in the session) then send them on to an error page. Without the struts action doing this check, the method in the service: getTransaction(int transactionId) will probably be called directly. Normally a service would not be expected to do the check, as it will probably be used by UI components as well as low level system components. The struts actions (if coded well) add a nice isolation layer between the view and business services. Anyway, that's my take on things! Daniel. > -Original Message- > From: mike [mailto:[EMAIL PROTECTED] > Sent: 17 June 2004 21:45 > To: Struts Users Mailing List; Struts Users Mailing List > Subject: RE: Theoretical debate > > > +1 I personally do not find what you have to or can do with > Struts much of > a problem at all. I like the freedom the separation gives me. It is > rather like the defensive idea of Aaron Nitzovitch in chess. If you just > defend a square or piece as much as required, all the defensive > pieces are > tied down. However, if you add an additional defender, then all your > pieces incorporated into the defense are free to abandon that task and a > very interesting and deep interchange of offense and defense > results. The > separation of functions in Struts does this for me. I think I prefer the > Struts approach to the JSF approach as well, although like > everyone else, I > would like and try to achieve a hybrid for my purposes. > > Michael > > At 01:29 PM 6/17/2004, Hubert Rabago wrote: > > > > From: Frank Zammetti [mailto:[EMAIL PROTECTED] > > > Most likely you would have a ShoppingCart class with a > number of methods > >in it, > > > things like addItem(), removeItem(), totalPrice(), etc. > > > >I follow this design on my applications, on the *business logic* tier. > >On that tier (whether I implement it as EJBs or POJOs), I would have an > >actual business object that would have these methods. > >I tend to look at Struts as a necessary add-on to the application to give > >it a web front end. > >To me, my web application isn't "a collection of services that > are executed > >to form a coherent larger application", rather it's just an interface > >to the actual application that runs on the server. > > > > > > --- "Hookom, Jacob" <[EMAIL PROTECTED]> wrote: > > > With Struts, I have to create an ActionForm objects (can't just use a > > > business object I already have), and then create separate > Action objects > >to > > > >Because of the way I view my app, I have no problem separating > my view of the > >objects in my interface and my app's business objects. I fully > understand > >the need for separate ActionForm objects (users work with untyped string > >values, my business tier works with typed values, the Action > object goes in > >between). Still, I don't like having to create string-ified > counterparts of > >my business objects. That's how the FormDef project began ( > >http://www.rabago.net/struts/formdef and http://formdef.dev.java.net/ ). > > > >I haven't tried JSF yet, but I don't think I want my business > tier objects > >"contaminated" with presentation-tier specifics, such as the > callback methods > >JSF needs on their managed
RE: Theoretical debate
There is a LOT MORE to JSF than that. The event structure is important.
At 07:56 PM 6/17/2004, souravm wrote:
Hi All,
My understanding is JSF is nothing but an improved implementation of
Struts' philosophy where all Struts'' internals are made transparent to
the end user. So what end user gets is - the same functionality of
Struts but with lesser coding. In that way I find JSF to be logical
extension of Struts.
Please rectify me if my high level understanding is wrong.
Regards,
Sourav
-Original Message-
From: Hookom, Jacob [mailto:[EMAIL PROTECTED]
Sent: Friday, June 18, 2004 1:28 AM
To: 'Struts Users Mailing List'
Subject: RE: Theoretical debate
I completely agree with what Crysalis is trying to push, also a
framework
called VRaptor (vraptor.org) also pushes the same idea of moving away
from
the procedural weight that Struts promotes.
Look at JSF, do you have actions? No, JSF just updates your POJO beans
and
calls methods on them. Why have an ActionForm or have to create all of
these Actions that are simply getter/setter adapters? Please don't be
too
quick to retort to my supposed anti-struts mindset, but there are other
frameworks out there that allow direct interaction with my business
objects
and don't require a heck of a lot of framework specific coding.
---
Example:
To have a multi-page form with JSF, I just create a bean that sits in
Session scope that has a series of getters and setters. JSF will also
allow
me to pre-set relationships to other objects at creation time. Then,
when
I'm ready to submit the multi-page form, I just put in the jsp
#{myFormBean.submit}. No action mappings, only a managed bean entry.
With Struts, I have to create an ActionForm objects (can't just use a
business object I already have), and then create separate Action objects
to
manipulate that ActionForm.
---
-Jacob Hookom
-Original Message-
From: Frank Zammetti [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 17, 2004 2:29 PM
To: [EMAIL PROTECTED]
Subject: Theoretical debate
Last night I was Googling for something and I stumbled across the
Crysalis
framework. I was actualyl intrigued by the underlying premise of it and
I
wanted to see what others thought about it.
In a nutshell and in my own words, Crysalis
(http://chrysalis.sourceforge.net/) has the underlying idea that when
you
develop in most MVC frameworks, Struts chief among them, you are
actually
doing something unnatural and in a way at odds with basic OOP design.
Think about a shopping cart example... If you were going to write that
in
straight Java, not for the web or anything, how would you model it?
Most
likely you would have a ShoppingCart class with a number of methods in
it,
things like addItem(), removeItem(), totalPrice(), etc.
In Struts, although you aren't FORCED to, what you GENERALLY do is
create
three different Action classes like addItemAction, removeItemAction and
totalPriceAction, and each is called in response to a form submission.
But isn't it kind of odd that your object model isn't following what you
probably think in your head is the right way, i.e., one class with
multiple
related methods? Proper encapsulation and all that jazz, right?
Well, Crysalis does just that. It's controller elements are regular
Java
classes with multiple methods. What you wind up with is something that
resembles Remote Procedure Calls instead of numerous servlets as
controllers.
In other words, you would create the ShoppingCart object just as I
described
above, with all three methods. Then, when you submit a form, the action
is
something along the lines of "ShoppingCart.addItem.cmd". ShoppingCart
is
the class to execute, addItem the method and cmd is a suffix to direct
the
request, just like extensions in your Struts apps map requests to
ActionServlet.
The elements of the submitted form are treated as the parameters of the
method being called, making it rather elegant.
I haven't gotten into any real detail on Crysalis, but I was interested
in
getting other peoples' thoughts on the underlying principal (which I
*THINK*
I've stated properly!). It was rather interesting to me because I'd
never
reall considered looking at it that way, and certainly it's not the way
you
typically approach a Struts-based application. It was also interesting
to
me because I've for about four years now been preaching here at work
that we
should write our applications as a collection of services that are
executed
to form a coherent larger application, which is very much along the
lines of
this (so I guess I actually HAVE looked at it this way in a sense, but
not
exactly).
Any thoughts?
Frank
_
Watch the online reality show Mixed Messages with a friend and enter to
win
a trip to NY
http://www.msnmessenger-download.click-url.com/go/onm00200497ave/direct/
01/
--
RE: Theoretical debate
Hi, This is a very good detail explanation given by Hans Bergsten Looking through all the other threads dealing with this question, I see that most of the points have already been mentioned but let's see if I can give you a more conclusive answer. I describe this in more detail in the book, but my take on this is that Struts and JSF are focused on different parts of the application. They also overlap in some areas, however, which is probably the cause for this endless discussion. I refer to Struts as an "application framework". It's main goal in life is to hand off the processing of a request to code registered for the task indicated by the URI, and then hand off the response generation to another piece of code registered under a name returned by the request processing piece of code. Struts doesn't care much about how the request is processed or how the response is generated. Typically JSP is used to generate the response, and if so, there are tag libraries that can help, but you can use any template technology you like, e.g., Velocity. I refer to JSF as a "UI framework." It's focus is on user interface components, which are bound directly to business logic properties holding their values. A request is processed through these components with the help of other well-defined objects attached to the component. For instance, an input component reads its value from the request, converts it to the business logic data type by calling an attached converter, validates it by calling an attached validator, and if everything is okay, sets the business logic property bound to the component to the new value. A command component looks for a marker in the request that tells it if it triggered this request, and if so, queues an event. An event listener bound to the command component handles the event when all components have processed their input, typically by calling business logic code, and may return an "outcome" mapped to a "view ID" to tell JSF to use a different set of components to render the response. The response is generated by the components, or more commonly, by an attached renderer. So JSF hides a lot of the HTTP details and let you develop application code that's focused on the business objective rather that fiddling around with details that add no value to the application. More importantly, a JSF component handles both output and input. For instance, an date input component can let the user input the date by selecting a year, a month and a day from three separate selection lists. Because it knows this, it can correctly read the three input values, merge them and convert the value to a java.util.Date object and update the business logic with this Date object. Struts, on the other hand, may provide a JSP tag that generates the three selection elements, but your application code must know about it and get all three values from the request. The overlap is in validation and navigation. JSF provides just the basics for component level validation out-of-the box, while Struts offers a more sophisticated validation mechanism. I don't think the functional differences in navigation are so big, rather different because of differences between the framework. The important point, though, is that you can plug in custom validation and navigation support in JSF if the defaults aren't good enough for your application. So, that leaves us with the big question: which should I use? My standard answer is that for an existing Struts application, if you want to migrate to JSF for the user interface, it may be a good idea to do it piece by piece with the help of the Struts-JSF integration library if the application is big and complex. If it's small, it's pretty straight forward to migrate all of it to JSF in one shot. But first you need to ask yourself if migrating is the right thing to do. For a complex user interface, the answer is probably "yes" (at least if you're still making user interface changes now and then). For an application with a simple user interface (e.g., mostly simple dynamic output rather than a lot of complex input), or an application that's rarely changed, the answer is probably "no". For a new application, JSF would be my first choice if the user interface is complex, or plain JSP or some other template technology if the user interface is simple. If there are Struts features you can't live without, or don't want to implement as JSF plug-ins, I would take a look at the Struts-JSF integration library and consider using both. Regards Kamakshya Prasad Mishra Sourav, you might know me -Original Message----- From: souravm [mailto:[EMAIL PROTECTED] Sent: Friday, June 18, 2004 11:56 AM To: Struts Users Mailing List Subject: RE: Theoretical debate Hi All, My understanding is JSF is nothing but an improved implementation of Struts' philosophy where all Struts''
RE: Theoretical debate
Hi All,
My understanding is JSF is nothing but an improved implementation of
Struts' philosophy where all Struts'' internals are made transparent to
the end user. So what end user gets is - the same functionality of
Struts but with lesser coding. In that way I find JSF to be logical
extension of Struts.
Please rectify me if my high level understanding is wrong.
Regards,
Sourav
-Original Message-
From: Hookom, Jacob [mailto:[EMAIL PROTECTED]
Sent: Friday, June 18, 2004 1:28 AM
To: 'Struts Users Mailing List'
Subject: RE: Theoretical debate
I completely agree with what Crysalis is trying to push, also a
framework
called VRaptor (vraptor.org) also pushes the same idea of moving away
from
the procedural weight that Struts promotes.
Look at JSF, do you have actions? No, JSF just updates your POJO beans
and
calls methods on them. Why have an ActionForm or have to create all of
these Actions that are simply getter/setter adapters? Please don't be
too
quick to retort to my supposed anti-struts mindset, but there are other
frameworks out there that allow direct interaction with my business
objects
and don't require a heck of a lot of framework specific coding.
---
Example:
To have a multi-page form with JSF, I just create a bean that sits in
Session scope that has a series of getters and setters. JSF will also
allow
me to pre-set relationships to other objects at creation time. Then,
when
I'm ready to submit the multi-page form, I just put in the jsp
#{myFormBean.submit}. No action mappings, only a managed bean entry.
With Struts, I have to create an ActionForm objects (can't just use a
business object I already have), and then create separate Action objects
to
manipulate that ActionForm.
---
-Jacob Hookom
-Original Message-
From: Frank Zammetti [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 17, 2004 2:29 PM
To: [EMAIL PROTECTED]
Subject: Theoretical debate
Last night I was Googling for something and I stumbled across the
Crysalis
framework. I was actualyl intrigued by the underlying premise of it and
I
wanted to see what others thought about it.
In a nutshell and in my own words, Crysalis
(http://chrysalis.sourceforge.net/) has the underlying idea that when
you
develop in most MVC frameworks, Struts chief among them, you are
actually
doing something unnatural and in a way at odds with basic OOP design.
Think about a shopping cart example... If you were going to write that
in
straight Java, not for the web or anything, how would you model it?
Most
likely you would have a ShoppingCart class with a number of methods in
it,
things like addItem(), removeItem(), totalPrice(), etc.
In Struts, although you aren't FORCED to, what you GENERALLY do is
create
three different Action classes like addItemAction, removeItemAction and
totalPriceAction, and each is called in response to a form submission.
But isn't it kind of odd that your object model isn't following what you
probably think in your head is the right way, i.e., one class with
multiple
related methods? Proper encapsulation and all that jazz, right?
Well, Crysalis does just that. It's controller elements are regular
Java
classes with multiple methods. What you wind up with is something that
resembles Remote Procedure Calls instead of numerous servlets as
controllers.
In other words, you would create the ShoppingCart object just as I
described
above, with all three methods. Then, when you submit a form, the action
is
something along the lines of "ShoppingCart.addItem.cmd". ShoppingCart
is
the class to execute, addItem the method and cmd is a suffix to direct
the
request, just like extensions in your Struts apps map requests to
ActionServlet.
The elements of the submitted form are treated as the parameters of the
method being called, making it rather elegant.
I haven't gotten into any real detail on Crysalis, but I was interested
in
getting other peoples' thoughts on the underlying principal (which I
*THINK*
I've stated properly!). It was rather interesting to me because I'd
never
reall considered looking at it that way, and certainly it's not the way
you
typically approach a Struts-based application. It was also interesting
to
me because I've for about four years now been preaching here at work
that we
should write our applications as a collection of services that are
executed
to form a coherent larger application, which is very much along the
lines of
this (so I guess I actually HAVE looked at it this way in a sense, but
not
exactly).
Any thoughts?
Frank
_
Watch the online reality show Mixed Messages with a friend and enter to
win
a trip to NY
http://www.msnmessenger-download.click-url.com/go/onm00200497ave/direct/
01/
Re: Theoretical debate
I've been playing with JSF recently. If the standard sun version had
file upload support
The Form, Action JSP is all very well and good but there are certain
limitations to this, for example to be able to plug a non webapp front
on the model you have to have a bunch of util classes that manipulate
your object model, conversions and such like, so in addition to the web
layer struts stuff you've got a hole bunch of files that in JSF you
could reduce a lot.
Having the bean (action form) do more than just be a server side
representation of a view makes the actual business of making an
application cleaner and more straight forward. But there's also the
option of using Listeners rather than doing the "doing" stuff in the
bean itself.
It also makes sense having validation defined in the view it means not
having yet another xml file, yes I know xdoclet can help but its
usually 1 step behind (struts 1.2 and servlet 24 cant be done with
stable version). OF course having the programming logic in a javaclass
makes sense but the choosing of the validation to use and which form
element to associate it which makes more sense in the JSP.
Where struts would perhaps be handier would be when you need to stick a
weblayer on something thats running already. But then i don't see any
huge problems doing this in JSF either.
I just hope the file upload support happens soon, and i can start do
all my forms in JSF.
Mark
On 17 Jun 2004, at 22:54, Brian Lee wrote:
I think struts' concept of separating your actions from your data is
admirable and should be followed. The concept of your value/transfer
objects (basically the form) also having business logic sounds
acceptable at first but rapidly becomes a nightmare when you try to
use the same value/transfer objects in multiple processes.
I think it's a generally accepted practice that separating data from
logic is a "Good Thing"(tm).
BAL
From: "Hookom, Jacob" <[EMAIL PROTECTED]>
To: 'Struts Users Mailing List' <[EMAIL PROTECTED]>
Subject: RE: Theoretical debate
Date: Thu, 17 Jun 2004 14:57:31 -0500
I completely agree with what Crysalis is trying to push, also a
framework
called VRaptor (vraptor.org) also pushes the same idea of moving away
from
the procedural weight that Struts promotes.
Look at JSF, do you have actions? No, JSF just updates your POJO
beans and
calls methods on them. Why have an ActionForm or have to create all
of
these Actions that are simply getter/setter adapters? Please don't
be too
quick to retort to my supposed anti-struts mindset, but there are
other
frameworks out there that allow direct interaction with my business
objects
and don't require a heck of a lot of framework specific coding.
---
Example:
To have a multi-page form with JSF, I just create a bean that sits in
Session scope that has a series of getters and setters. JSF will
also allow
me to pre-set relationships to other objects at creation time. Then,
when
I'm ready to submit the multi-page form, I just put in the jsp
#{myFormBean.submit}. No action mappings, only a managed bean entry.
With Struts, I have to create an ActionForm objects (can't just use a
business object I already have), and then create separate Action
objects to
manipulate that ActionForm.
---
-Jacob Hookom
-Original Message-
From: Frank Zammetti [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 17, 2004 2:29 PM
To: [EMAIL PROTECTED]
Subject: Theoretical debate
Last night I was Googling for something and I stumbled across the
Crysalis
framework. I was actualyl intrigued by the underlying premise of it
and I
wanted to see what others thought about it.
In a nutshell and in my own words, Crysalis
(http://chrysalis.sourceforge.net/) has the underlying idea that when
you
develop in most MVC frameworks, Struts chief among them, you are
actually
doing something unnatural and in a way at odds with basic OOP design.
Think about a shopping cart example... If you were going to write
that in
straight Java, not for the web or anything, how would you model it?
Most
likely you would have a ShoppingCart class with a number of methods
in it,
things like addItem(), removeItem(), totalPrice(), etc.
In Struts, although you aren't FORCED to, what you GENERALLY do is
create
three different Action classes like addItemAction, removeItemAction
and
totalPriceAction, and each is called in response to a form submission.
But isn't it kind of odd that your object model isn't following what
you
probably think in your head is the right way, i.e., one class with
multiple
related methods? Proper encapsulation and all that jazz, right?
Well, Crysalis does just that. It's controller elements are regular
Java
classes with multiple methods. What you wind up with is something
that
resembles Remote Procedure Calls instead of nume
RE: Theoretical debate
Maybe its old school but I always thought true object oriented design
involved encapsulation of data AND behavior together whenever possible.
The trick is to know how to model correctly it to maximize
encapsulation.
One tries not to expose more than necessary. In order to expose as
little as possible, generally the behavior usually has to live as close
to the data as possible so the all the data doesn't have to be publicy
exposed to implement a behavior.
Behavior which acts across different object/class boundaries is more
suceptable to breaking than behavior encapsulated in one object.
Admittedly, there is no way to avoid behavior that acts across
object/class boundaries but whenever it is possible, I would do it hands
down.
-Original Message-
From: Brian Lee [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 17, 2004 4:54 PM
To: [EMAIL PROTECTED]
Subject: RE: Theoretical debate
I think struts' concept of separating your actions from your data is
admirable and should be followed. The concept of your value/transfer
objects (basically the form) also having business logic sounds
acceptable at first but rapidly becomes a nightmare when you try to use
the same value/transfer objects in multiple processes.
I think it's a generally accepted practice that separating data from
logic is a "Good Thing"(tm).
BAL
>From: "Hookom, Jacob" <[EMAIL PROTECTED]>
>To: 'Struts Users Mailing List' <[EMAIL PROTECTED]>
>Subject: RE: Theoretical debate
>Date: Thu, 17 Jun 2004 14:57:31 -0500
>
>I completely agree with what Crysalis is trying to push, also a
>framework called VRaptor (vraptor.org) also pushes the same idea of
>moving away from the procedural weight that Struts promotes.
>
>Look at JSF, do you have actions? No, JSF just updates your POJO beans
>and calls methods on them. Why have an ActionForm or have to create
>all of these Actions that are simply getter/setter adapters? Please
>don't be too quick to retort to my supposed anti-struts mindset, but
>there are other frameworks out there that allow direct interaction with
>my business objects and don't require a heck of a lot of framework
specific coding.
>
>---
>
>Example:
>To have a multi-page form with JSF, I just create a bean that sits in
>Session scope that has a series of getters and setters. JSF will also
>allow me to pre-set relationships to other objects at creation time.
>Then, when I'm ready to submit the multi-page form, I just put in the
>jsp #{myFormBean.submit}. No action mappings, only a managed bean
>entry.
>
>With Struts, I have to create an ActionForm objects (can't just use a
>business object I already have), and then create separate Action
>objects to manipulate that ActionForm.
>
>---
>
>-Jacob Hookom
>
>-Original Message-
>From: Frank Zammetti [mailto:[EMAIL PROTECTED]
>Sent: Thursday, June 17, 2004 2:29 PM
>To: [EMAIL PROTECTED]
>Subject: Theoretical debate
>
>Last night I was Googling for something and I stumbled across the
>Crysalis framework. I was actualyl intrigued by the underlying premise
>of it and I wanted to see what others thought about it.
>
>In a nutshell and in my own words, Crysalis
>(http://chrysalis.sourceforge.net/) has the underlying idea that when
>you develop in most MVC frameworks, Struts chief among them, you are
>actually doing something unnatural and in a way at odds with basic OOP
design.
>
>Think about a shopping cart example... If you were going to write that
>in straight Java, not for the web or anything, how would you model it?
>Most likely you would have a ShoppingCart class with a number of
>methods in it, things like addItem(), removeItem(), totalPrice(), etc.
>
>In Struts, although you aren't FORCED to, what you GENERALLY do is
>create three different Action classes like addItemAction,
>removeItemAction and totalPriceAction, and each is called in response
to a form submission.
>
>But isn't it kind of odd that your object model isn't following what
>you probably think in your head is the right way, i.e., one class with
>multiple related methods? Proper encapsulation and all that jazz,
right?
>
>Well, Crysalis does just that. It's controller elements are regular
>Java classes with multiple methods. What you wind up with is something
>that resembles Remote Procedure Calls instead of numerous servlets as
>controllers.
>
>In other words, you would create the ShoppingCart object just as I
>described
>
>above, with all three methods. Then, when you submit a form, the
>action is something along the lines of "ShoppingCart.addItem.cmd".
>ShoppingCart is the class to execute, addItem the method and cmd is a
>suffix to direct the request
RE: Theoretical debate
> In Struts, although you aren't FORCED to, what you GENERALLY do is create > three different Action classes like addItemAction, removeItemAction and > totalPriceAction, and each is called in response to a form submission. > > But isn't it kind of odd that your object model isn't following what you > probably think in your head is the right way, i.e., one class with multiple > related methods? Proper encapsulation and all that jazz, right? Frank, you could view web application development as event programming just like any other application. There are several layers that have various responsibilities. The call eventually gets to your model where you can use the appropriate OO principles and design strategies. I wouldn't consider the Struts portion the object model, but more of an web presentation layer which utilizes the MVC design pattern in order to communicate with the model and populate and display the appropriate view. I think of an Action as a web event, which can then delegate to a business event which does the actual work (or more appropriately delegates to others...typical management stuff :) ). The business event eventually reports back to the web event which can then report back to the web controller. IMHO, Struts follows solid and proven design patterns. In fact, one could argue that it is very OO, in that it promotes loose coupling with each component being very cohesive. I will admit, it gives you plenty of rope to hang yourself My 2 cents. robert > -Original Message- > From: Frank Zammetti [mailto:[EMAIL PROTECTED] > Sent: Thursday, June 17, 2004 3:29 PM > To: [EMAIL PROTECTED] > Subject: Theoretical debate > > > Last night I was Googling for something and I stumbled across the Crysalis > framework. I was actualyl intrigued by the underlying premise of it and I > wanted to see what others thought about it. > > In a nutshell and in my own words, Crysalis > (http://chrysalis.sourceforge.net/) has the underlying idea that when you > develop in most MVC frameworks, Struts chief among them, you are actually > doing something unnatural and in a way at odds with basic OOP design. > > Think about a shopping cart example... If you were going to write that in > straight Java, not for the web or anything, how would you model it? Most > likely you would have a ShoppingCart class with a number of methods in it, > things like addItem(), removeItem(), totalPrice(), etc. > > In Struts, although you aren't FORCED to, what you GENERALLY do is create > three different Action classes like addItemAction, removeItemAction and > totalPriceAction, and each is called in response to a form submission. > > But isn't it kind of odd that your object model isn't following what you > probably think in your head is the right way, i.e., one class with multiple > related methods? Proper encapsulation and all that jazz, right? > > Well, Crysalis does just that. It's controller elements are regular Java > classes with multiple methods. What you wind up with is something that > resembles Remote Procedure Calls instead of numerous servlets as > controllers. > > In other words, you would create the ShoppingCart object just as I described > above, with all three methods. Then, when you submit a form, the action is > something along the lines of "ShoppingCart.addItem.cmd". ShoppingCart is > the class to execute, addItem the method and cmd is a suffix to direct the > request, just like extensions in your Struts apps map requests to > ActionServlet. > > The elements of the submitted form are treated as the parameters of the > method being called, making it rather elegant. > > I haven't gotten into any real detail on Crysalis, but I was interested in > getting other peoples' thoughts on the underlying principal (which I *THINK* > I've stated properly!). It was rather interesting to me because I'd never > reall considered looking at it that way, and certainly it's not the way you > typically approach a Struts-based application. It was also interesting to > me because I've for about four years now been preaching here at work that we > should write our applications as a collection of services that are executed > to form a coherent larger application, which is very much along the lines of > this (so I guess I actually HAVE looked at it this way in a sense, but not > exactly). > > Any thoughts? > > Frank > > _ > Watch the online reality show Mixed Messages with a friend and enter to win > a trip to NY > http://www.msnmessenger-download.click-url.com/go/onm00200497ave/direct/01/ > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands,
RE: Theoretical debate
I think struts' concept of separating your actions from your data is
admirable and should be followed. The concept of your value/transfer objects
(basically the form) also having business logic sounds acceptable at first
but rapidly becomes a nightmare when you try to use the same value/transfer
objects in multiple processes.
I think it's a generally accepted practice that separating data from logic
is a "Good Thing"(tm).
BAL
From: "Hookom, Jacob" <[EMAIL PROTECTED]>
To: 'Struts Users Mailing List' <[EMAIL PROTECTED]>
Subject: RE: Theoretical debate
Date: Thu, 17 Jun 2004 14:57:31 -0500
I completely agree with what Crysalis is trying to push, also a framework
called VRaptor (vraptor.org) also pushes the same idea of moving away from
the procedural weight that Struts promotes.
Look at JSF, do you have actions? No, JSF just updates your POJO beans and
calls methods on them. Why have an ActionForm or have to create all of
these Actions that are simply getter/setter adapters? Please don't be too
quick to retort to my supposed anti-struts mindset, but there are other
frameworks out there that allow direct interaction with my business objects
and don't require a heck of a lot of framework specific coding.
---
Example:
To have a multi-page form with JSF, I just create a bean that sits in
Session scope that has a series of getters and setters. JSF will also
allow
me to pre-set relationships to other objects at creation time. Then, when
I'm ready to submit the multi-page form, I just put in the jsp
#{myFormBean.submit}. No action mappings, only a managed bean entry.
With Struts, I have to create an ActionForm objects (can't just use a
business object I already have), and then create separate Action objects to
manipulate that ActionForm.
---
-Jacob Hookom
-Original Message-
From: Frank Zammetti [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 17, 2004 2:29 PM
To: [EMAIL PROTECTED]
Subject: Theoretical debate
Last night I was Googling for something and I stumbled across the Crysalis
framework. I was actualyl intrigued by the underlying premise of it and I
wanted to see what others thought about it.
In a nutshell and in my own words, Crysalis
(http://chrysalis.sourceforge.net/) has the underlying idea that when you
develop in most MVC frameworks, Struts chief among them, you are actually
doing something unnatural and in a way at odds with basic OOP design.
Think about a shopping cart example... If you were going to write that in
straight Java, not for the web or anything, how would you model it? Most
likely you would have a ShoppingCart class with a number of methods in it,
things like addItem(), removeItem(), totalPrice(), etc.
In Struts, although you aren't FORCED to, what you GENERALLY do is create
three different Action classes like addItemAction, removeItemAction and
totalPriceAction, and each is called in response to a form submission.
But isn't it kind of odd that your object model isn't following what you
probably think in your head is the right way, i.e., one class with multiple
related methods? Proper encapsulation and all that jazz, right?
Well, Crysalis does just that. It's controller elements are regular Java
classes with multiple methods. What you wind up with is something that
resembles Remote Procedure Calls instead of numerous servlets as
controllers.
In other words, you would create the ShoppingCart object just as I
described
above, with all three methods. Then, when you submit a form, the action is
something along the lines of "ShoppingCart.addItem.cmd". ShoppingCart is
the class to execute, addItem the method and cmd is a suffix to direct the
request, just like extensions in your Struts apps map requests to
ActionServlet.
The elements of the submitted form are treated as the parameters of the
method being called, making it rather elegant.
I haven't gotten into any real detail on Crysalis, but I was interested in
getting other peoples' thoughts on the underlying principal (which I
*THINK*
I've stated properly!). It was rather interesting to me because I'd never
reall considered looking at it that way, and certainly it's not the way you
typically approach a Struts-based application. It was also interesting to
me because I've for about four years now been preaching here at work that
we
should write our applications as a collection of services that are executed
to form a coherent larger application, which is very much along the lines
of
this (so I guess I actually HAVE looked at it this way in a sense, but not
exactly).
Any thoughts?
Frank
_
Watch the online reality show Mixed Messages with a friend and enter to win
a trip to NY
http://www.msnmessenger-download.click-url.com/go/onm00200497ave/direct/01/
-
RE: Theoretical debate
+1 I personally do not find what you have to or can do with Struts much of a problem at all. I like the freedom the separation gives me. It is rather like the defensive idea of Aaron Nitzovitch in chess. If you just defend a square or piece as much as required, all the defensive pieces are tied down. However, if you add an additional defender, then all your pieces incorporated into the defense are free to abandon that task and a very interesting and deep interchange of offense and defense results. The separation of functions in Struts does this for me. I think I prefer the Struts approach to the JSF approach as well, although like everyone else, I would like and try to achieve a hybrid for my purposes. Michael At 01:29 PM 6/17/2004, Hubert Rabago wrote: > From: Frank Zammetti [mailto:[EMAIL PROTECTED] > Most likely you would have a ShoppingCart class with a number of methods in it, > things like addItem(), removeItem(), totalPrice(), etc. I follow this design on my applications, on the *business logic* tier. On that tier (whether I implement it as EJBs or POJOs), I would have an actual business object that would have these methods. I tend to look at Struts as a necessary add-on to the application to give it a web front end. To me, my web application isn't "a collection of services that are executed to form a coherent larger application", rather it's just an interface to the actual application that runs on the server. --- "Hookom, Jacob" <[EMAIL PROTECTED]> wrote: > With Struts, I have to create an ActionForm objects (can't just use a > business object I already have), and then create separate Action objects to Because of the way I view my app, I have no problem separating my view of the objects in my interface and my app's business objects. I fully understand the need for separate ActionForm objects (users work with untyped string values, my business tier works with typed values, the Action object goes in between). Still, I don't like having to create string-ified counterparts of my business objects. That's how the FormDef project began ( http://www.rabago.net/struts/formdef and http://formdef.dev.java.net/ ). I haven't tried JSF yet, but I don't think I want my business tier objects "contaminated" with presentation-tier specifics, such as the callback methods JSF needs on their managed beans. > > Any thoughts? > > Frank > Hubert __ Do you Yahoo!? Yahoo! Mail is new and improved - Check it out! http://promotions.yahoo.com/new_mail - 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]
RE: Theoretical debate
> From: Frank Zammetti [mailto:[EMAIL PROTECTED] > Most likely you would have a ShoppingCart class with a number of methods in it, > things like addItem(), removeItem(), totalPrice(), etc. I follow this design on my applications, on the *business logic* tier. On that tier (whether I implement it as EJBs or POJOs), I would have an actual business object that would have these methods. I tend to look at Struts as a necessary add-on to the application to give it a web front end. To me, my web application isn't "a collection of services that are executed to form a coherent larger application", rather it's just an interface to the actual application that runs on the server. --- "Hookom, Jacob" <[EMAIL PROTECTED]> wrote: > With Struts, I have to create an ActionForm objects (can't just use a > business object I already have), and then create separate Action objects to Because of the way I view my app, I have no problem separating my view of the objects in my interface and my app's business objects. I fully understand the need for separate ActionForm objects (users work with untyped string values, my business tier works with typed values, the Action object goes in between). Still, I don't like having to create string-ified counterparts of my business objects. That's how the FormDef project began ( http://www.rabago.net/struts/formdef and http://formdef.dev.java.net/ ). I haven't tried JSF yet, but I don't think I want my business tier objects "contaminated" with presentation-tier specifics, such as the callback methods JSF needs on their managed beans. > > Any thoughts? > > Frank > Hubert __ Do you Yahoo!? Yahoo! Mail is new and improved - Check it out! http://promotions.yahoo.com/new_mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Theoretical debate
> In Struts, although you aren't FORCED to, what you GENERALLY do is > create > three different Action classes like addItemAction, removeItemAction > and > totalPriceAction, and each is called in response to a form > submission. Most (if not all) the Actions in my current application extend LookupDispatchAction in order to help group common methods together. If I was doing a ShoppingCart, I would have a single ShoppingCartAction that contained add(), update(), delete(), as well as any private helper methods. I agree with you that most people do generally split that up into three seperate classes. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Theoretical debate
Just a follow up note on my blabber below, when using struts, you have to
educate developers on the lifecycle and what all the parts are to the struts
equation-- when a form gets reset, when it's validated, how to switch struts
modules, etc. Just take a look at this past week's user group questions...
-Original Message-
From: Hookom, Jacob [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 17, 2004 2:58 PM
To: 'Struts Users Mailing List'
Subject: RE: Theoretical debate
I completely agree with what Crysalis is trying to push, also a framework
called VRaptor (vraptor.org) also pushes the same idea of moving away from
the procedural weight that Struts promotes.
Look at JSF, do you have actions? No, JSF just updates your POJO beans and
calls methods on them. Why have an ActionForm or have to create all of
these Actions that are simply getter/setter adapters? Please don't be too
quick to retort to my supposed anti-struts mindset, but there are other
frameworks out there that allow direct interaction with my business objects
and don't require a heck of a lot of framework specific coding.
---
Example:
To have a multi-page form with JSF, I just create a bean that sits in
Session scope that has a series of getters and setters. JSF will also allow
me to pre-set relationships to other objects at creation time. Then, when
I'm ready to submit the multi-page form, I just put in the jsp
#{myFormBean.submit}. No action mappings, only a managed bean entry.
With Struts, I have to create an ActionForm objects (can't just use a
business object I already have), and then create separate Action objects to
manipulate that ActionForm.
---
-Jacob Hookom
-Original Message-
From: Frank Zammetti [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 17, 2004 2:29 PM
To: [EMAIL PROTECTED]
Subject: Theoretical debate
Last night I was Googling for something and I stumbled across the Crysalis
framework. I was actualyl intrigued by the underlying premise of it and I
wanted to see what others thought about it.
In a nutshell and in my own words, Crysalis
(http://chrysalis.sourceforge.net/) has the underlying idea that when you
develop in most MVC frameworks, Struts chief among them, you are actually
doing something unnatural and in a way at odds with basic OOP design.
Think about a shopping cart example... If you were going to write that in
straight Java, not for the web or anything, how would you model it? Most
likely you would have a ShoppingCart class with a number of methods in it,
things like addItem(), removeItem(), totalPrice(), etc.
In Struts, although you aren't FORCED to, what you GENERALLY do is create
three different Action classes like addItemAction, removeItemAction and
totalPriceAction, and each is called in response to a form submission.
But isn't it kind of odd that your object model isn't following what you
probably think in your head is the right way, i.e., one class with multiple
related methods? Proper encapsulation and all that jazz, right?
Well, Crysalis does just that. It's controller elements are regular Java
classes with multiple methods. What you wind up with is something that
resembles Remote Procedure Calls instead of numerous servlets as
controllers.
In other words, you would create the ShoppingCart object just as I described
above, with all three methods. Then, when you submit a form, the action is
something along the lines of "ShoppingCart.addItem.cmd". ShoppingCart is
the class to execute, addItem the method and cmd is a suffix to direct the
request, just like extensions in your Struts apps map requests to
ActionServlet.
The elements of the submitted form are treated as the parameters of the
method being called, making it rather elegant.
I haven't gotten into any real detail on Crysalis, but I was interested in
getting other peoples' thoughts on the underlying principal (which I *THINK*
I've stated properly!). It was rather interesting to me because I'd never
reall considered looking at it that way, and certainly it's not the way you
typically approach a Struts-based application. It was also interesting to
me because I've for about four years now been preaching here at work that we
should write our applications as a collection of services that are executed
to form a coherent larger application, which is very much along the lines of
this (so I guess I actually HAVE looked at it this way in a sense, but not
exactly).
Any thoughts?
Frank
_
Watch the online reality show Mixed Messages with a friend and enter to win
a trip to NY
http://www.msnmessenger-download.click-url.com/go/onm00200497ave/direct/01/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
RE: Theoretical debate
I completely agree with what Crysalis is trying to push, also a framework
called VRaptor (vraptor.org) also pushes the same idea of moving away from
the procedural weight that Struts promotes.
Look at JSF, do you have actions? No, JSF just updates your POJO beans and
calls methods on them. Why have an ActionForm or have to create all of
these Actions that are simply getter/setter adapters? Please don't be too
quick to retort to my supposed anti-struts mindset, but there are other
frameworks out there that allow direct interaction with my business objects
and don't require a heck of a lot of framework specific coding.
---
Example:
To have a multi-page form with JSF, I just create a bean that sits in
Session scope that has a series of getters and setters. JSF will also allow
me to pre-set relationships to other objects at creation time. Then, when
I'm ready to submit the multi-page form, I just put in the jsp
#{myFormBean.submit}. No action mappings, only a managed bean entry.
With Struts, I have to create an ActionForm objects (can't just use a
business object I already have), and then create separate Action objects to
manipulate that ActionForm.
---
-Jacob Hookom
-Original Message-
From: Frank Zammetti [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 17, 2004 2:29 PM
To: [EMAIL PROTECTED]
Subject: Theoretical debate
Last night I was Googling for something and I stumbled across the Crysalis
framework. I was actualyl intrigued by the underlying premise of it and I
wanted to see what others thought about it.
In a nutshell and in my own words, Crysalis
(http://chrysalis.sourceforge.net/) has the underlying idea that when you
develop in most MVC frameworks, Struts chief among them, you are actually
doing something unnatural and in a way at odds with basic OOP design.
Think about a shopping cart example... If you were going to write that in
straight Java, not for the web or anything, how would you model it? Most
likely you would have a ShoppingCart class with a number of methods in it,
things like addItem(), removeItem(), totalPrice(), etc.
In Struts, although you aren't FORCED to, what you GENERALLY do is create
three different Action classes like addItemAction, removeItemAction and
totalPriceAction, and each is called in response to a form submission.
But isn't it kind of odd that your object model isn't following what you
probably think in your head is the right way, i.e., one class with multiple
related methods? Proper encapsulation and all that jazz, right?
Well, Crysalis does just that. It's controller elements are regular Java
classes with multiple methods. What you wind up with is something that
resembles Remote Procedure Calls instead of numerous servlets as
controllers.
In other words, you would create the ShoppingCart object just as I described
above, with all three methods. Then, when you submit a form, the action is
something along the lines of "ShoppingCart.addItem.cmd". ShoppingCart is
the class to execute, addItem the method and cmd is a suffix to direct the
request, just like extensions in your Struts apps map requests to
ActionServlet.
The elements of the submitted form are treated as the parameters of the
method being called, making it rather elegant.
I haven't gotten into any real detail on Crysalis, but I was interested in
getting other peoples' thoughts on the underlying principal (which I *THINK*
I've stated properly!). It was rather interesting to me because I'd never
reall considered looking at it that way, and certainly it's not the way you
typically approach a Struts-based application. It was also interesting to
me because I've for about four years now been preaching here at work that we
should write our applications as a collection of services that are executed
to form a coherent larger application, which is very much along the lines of
this (so I guess I actually HAVE looked at it this way in a sense, but not
exactly).
Any thoughts?
Frank
_
Watch the online reality show Mixed Messages with a friend and enter to win
a trip to NY
http://www.msnmessenger-download.click-url.com/go/onm00200497ave/direct/01/
-
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]
RE: Theoretical debate
I recently downloaded IBATIS in order to use it for some object persistence... interestingly, their JPetStore implementation used a similar idea, although it was all struts based: Essentially, each "method" you want to call is actually mapped within the Action Mapping... so if you wanted to "searchProduct", then your mapping could be: Where the CatalogBean has the required method (searchProducts) It seems pretty neat so far... haven't had much time to play though... /A -Original Message- From: Frank Zammetti [mailto:[EMAIL PROTECTED] Sent: Thursday, June 17, 2004 2:29 PM To: [EMAIL PROTECTED] Subject: Theoretical debate Last night I was Googling for something and I stumbled across the Crysalis framework. I was actualyl intrigued by the underlying premise of it and I wanted to see what others thought about it. In a nutshell and in my own words, Crysalis (http://chrysalis.sourceforge.net/) has the underlying idea that when you develop in most MVC frameworks, Struts chief among them, you are actually doing something unnatural and in a way at odds with basic OOP design. Think about a shopping cart example... If you were going to write that in straight Java, not for the web or anything, how would you model it? Most likely you would have a ShoppingCart class with a number of methods in it, things like addItem(), removeItem(), totalPrice(), etc. In Struts, although you aren't FORCED to, what you GENERALLY do is create three different Action classes like addItemAction, removeItemAction and totalPriceAction, and each is called in response to a form submission. But isn't it kind of odd that your object model isn't following what you probably think in your head is the right way, i.e., one class with multiple related methods? Proper encapsulation and all that jazz, right? Well, Crysalis does just that. It's controller elements are regular Java classes with multiple methods. What you wind up with is something that resembles Remote Procedure Calls instead of numerous servlets as controllers. In other words, you would create the ShoppingCart object just as I described above, with all three methods. Then, when you submit a form, the action is something along the lines of "ShoppingCart.addItem.cmd". ShoppingCart is the class to execute, addItem the method and cmd is a suffix to direct the request, just like extensions in your Struts apps map requests to ActionServlet. The elements of the submitted form are treated as the parameters of the method being called, making it rather elegant. I haven't gotten into any real detail on Crysalis, but I was interested in getting other peoples' thoughts on the underlying principal (which I *THINK* I've stated properly!). It was rather interesting to me because I'd never reall considered looking at it that way, and certainly it's not the way you typically approach a Struts-based application. It was also interesting to me because I've for about four years now been preaching here at work that we should write our applications as a collection of services that are executed to form a coherent larger application, which is very much along the lines of this (so I guess I actually HAVE looked at it this way in a sense, but not exactly). Any thoughts? Frank _ Watch the online reality show Mixed Messages with a friend and enter to win a trip to NY http://www.msnmessenger-download.click-url.com/go/onm00200497ave/direct/01/ - 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]
