struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eddie Bush <>
Subject Re: Remove request parameter
Date Wed, 31 Jul 2002 14:30:52 GMT
Marius Gabor wrote:

>> What I think I'm unclear about is:  At what point are you wanting to 
>> manipulate them?  ... on the page?  ... at the action itself? 
> I'm trying to manipulate them in the action, for a specific action 
> that user chooses, i.e. when user pushes some stupid button, set some 
> specific values with "default" ones.
>> Obviously, you can't really "remove" parameters.  You _could_ set 
>> them to some well-established value that says "ignore me - I'm not 
>> here" (which you should then document heavily!).  Is this maybe an 
>> option? 
> Could be, if u explain me more about that... :) 

Ok - you should know what the valid range of values is for a given 
field.  Typically there values which you can use to denote that a field 
has explicitly been set/reset to "default" - like setting a variable 
used as a loop-index to -1 - there is no language that lets you have -1 
as a loop index (I'm not sure this is 100% accurate - I think some 
languages give you the option of specifying what the range of indexes 
would be).  If you get to where you're going to use your array and the 
loop-index is -1, you know you're not ready to work yet.  This is the 
sort of thing I'm talking about.  For your parameters, it could be that 
perhaps you just set them to "IGNORE" or something similar - just to 
clue you in that you don't care about that field.  The point is that you 
want to choose something outside the "valid range" of values for that 
field, and choose to use that as an "ignore me" value - just be sure you 
document what you do so someone coming behind you can figure out what's 
going on easily.

What I typically do is have a button for each "action" I want to perform 
on a given form's data.  Then, by naming the buttons all the same name, 
and providing different "Value" attributes, you can tell what the user 
intended to do, just by which button they pushed.  Ex:

<input name='action' type='submit' value='Insert'>
<input name='action' type='submit' value='Edit'>
<input name='action' type='submit' value='Delete'>

All 3 actions will submit with a query-string that looks like (omitting 
any form values): ?action=Insert or ?action=Edit or ?action=Delete

In this sort of scenario, you _know_ right off what you're doing because 
you have enabled the user to communicate that to you through careful, 
deliberate naming/value-setting of your submit buttons.  This was the 
sort of thing I thought you might be wanting to do, but wasn't sure. 
 For instance, editing may not require all the same fields to be present 
as, let's say, inserting.

>> I would think that, based off how the user submits the form (ie. 
>> which button did they push?) you should know which values to 
>> use/ignore - but this may not be the case.
> Exactly this is the case. When a user pushes a specific button, only 
> then must be the values set. I managed to do that, but only when the 
> user pushes twice, so I guess I'll have to send a 
> javascript:document.submit() and I hate that. 

So they are pushing one button that sets form state - and another that 
submits?  Why not just attach something to the onclick= attribute of the 
button that handles setting the values - the form will submit itself 
still, will it not?

>> I still feel very uninformed :-)  I really think knowing the larger 
>> problem that this is a part of would help us understand what your 
>> implementation choices are a lot better.  That's what I was trying to 
>> get you to provide, but I suppose I didn't ask for it clearly enough.
> I admit I'm not very good in explaining things. :((( 

You're just explaining with too narrow of a scope.  You're zoomed in on 
the immediate problem.  What would help is if you could "zoom out" to 
what you're doing and what you're trying to acheive and how - and that 
would help us all understand your perdicament, I think.

Ex. (purely hypothetical)

I have this form that employees will use to submit their time.  When 
they push button "X", I need to somehow make it known that foo=baz and 
bar=bloop - but the person entering their time should never see this 
(they won't set it directly).  I've tried many JavaScript techniques to 
accomplish this - but nothing has worked well for me:

I have tried:
(list of things I have tried)

>> About all you are going to be able to do with form values are modify 
>> their values.  Note that you could, in fact, set them to nothing 
>> (effectively, null - actually an empty string, I think), and then 
>> just "know" to ignore them.  I think you should also be able to tell 
>> by how the user submits the form which parameters you need, but maybe 
>> I'm missing something.
> Well, the form can have many parameters, dynamically, that's y I can't 
> set them as properties in the form bean. 

Why not have the action that displays the page containing the form 
populate the form?  It is already in scope at that point.  This is a 
typical problem people face.  Or by dynamic do you mean you're changing 
the number of parameters in response to user interaction - ie: fields a, 
b, and c are always shown - if the user clicks button x, fields d, e, 
and f are also shown.

>> You cannot set request attributes from a (HTML) form.  You _can_ set 
>> request attributes in the action that your form submits to.  If the 
>> action your form submits to forwards to the next page, request 
>> attributes could be set and would be available to the post-submittal 
>> action (the one your submit action forwarded control to).  If you're 
>> doing redirects, your only option is to set parameters to have values 
>> transferred to this second action (unless you want to put them into 
>> the session - be sure you remove them promptly though!).  You would 
>> have explicit control over which parameters you included though.
> The whole thing worx with forwards, that's what I forgot to say. :(
> And the form, actually, by clicking that button must submit to itself. 

Yes - sounds more and more like you just need to populate the form ahead 
of time - in your action that is responsible for that form being shown.

>> Sorry, but I don't really feel I have enough information to say, with 
>> any authority, what "the" solution to your problem is.  Knowing the 
>> "larger problem" would help immensly. 
> Thank you very much, any way!!! I'll try to fix my problem 2day. If 
> not, God have mercy of what stay in front of me. >:) 



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

View raw message