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 (nike.apache.org: local policy)
Message-ID: <4149.128.237.227.40.1186598852.squirrel@128.237.227.40>
In-Reply-To: <46B9FDC5.6060002@Newfield.org>
References: <3490.128.237.227.40.1186590907.squirrel@128.237.227.40>   
    <46B9F182.40707@Newfield.org>
    <3636.128.237.227.40.1186591761.squirrel@128.237.227.40>
    <46B9FA20.5050208@Newfield.org> <46B9FDC5.6060002@Newfield.org>
Date: Wed, 8 Aug 2007 14:47:32 -0400 (EDT)
Subject: Re: getting the value of a s:checkbox
From: "Session A Mwamufiya" <smwamufi@andrew.cmu.edu>
To: "Struts Users Mailing List" <user@struts.apache.org>
User-Agent: SquirrelMail/1.5.1 [CVS]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Importance: Normal

I appreciate the explanation on how it's all supposed to work, but given my limited experience with struts 2 and this type of framework as a whole, I am not yet proficient enough to figure out where things are being generated.  I use log4j to log a number of events in my code, but I don't even know how to display this type of request object logging you're presenting.  I need examples to run with and understand how things work; going through this was helpful to get a big view, and I don't mean to be rude, but it still doesn't help me read the checkbox value.

Is there a simple example I can follow?  That's the best way I learn.

Thanks,
Session


> Dale Newfield wrote:
>> OK--now this request goes to your server.  Hopefully eventually to 
>> struts.  Struts then steps through the interceptors and eventually
>> calls your action.  The action does it's thing and selects a result.
> 
> And this whole process can generate as many logs as you have log4j set up
> to generate.  For example, here's a piece from a log (in this case 
> generated because the request was multipart/included an upload) in my app
> showing that there were two parameters found in the request corresponding
> with the form's single checkbox:
> 
> MultiPartRequest.parse(94) | Found item user.commentsPlain 
> MultiPartRequest.parse(96) | Item is a normal form field 
> MultiPartRequest.parse(94) | Found item __checkbox_user.commentsPlain 
> MultiPartRequest.parse(96) | Item is a normal form field
> 
> Why were there two?  Because s:checkbox generated not only an <input> of 
> type checkbox, but also an <input> of type hidden.  These are both visible
> in the html of the page with the form.
> 
> How does having the __checkbox_user.commentsPlain parameter help?  Well, 
> the "checkbox" interceptor notices that it's there, and if 
> user.commentsPlain is not, it does whatever it needs to to make the rest 
> of the process do the right thing.
> 
> -Dale
> 
> --------------------------------------------------------------------- To
> unsubscribe, e-mail: user-unsubscribe@struts.apache.org For additional
> commands, e-mail: user-help@struts.apache.org
> 
> 
> 


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