On Feb 5, 11:09 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > Yes, I know, but for some simple state (like pagination) I don't need > the full session support.
Well, it's almost no work to use CherryPy sessions. So where is the problem that CP has "full session support"? You get it for free. > Also, storing some state in the URL (if it > can be passed via the URL) would allow easier handling of the "back" > button. Personally, I don't like storing state in the URL. URLs should reflect "resources" (see REST). If it's only about pagination, you might want a URL scheme like "/some/ resources/page/3". > Anyway, my proposal is for a unified state handling in which you can > choose where some variables are stored (URL, cookie or server-side > session) and simply access them via an object. The API should be the > same whether you use CherryPy or Pylons, only the implementation > should differ. But saving arbitrary, especially personal state in URLs isn't a good idea. F.ex. you don't want to hand over your session ID to a foreign user, what can easily happen when sending the URL to another user. So I believe that all "public" state, which is usually the path to a resource, should be in the URL. All "private" state should be on the server (not in a cookie that the user could manipulate). A cookie should only be used to identify the user, i.e. providing a session ID. For me, this scheme works very well. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~----------~----~----~----~------~----~------~--~---
