struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eddie Bush <ekb...@swbell.net>
Subject Re: Remove request parameter
Date Wed, 31 Jul 2002 16:01:28 GMT
Marius Gabor wrote:
<snip>

>> 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.
>
> So, we have some things in common: the input fields, that by me are 
> hidden and the query thing, that by me doesn't exist anymore, don't 
> ask me y, I think is from the submit method, because I already made a 
> solution for query string like that (with "?" and "&"). I wrote u 
> about that already.
>
>> 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? 
>
> Well, onClikc my project manager doesn't want to. I don't want 
> neither, I don'T like very much JScript, u know... 

understood :-)

> The thing is I have a form, with many links (Javascript one, that 
> submit the form also, with document.myform.submit()) and buttons, 
> Struts buttons, i.e. for every button there is an action specified in 
> action class. When I click "Button1", I want the page in an arbitrary 
> state, but the links make also sumbit() and the parameters are changed.
> I managed to overcome that only through session, i.e. I set an 
> attribute in the session and then this is read when the other 
> "actions" that modify the parameters( i.e. my hidden fields) and they 
> acting accordingly, i.e. setting the fields on "default" values. 

I see - so you're making round-trips to the server to change the values 
in your forms hidden fields (you're doing it in your action).  I think I 
understand that now - I thought you were using JavaScript.  I don't know 
why you're maintaining information in the session, but if it works 
that's what is important.  I would honestly think you could just allow 
your the values of your buttons guide you to what you need to be doing - 
as I mentioned above.  Obviously I don't fully understand your problem 
still, but it sounds like you've about got it solved anyway ;-)

>> 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. 
>
> I've tried one more time to do that. :o) 

That is what I was looking for!

>> 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.
>
> U are a little bit confusing: form that populates form (?!) 

No no no - the _action_ populates the form :-)  If you have an action 
that is responsible for forwarding to the page containing the form, the 
form should be in request scope when the action is invoked.  You could 
put any values into the form at that time.

>> 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.
>
> Well, close enough. I need only the hidden fields with another values, 
> but the values are modified from these Javascript things. 

Ok, I'm confused.  I thought you said above that your buttons submitted 
the form, and that, depending on which button was pressed, you set your 
hidden fields accordingly and redisplayed the form.

> I've thought about it and loox like there are 2 possibilities:
> 1) with onClick thing, not very acceptable
> 2) with attributes, but if possible with no Session attribute 

Well, as long as you don't get too carried away with what you're putting 
in the session, it shouldn't be a problem.  If you just have a boolean 
out there, for instance, or even an int - to help you track what's going 
on - that shouldn't give much overhead (unless you have limited 
resources and many simultaneous users).  It can be difficult to decide 
when to remove it though.  If the user actually finishes whatever 
"process" they are going through, you can know to remove it at the end - 
however, if they do not finish the process you have no idea where to 
remove it.

> I've tried with request attributes, but there are vanished after the 
> JavaScript document.bla-bla.submit(). 

Yes.  When the user clicks on Submit they initiate another request. 
 Requests only live for one "round-trip" (ie user request document 
[start request], server locates document and returns to user, document 
is displayed on user terminal [end request]).  They aren't very useful 
for maintaining state - they are as stateless as HTTP itself.  The 
session (or some sort of serialization technique) is the only way around 
this.

> So, I hope the solution is good so far, I must only figure it out when 
> should I delete the session attribute(s). 

It would be acceptable to remove session attribute(s) when you know they 
will no longer be needed (ie at the end of your "process" as I said 
above).  There's no other "good place" to do it.  Unfortunately, if the 
user breaks out of the work-flow, that data will remain in the session 
until it times out.

Sorry, but I really can't help you more, I don't think.  I wish you luck 
though!

Eddie



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


Mime
View raw message