struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Hardy <>
Subject Re: usage of Preparable interface?
Date Thu, 01 May 2008 12:51:57 GMT
Jeromy Evans on 01/05/08 12:48, wrote:
> Adam Hardy wrote:
>> I have been casting around for a while for the most elegant and 
>> quick-to-code mechanism for putting populating lists for select controls.
>> I wanted to run this one idea past the struts users to get any 
>> feedback on something I may have missed or need to know.
>> One requirement I set myself is that I want to avoid coding for the 
>> dropdown lists in every action method.
>> The Preparable action interface seems ideally suited for this situation.
>> I can write a prepare() method and use its MethodFilterInterceptor to 
>> turn it on only when doing reads. My creates, saves and deletes don't 
>> need lists because they do Post-Redirect-Gets back to the appropriate 
>> read.
>> The reason I ask is that the struts docs make clear that Preparable is 
>> intended for use in param and model management. Is anyone else using 
>> Preparable to do other stuff like this?
> I've been toying with the idea of creating a custom interceptor to do 
> this.  It would be effectively the same as you describe, except that it 
> would inspect the action for the presence of some interface, annotation, 
> or method, and examine the request for some characteristic (eg. get 
> method) and if matched it creates/looks up the model and injects it into 
> an appropriate scope (eg. into the action, into the action context, 
> request scope, or onto the valuestack).
> That way you could remove all the boilerplate from your actions.
> eg, If it placed the model into the actioncontext you could potentially use
> <s:select name="state" list="#states"/>
> without your action providing the list or getter at all (except 
> something must instruct the interceptor to load it).
> Just some ideas.

I thought about putting it all in the interceptor but I think it could get 
unwieldy once the application grows.

Plus, there may be logic in the list call to restrict the list in some way. I 
guess you could do that in an interceptor by casting your action to what you 
know it is and then calling the required methods on your model.

My boiler plate code isn't so bad, and in fact the only boiler plate stuff is 
the catch block.

By the way, how would you figure out what the method being called is? Hard-code 
a call to fetch anything prefixed "method:" from the HTTP params? Or is there 
something on the Struts API already?

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

View raw message