[Web-SIG] and now for something completely different!
Phillip J. Eby
pje at telecommunity.com
Thu Aug 18 00:49:22 CEST 2005
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.
More information about the Web-SIG