Craig, do you have this posted anywhere other than here on this list?
This is a great summary that I've actually been looking for, so I'm glad
I peeked into this thread. Thanks.
You should add this to your blog somewhere or it should be on JSF
Central. I'd like to bookmark it.
Craig McClanahan wrote:
For someone familiar with Struts 1.x, I would draw the following analogies:
* Where in Struts you have an Action and an ActionForm,
with JSF you tend to combine them into a single request
scope object.
* Where an ActionForm tells you to use Strings for the properties,
JSF components deal with conversion for you, so you can use
native data types.
* It's also possible to bind JSF components directly to POJO
model objects if you want ... sorta like what WebWork does too.
* Where Struts actions tend to have either a single execute()
method for the entire page, or some sort of dispatch mechanism,
you tend to bind each submit button in a JSF page to a separate
action method in some backing bean (although you can share
them if two different buttons should really do the same thing).
* Just like an Action in Struts, the action method called by JSF
should be considered an adapter to the "real" business logic
(although, just like you can do with Struts, it's possible to embed
business logic directly in the method :-).
* Shale's ViewController adds the notion of application event calbacks
to the strictly UI events that JSF supports. Of particular interest
is the prerender() callback, which is invoked just before the next
page actually renders ... the perfect place to do what you'd put in
a "setup action" in a traditionally architected Struts application.
As you become more familiar with JSF and Shale, you're likely to end up
agreeing with my judgement on the best two features of the combination for
an experienced Struts developer contemplating using JSF:
* Managed beans extend the Struts concept of magically instantiating
ActionForm beans, and makes it general purpose -- they can be
created indirectly by virtue of being bound to a component property,
or you can evaluate expressions programmatically (with the possible
side effects of creating new objects on the fly). Plus, you get basic
dependency injection for free ... if your DI needs are relatively simple,
you don't need something like Spring -- although you can certainly use
that as well if you need it.
* Shale dialogs address one of the tougher architectural areas in
Struts 1.x ... how to deal with setup actions versus process actions,
and how to organize everything. Dialogs lets you divide up your
application into states (action state = method execution, view state =
page rendering + the following form submit, subdialog state lets you
treat dialogs as black box subroutines). Every state returns a logical
outcome string, which can be used to drive transitions to other states.
And, you can have as many action states as you like between view
states. It's pretty easy to architect the overall organization of the
application in these terms, and to divide things up into logically
separate
units of work.
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
