On Thu, 06 Jan 2005 04:32:56 +0000, [EMAIL PROTECTED]
> [snip]
> IMHO, I really dig JSF, but struts handle this situation better. The postback
> method that Ted talks about seems like a better JSF solution.
Indeed, the postback approach is what I used in the Shale proposal.
The basic idea is that there's a backing bean associated with each JSP
page, with the following four lifecycle methods defined:
public void init() - called when the view for this page is either
created or destroyed. Useful to allocate resources you need for both
form processing and rendering
public void preprocess() - called if this request is a postback ...
i.e. we are about to perform the Apply Request Values through Invoke
Application phases of the JSF lifecycle. Useful to allocate resources
that are only needed for event handling.
public void prerender() -- called if we are about to render this page
(i.e. the Render Response phase). Useful to allocate resources (such
as open a JDBC ResultSet that backs a table) needed only for the
duration of rendering.
public void destroy() -- called if init() was ever called. Useful for
cleaning up any resources allocated in earlier lifecycle events (such
as closing the JDBC ResultSet you might have opened in prerender()).
Interestingly, I got the idea for prerender() directly from Struts
:-). Tiles has the concept of a Controller
(org.apache.struts.tiles.Controller) whose execute() method is called
at the point in the Struts lifecycle analogous to where prerender() is
called by Shale.
Compared to the typical approaches used in Struts for the setup, this
turns out to be easier to program for a variety of reasons:
* No chaining involved, as you would see in the typical pattern
of a "process action" for the previous form chained to a
"setup action" for the next action.
* No need for a helper class to encapsulate the common setup
logic (nor for Frank's "instantiate the setup action and call execute"
approach, which is very clever but clearly points out a flaw in
the current Struts application model :-).
* Since there is no need for a form bean in Shale, all
"communication" between the various parts of the lifecycle can
happen via instance variables in a single class, with no need to
construct multiple classes, or expose those classses via public
APIs that might be called by anyone.
* ViewControllers are much easier to "get right the first time"
- you can visually inspect them to see that there is corresponding
cleanup code for every resource allocation. The framework
guarantees that all the lifecycle methods will be called at the
right time, no matter what configuration settings the developer
uses.
- you can write unit tests for ViewControllers very easily
compared to what it takes to unit test the combination
of Actions and form beans that it takes to represent the
processing for a single HTTP request in Struts.
>
> Gary
>
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
