On Feb 5, 10:20 am, Thomas Wittek <[EMAIL PROTECTED]> wrote: > 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.
There's nothing wrong with CherryPy sessions. They are indeed useful for many applications and easy to use. > > 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". While REST seems nice, it gets complicated when many variables are involved (but, well, maybe my approach is wrong). In my case, I have a CRUD application where I can filter the records listing by various fields which might or might not be present in the URL. Let's assume I can map these in a RESTful way but one would like to edit a record. The REST URL (i.e. /some/resource/55/edit) passed for editing would miss the previous pagination information and, after saving the record, you get back to the beginning of the list with the filtering and page number information lost. If one doesn't need the state preserved when invoking a method, s/he would just not add the @state decorator. Of course, you can save the page number and filtering information in a session but I don't think we need the full power of sessions here, when there is no private information. > > 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. In my example above, there is no personal information saved in the URL. > 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. No, this mechanism shouldn't interfere with the session id. This is handled by CherryPy and the proposed State object should just use the CherryPy session support if it needs private variables. > 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). I agree with the above. > A cookie should only be used to identify the user, i.e. providing a > session ID. Yes, probably (as I said, I'm new to web development, my background is mainly OS/embedded software :-)). Thanks, Catalin --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
