One of the main reasons to have replayable GET requests is so you can cache the content for high access websites. If you are developing a non-public low traffic website there is no reason to cache the result and no reason not to take advantage of the simplicity of GET requests.
I understand the cache vs non-cache thing, but what about Browser plug-ins like GoogleToolbar, or other plug-ins that do (pre-)fetching or spidering? Bob Schellink wrote: > > The Click example could be implemented with GET or POST requests, nothing > in Click stops you from > using one or the other. > Users usually follow the click-examples, documentation and the best practices :). Bob Schellink wrote: > > For example, instead of having a "delete" link, the example could be > implemented by having a "Delete" button on the edit-customer.htm page. > However the user now has to > select the customer before deleting it. Alternatively the table could be > wrapped in a Form and > checkboxes used to select which row to delete, ala gmail. > This looks a little bit complicated. A simple link is indeed much simpler than a button - even when considering the styling only. Wouldn't be worth having something like SubmitLink but without the trouble with a From object? e.g. To have a Link that allows POST functionality too? I saw that Basecamp is doing this for their Delete operations - it's a link on the page, but when clicked, dynamically adds a unique small Form (to have a POST for delete - but to keep the simplicity of the link usage) - I suppose their server translates this transparently too. thanks, George. -- View this message in context: http://n2.nabble.com/HTTP-GET-should-not-change-the-data-on-the-server-tp4817128p4817484.html Sent from the click-development mailing list archive at Nabble.com.
