Still with buttons. How many of you have added an "Edit Document" button to a form, which has an @Command([EditDocument]) call behind it, which translates to a _doClick() call on the web? That's right, we all have!
Well, from now on, I plan to never use another button with an @Function behind it. So, how would I go about adding an edit document button?
Remember I talked about a codeless edit button before? That, I suppose, was a bit of a hack. Well, using yesterday's trick will can simplify the form a little, so it becomes:
<form action="/db.nsf/0/ComputedDocIDHere" method="get"> <input type="submit" name="EditDocument" value="Edit" /> </form>
Which simply results in a request to GET the URL
Still an odd way of doing things though, don't you think? It takes me back to a discussion we had last year about the difference between links and buttons. Back then my notion was that buttons were for actions and links were for, ahem, links. Buttons send data. Links fetch pages. Is it as simple as that though? Is "Edit" an action or a link? Technically speaking, it's simply a GET request for a URL that ends in ?EditDocument. So, it could just as well be a link.
I've found myself rethinking the approach and have decided on a new paradigm - buttons for POST, links for GET ("BPLG"). Consider the following table:
I can't help thinking it's a little too broad-ranging though. Deleting documents might technically be a GET for us as developers, but it's an action to the user. What then about Close/Cancel buttons? If they do indeed have a place on any form, should they be a button, when, in fact, they are GET requests. My head hurts.
Is there not an accepted standard that defines when to use a link and when to use a button? I've been using BaseCamp more and more recently and I know that follows the BPLG idea. They have links for create, edit, delete and cancel. Buttons are reserved merely for saving documents.