...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).
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.
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 :)
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 :)
-- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com
Craig McClanahan wrote:
On Sat, 05 Mar 2005 17:56:40 -0500, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
Then again, I know *someone* is going to point out that Shale (or I guess JSF generically?) already has this notion ingrained in it.
But of course! :-)
In Shale, a ViewController bean (pretty much the equivalent of ActionForm+Action) has callback methods that the framework calls for you: - init() -- called if this page is going to either process a postback or be rendered - preprocess() - called if we are about to process a postback (form submit) for the corresponding page - prerender() - called if we are about to be rendered - destroy() - called if init() was ever called
To the original question about getting rid of the setup action, the Shale approach is to put that kind of setup stuff (populating dropdown list options, etc.) in the prerender() method, which will be called *only* if we are the page that is going to be rendered -- thus avoiding needless work if you navigated somewhere else instead.
For Struts 1.x, the "setup method" or "setup helper class" idea seems reasonable, unless you are using Tiles. In that case, use a Tiles Controller, which is almost the same thing as the Shale prerender() method -- it is called just before that tile is rendered, and is (again) the right place for this sort of setup behavior.
Craig
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
