click-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From georgex <>
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

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.

View this message in context:
Sent from the click-development mailing list archive at

View raw message