Great, sounds good. I like your suggestion for the new attribute name.
On 10/25/05, Daryl Olander <[EMAIL PROTECTED]> wrote: > > I think that sounds right. We should revert the old behavior to override > the > value with the content, and only produce an <button> with the attribute. > One > suggestion would be to call the attribute renderAsButton. I think it fits > a > bit nicer. > > On 10/25/05, Carlin Rogers <[EMAIL PROTECTED]> wrote: > > > > Searching on the net, I haven't found much on the IE issue with button > > tags > > other than a couple entries in some IE msdn blogs... > > > > http://blogs.msdn.com/dmassy/archive/2004/06/16/157263.aspx#162226 > > http://blogs.msdn.com/ie/archive/2005/04/22/410963.aspx#413515 > > > > I'd like to propose that we go ahead and add this patch to beehive and > > give > > the users the option to create <button> elements using <netui:button> We > > can > > doc the boundary case that using the actionOverride with the HTML > <button> > > element will cause problems in IE. > > > > Currently, my patch will use the HTML <button> element if the > netui:button > > value attribute is set AND there's content between the begin and end > tags. > > I'd change my patch so that we only write out a <button> element if and > > only > > if the new netui:attribute 'renderButtonElement' is set. This way a user > > always has to explicitly state that they want the <button> element > > rendered. > > At least we'll give them the option to have this control for the > > netui:button rendering. > > > > Sound OK? Any thoughts? > > > > Kind regards, > > Carlin > > > > > > On 10/25/05, Carlin Rogers <[EMAIL PROTECTED]> wrote: > > > > > > I've found an issue with IE in how it passes the name/value pair of an > > > HTML <button> control as a request parameter from the form regardless > of > > > whether it was the button that was clicked or not. > > > > > > Yesterday I attached a patch to to JIRA issue 970 for beehive. See > > > http://issues.apache.org/jira/browse/BEEHIVE-970. In the patch the > NetUI > > > Button tag class has been modified to use a new renderer, ButtonTag, > to > > > output the HTML <button> element when either the 'renderButtonElement' > > > attribute is set or in the case when a <netui:button> has both a value > > > attribute and content between its start and end tags. > > > > > > However, after submitting the patch I've noticed one particular issue > > with > > > IE. When we set the 'action' attribute on the netui:button we write > out > > the > > > name attribute of the <button> tag using the "actionOverride:" prefix > so > > > NetUI PageFlowRequestProcessor can process an action override. For > > example, > > > > > > <button type="submit" name="actionOverride:cancel">Cancel</button> > > > > > > But this may break the form submit in NetUI. IE handles this tag > > > differently from the HTML <input> tag. IE does not include an <input> > > button > > > in the request parameters if it was not pressed. However, even when a > > > different submit button is used in a form, IE seems to pass all > > name/value > > > pairs of <button> controls in the request parameter. > > > > > > That means that a form with the above <button> tag will include a > > request > > > parameter with > > > name = "actionOverride:cancel" > > > value = "Cancel" > > > > > > Then in NetUI when we look for a process override parameter, we will > see > > > this parameter and set our request wrapper to indicate that it's > > forwarded > > > by button and use the alternate action (cancel in this case). > > > > > > This is not an issue with Mozilla, FireFox, or Opera. > > > > > > I was wondering if anyone had some good ideas about how I could > address > > > this issue or what I should do with regards to BEEHIVE-970. Thoughts? > > > > > > Thanks, > > > Carlin > > > > > > > > >
