Fog Creek Software
Discussion Board




ASP.NET LinkButton and leaky abstractions

Here's a problem which burned out a few brain cells of mine. I share my workaround in case any of you should face the same problem.

My problem: I use the IE5+ html edit capacity and a LinkButton to submit the form. But before I submit the form, I have to use client script to copy the content from the editor component to a hidden form field.

The obvious solution is to call the script from the form's OnSubmit event, but guess what? That doesn't work on LinkButtons. This looks like an IE issue. The LinkButton is rendered to nothing more than an A-tag with href="javascript:__DoPostback('buttonName', '')".

It appears that IE fail to trigger the OnSubmit event in this case. That's a leaky abstraction! We are lulled into thinking that the various buttons works the same.

I am stuck with the LinkButton because I already have multiple webforms using it

The workaround: It looks like ASP.NET render the href after everything else on the page has been executed. But it also checks if the href attribute is already set, and will leave it as it is if so.

So create a client function like this:

function submitForm(eventTarget) {
  // do form submit stuff here
  document.Form1.body.value = 
          document.Form1.dhtmlBody.DocumentHtml;
 
  // call the original function so the server side
  // click event is raised
  __doPostBack(eventTarget,'')
}

Then set the LinkButton's href in ASP.NET:

save.Attributes["href"] = "javascript:submitForm('save');";

Thomas Eyde
Sunday, July 13, 2003

I think LinkButtons in this scenario are possibly a usability no-no anyway. On the whole, links should navigate the user somewhere (but not modify data). Buttons should carry out actions - ie, save, delete, etc.

Duncan Smart
Sunday, July 13, 2003

The ASP.NET linkButton is the *classic* leaky abstraction. It tries to make an <a> tag behave like a submit button even though in HTML that only works about 10% of the time.

There's a very good reason to use LinkButtons or their equivalent, though: on fairly complicated forms, sometimes you want to sprinkle links throughout that actually navigate to another page, but when the user clicks on one of them, you want to remember all the things they've typed so far.

For example, on a checkout form:

Name: [          ]
Address: [          ]
Credit card (choose one) [ My Visa ending in 3982 ]
      <a> register another credit card </a>

Joel Spolsky
Sunday, July 13, 2003

DHTML + CGI is *the* classic leaky abstraction for distributed applications, period.

But, as they say, worse is better.

Alyosha`
Sunday, July 13, 2003

Another approach is to use css to make a button look and behave like a link.

asdf
Sunday, July 13, 2003

I like link buttons, and no complaints from the users.
Duncan - I think you're overthinking the issue - do users really think that way? Or to them is it simply
"Link = button = do something" ?

The *problem* (IMHO) with link buttons is pretty simple - you can't customize a browse button. It *must* look like a plain ol' HTML button. Given that, if you want consistency throughout your application, then you're stuck with buttons for actions. (FWIW, I think that's a *horrible* "fix" for the perceived "security issue" with browse buttons)

Philo

Philo
Sunday, July 13, 2003

Philo,

You can customize html buttons anyway you want - color, background, font, border, size, add images, etc.  Pretty standard CSS and you can use thoughout you website.

tekumse
Tuesday, July 15, 2003

The file uploading input element in HTML is pretty unique in that the common implementation yields TWO on-screen elements, not one: the edit control, and the browse button that's glued to its right.

I'm not sure how you would style that.

Brad Wilson (dotnetguy.techieswithcats.com)
Tuesday, July 15, 2003

*  Recent Topics

*  Fog Creek Home