At 06:25 PM 8/17/2005 -0400, mike bayer wrote: >But even in this case, I think its a good idea to approach >per-user-session state information with code that is conceptually aware of >it being session-scoped information...meaning even if all my state is in >the database, id still want to access state which is session-scoped via a >"session" API. having a strong concept of "session scope" makes it easier >to model things like data caching for the right amount of time, user >interface flow, creating multi-step transactions, etc.
That really hasn't been my experience. Partly, this is because I tend to use RESTful approaches that put 99% of all statefulness in the browser. For example, if I have a multi-page form, I embed all the previous pages' data as hidden fields on the subsequent pages. The entire form is processed by a single validation routine, so it doesn't matter what the client sends or in what order, because as soon as all the data is both present and valid, the form is done. Similarly, the vast majority of UI flow is easiest to model as URL-per-state, so that the browser is in charge of the flow, and the back button works. As for caching, that's something that you tune when you have to tune it, for whatever you're tuning it for. And that's on the basis of what type of object you're persisting. Note that if you have a Cart type, let's say, then you don't really have a case where some Carts are session-specific and some are not! Session-like behavior is inherent in the object types involved, so there's no real benefit to creating a secondary classification scheme for session scope. The only session API I need in that case is: cart = get_cart(get_cart_id(request)) And since the cart is just another persistent application object, it's part of the same transaction, and I have nothing else to mess around with. You also mentioned prototyping, but a good object persistence toolkit shouldn't be tied strictly to SQL; you ought to be able to plug in a "pickle all the data to disk" mode and use it for *all* your application data, not just the session-specific objects. _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com