You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Craig McClanahan <cr...@apache.org> on 2004/07/09 02:35:08 UTC
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 <form>, 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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Theoretical debate
Posted by Rick Reumann <st...@reumann.net>.
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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Theoretical debate
Posted by Michael McGrady <mi...@michaelmcgrady.com>.
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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
RE: Theoretical debate
Posted by Matthias Wessendorf <ma...@matthias-wessendorf.de>.
> 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.
<h:inputText ... value="#bean.date">
<f:convertDateTime pattern="MM/dd/yyyy"/>
</h:inputText>
enter in textfield: 12/06/2004
and java.util.Date got created...
on the other side the output, i case of
presenting a date
<h:outputText ... value="#bean.date">
<f:convertDateTime pattern="MM/dd/yyyy"/>
</h:ouputText>
so you got your date like '12/06/2004' instead of
java.util.Date@3242343 ;-)
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
<h:inputText ... value="#{bean.tele}">
<x:teleConverter delim="."/>
</h:inputText>
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:
>
> <h:inputText ... value="#{mybean.count}"/>
>
> 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 <cr...@apache.org> 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 <form>, 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: user-unsubscribe@struts.apache.org
> >>For additional commands, e-mail: user-help@struts.apache.org
> >>
> >>
> >>
> >>
> >
> >
> >
> >__________________________________
> >Do you Yahoo!?
> >Yahoo! Mail - 50x more storage than other providers!
> >http://promotions.yahoo.com/new_mail
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> >For additional commands, e-mail: user-help@struts.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Theoretical debate
Posted by Craig McClanahan <cr...@apache.org>.
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:
<h:inputText ... value="#{mybean.count}"/>
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 <cr...@apache.org> 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 <form>, 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: user-unsubscribe@struts.apache.org
>>For additional commands, e-mail: user-help@struts.apache.org
>>
>>
>>
>>
>
>
>
>__________________________________
>Do you Yahoo!?
>Yahoo! Mail - 50x more storage than other providers!
>http://promotions.yahoo.com/new_mail
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Theoretical debate
Posted by Mike Duffy <md...@yahoo.com>.
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 <cr...@apache.org> 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 <form>, 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: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org