Mailing-List: contact user-help@struts.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Struts Users Mailing List" <user@struts.apache.org>
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <4819CA59.5060902@blueskyminds.com.au>
Date: Thu, 01 May 2008 23:49:13 +1000
From: Jeromy Evans <jeromy.evans@blueskyminds.com.au>
Organization: Blue Sky Minds Pty Ltd
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: Struts Users Mailing List <user@struts.apache.org>
Subject: Re: usage of Preparable interface?
References: <481991AC.40300@cyberspaceroad.com>
 <4819AE02.4060601@blueskyminds.com.au> <4819BCED.2030909@cyberspaceroad.com>
 <4819C4D5.8070505@cyberspaceroad.com>
In-Reply-To: <4819C4D5.8070505@cyberspaceroad.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Adam Hardy wrote:
> Adam Hardy on 01/05/08 13:51, wrote:
>> 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?
>
> Is there an easier way?
>
> String method = 
> ServletActionContext.getActionContext(request).getActionInvocation().getProxy().getMethod(); 
>
>
That's the right place.  It's available as an argument in the 
intercetpor.  PrepareInterceptor is doing exactly that when it looks for 
the presence of the Preparable interface on your action, and then for a 
methods matching the prepare<methodName>() signature.


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org