You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Adam Hardy <ah...@cyberspaceroad.com> on 2008/05/01 11:47:24 UTC
usage of Preparable interface?
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?
Regards
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: usage of Preparable interface?
Posted by Adam Hardy <ah...@cyberspaceroad.com>.
Jeromy Evans on 01/05/08 14:49, wrote:
>>>> 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.
In that case, I shall ditch PrepareInterceptor and code another, along with an
interface for the action to implements:
interface DropdownListHelper {
prepareDropdowns(String methodName);
}
I'll pull the error handling into the interceptor as well, and then all I need
in the Action.prepareDropdowns() is a couple of if switchblocks to call the
right managers:
public void prepareDropdowns(String methodName)
{
if (methodName.equals("read")
|| (methodName.equals("save") && hasErrors()))
{
getRequest().setAttribute(
WildlifeJstlConstants.DROPDOWN_SPECIES_HABITAT.toString(),
habitatManager.search(0, 0));
}
}
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: usage of Preparable interface?
Posted by Jeromy Evans <je...@blueskyminds.com.au>.
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
Re: usage of Preparable interface?
Posted by Adam Hardy <ah...@cyberspaceroad.com>.
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();
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: usage of Preparable interface?
Posted by Adam Hardy <ah...@cyberspaceroad.com>.
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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: usage of Preparable interface?
Posted by Jeromy Evans <je...@blueskyminds.com.au>.
Dave Newton wrote:
> --- Jeromy Evans <je...@blueskyminds.com.au> wrote:
>
>> 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).
>>
>
> Annotated, parameterized with an injectable load implementation?
>
> The load impl takes a context, from which it could use whatever information
> needed to create/load the object, or be stubbed during development and
> testing.
>
> Dave
>
>
Yeah. A load impl injected via the DI framework is probably too early,
but one injected via an S2 interceptor could be configured to execute
after the params interceptor. hmm...
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: usage of Preparable interface?
Posted by Dave Newton <ne...@yahoo.com>.
--- Jeromy Evans <je...@blueskyminds.com.au> wrote:
> 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).
Annotated, parameterized with an injectable load implementation?
The load impl takes a context, from which it could use whatever information
needed to create/load the object, or be stubbed during development and
testing.
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: usage of Preparable interface?
Posted by Jeromy Evans <je...@blueskyminds.com.au>.
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?
>
Hi Adam,
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.
cheers,
Jeromy Evans
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org