struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig McClanahan <>
Subject Re: Eliminate Setup Actions
Date Sun, 06 Mar 2005 00:41:33 GMT
On Sat, 05 Mar 2005 18:42:35 -0500, Frank W. Zammetti
<> wrote:
> ...And I did in fact mean you when I wrote "someone" :)
> I generally like the overall idea behind ViewController beans as you
> describe.  If there was one "problem" that I see it is that the
> prerender() method is specific to the page the bean is associated with.
>   This can be viewed as "good" or "bad"...
> The "good" view is a nice encapsulation of the page-related
> functionality.  Also, as you point out, it may serve to eliminate some
> unnecassery work in some cases, which is nice.
> The "bad" view is that if you have essentially the same dropdown on
> three different pages, as I understand it, you either (a) have to
> duplicate that setup code in three different beans, (b) call some common
> class from all three prerender() methods, or (c) call prerender() of one
> of the beans from prerender() of the other two (assuming that's even
> allowed).

If the domain data is truly shared across multiple pages, you
shouldn't be setting it up in the prerender() method -- or in a setup
action in Struts 1.x -- at all.  Option (d) is best in that case: 
bind your dropdown list component directly to a list of options that
lives in session scope (if it is unique per user) or in application
scope (if it is common to all users).

The example app for Shale illustrates precisely this approach for
populating dropdowns, if you want to see how it looks in code.

> Of those options, (b) is the only one that doesn't make me immediately
> unhappy.  But, even that one feels a bit more heavyweight and hacky than
> it could.

That one is still too much work.
> But, don't take that as a criticism of Shale in any way.  I'm just
> thinking along the lines of how I might like to implement it in 1.x,
> trying to see what ideas from Shale I might like to steal and which I
> might like to go a different way on :)

Option (d) works great in Struts 1.x too :-).

> Your comment about the Tiles Controller is very interesting... If I was
> to do this, I would think the proper way would be that it should work
> regardless of whether Tiles is used or not, and in the same way in
> either case.  Clearly if I have to use a controller when using Tiles but
> something else when I'm not, that's not an optimal answer, to me anyway.
>   I could also make the same argument about the controller as I made
> about the Shale prerender() method too, but its two different issues I
> think :)

Use a Tiles controller (Struts 1.x) or Shale prerender() method
(Shale) *only* for the stuff that is unique to this particular page. 
For example, consider a classic master-detail scenario like "show me
all the orders for the selected customer."  Where do you put the logic
that actually performs the appropriate database select (or whatever,
based on the persistence technology you're using)?  That's right ...
this is where it goes, because it is unique setup for *this* page or

By the way, Shale's ViewController support recently got extended to
subviews (i.e. things which are included by <jsp:include> or the
equivalent, which is what Tiles does under the covers).  Therefore,
you'll be able to use exactly the same techniques on either a single
"tile" or the entire page, without having to learn two different APIs.

Anything you can do once and cache should be done once and cached :-).
 No need to execute *any* logic if you can bind to them directly.

    <!-- Assume form bean has a "state" property on it -->
    <html:select ... property="state">
        <!-- Assume appScopeBean is a Java class in application scope -->
        <!-- with a getStateNames() method that returns an array of State -->
        <!-- names, and a getStateAbbrs() method that returns an array of -->
        <!-- State abbreviations -->
       <html:options ... name="appScopeBean" property="stateNames"
           labelName="appScopeBean" labelProperty="stateAbbrs"/>

    <!-- Assume current customer bean has a "state" property on it -->
    <h:selectOneMenu ... value="#{customer.state}" ...>
        <!-- Assume appScopeBean is a Java class in application scope -->
        <!-- with a getStatesList() property that returns an array of
SelectItem -->
        <!-- instances, whose "label" and "value" properties are the state -->
        <!-- name and abbreviation, respectively -->
        <f:selectItems value="#{appScopeBean.statesList}"/>


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message