Quoting Octavian Rasnita <[email protected]>: > From: <[email protected]> > > --> 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)? > > Yes. If the users want to do that, it is very good to let them do it, > and > the next time when they'll come, they will see that they can't access > that > page without re-logging again, and we might also get the original URI > that > was requested, and after they log in, they could be forwarded to the > wanted > URL. > > > 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 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. > > Also, when POST is used , the URL on the url address bar of the > browser > > remains clean without the extra params. > > Why does this matter? Don't allow the user to bookmark a page because > the > URL that will be accessed doesn't look nice?
--> No. It's for usability and that's somethign that a lot of good programmers do not have yet and should start paying more attention to. I am reinventing myself by putting in points of usability. Having a url that's clean brings it closer to keeping it all simple. That's me. Do it however way you want but i have learnt enough lessons along the way to justify what I think is good for production. > > > Again, that's just my opinion and how I observed different > > organisations do things. No right or wrong - just common sense. > > That common sense is bad sense, and this is the main reason I put > that > question. > That common sense of not being flexible to situations/scenarios where requirements differ? Bravo. I'll halt from' investing more time on this thread. Cheers. _______________________________________________ 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/
