Thanks Musachy. I've been looking at the src for
ParameterRemoverInterceptor and it looks like I can easily modify it to
meet my needs. I just wanted to insure that I was approaching the
problem in a "S2 way" since it would seem to be a common problem.
--john
Musachy Barroso wrote:
By the way, the Parameters interceptor uses the "wrap" parameters map,
so removing them from there would work.
musachy
On Wed, Jan 7, 2009 at 11:52 AM, Musachy Barroso <musa...@gmail.com> wrote:
Parameters interceptor can ignore parameters based on the name, but
not on value. You could extend the parameters interceptor and check
for values before binding, or what Dave suggested. A tip there, if you
go with Dave's suggestion, have into account that the parameters in
the context is a new map, built from the parameters in the request, so
removing them from that map won't remove them from the request.
musachy
On Wed, Jan 7, 2009 at 11:35 AM, John Cartwright
<john.c.cartwri...@noaa.gov> wrote:
Thanks for your prompt response Dave. So an custom interceptor before
Params could modify the servlet request and Params interceptor would never
seem them? Is there not a way to configure the existing Params interceptor
to ignore any request parameters w/ a value of empty string?
The problem that I have is that Params is instantiating empty embedded
objects. For example, I have a Name class for my model. Name contains a
Contact class. So when the request contains blank strings for all the
Contact fields (e.g. contact.name, contact.phone, etc.), Params interceptor
creates a new Contact instance w/ all empty fields and assigns that
reference to the model.
I feel like I'm going against the grain of S2 somehow.
Thanks again for your advice!
--john
Dave Newton wrote:
John Cartwright wrote:
Can someone provide a recommendation for removing empty request
parameters before the Params interceptor sees them? Can Params interceptor
simply be configured to ignore request parameters with no value?
I'd probably just create a quick interceptor to do that, if that's
actually the functionality you require.
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org
