beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daryl Olander <dolan...@gmail.com>
Subject Re: IE issue with "netui:button" rendering HTML <button> control
Date Wed, 26 Oct 2005 02:21:56 GMT
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 <carlin.rogers@gmail.com> 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 <carlin.rogers@gmail.com> 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
> >
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message