beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlin Rogers <carlin.rog...@gmail.com>
Subject Re: IE issue with "netui:button" rendering HTML <button> control
Date Wed, 26 Oct 2005 03:11:24 GMT
Great, sounds good. I like your suggestion for the new attribute name.

On 10/25/05, Daryl Olander <dolander@gmail.com> 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 <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