Quoting David Dorward <[email protected]>: > [email protected] wrote: > > --> So, tell me, would you like to allow people to bookmark > transaction > > ID numbers or attributes which are not permanent (ie will last > until a > > transaction is done)? > > > Why would a user try to bookmark such a page? It doesn't make sense. --> 1) It's an example 2) You mentioned bookmarking of urls ( GET method )
> > What harm would it do if they did anyway? At worst, they should get > an > "Unrecognized transaction" error. > --> Oh great. That makes for a pleasant site experience. Instead of giving people links that would likely fail, just don't give it to them at all. Look at the many steps involved to getting something done when the link is wrong: 1) Load the bad link that was bookmarked 2) get an error message indicating the link is no longer valid 3) Log in to site 4) Navigate (and if the navigation was done well, it would be less than 2 clicks to get to what you wanted to achieve). 4 steps. I rather encourage my users to login and work from there. Also, be prepared to do more maintenance when you rename certain paths and parameters old: http://example.com/bill-logs?uid=12893&type=electricity&payment_method=direct_debit new: https://example.com/customer_billing_logs?user_id=12893&service=electricty&payment_method=direct_debit. Perhaps you would let your users bookmark things like this, but that's you. Not me. > More usefully, a log of the transaction could be supplied. > > Fact is, guidelines are there for best practices but rules are > meant to > > be bent when we encounter different problems/scenarios. Another > factor > > is the business rules. If they business doesn't want its > subscribers > > (for what ever business acumen/reason > Such as? > > or perhaps to discount future > > maintenance of having to put in redirects when they decommission > or > > rename certain URIs) to have a bookmark for them to achieve > certain > > things (ie. look at their electricity bills), then POST would be > the > > better pick. > > > Limiting the side effects of laziness and bad practices with other > bad > practices ... well, that's an interesting argument, I'll give you > that. I don't think that's the case. What I see as bad practice may be good to you and vice versa. It depends on the business rules of the application and the intention of the syystem built. You can continue arguing but i have made my point that every situation requires thought. Bye. _______________________________________________ List: [email protected] Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[email protected]/ Dev site: http://dev.catalyst.perl.org/
