click-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From georgex <george.st...@yahoo.com>
Subject Re: HTTP GET should not change the data on the server?
Date Mon, 29 Mar 2010 11:50:52 GMT


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.

Mime
View raw message