[Seaside] Re: Application/Session Objects
julian at beta4.com
Wed Feb 22 21:37:43 UTC 2006
Well, it is limiting but keep in mind that the user may have multiple
browser windows open in the same session so if you're going to keep your
requests open longer than a request you need some way of making sure
you're using the same one (particularly if you are using db transactions).
You could probably do it by hooking into something like #isolate: or
writing your own similar method so that you'd have a connection within
the scope of that call. I think it's implemented as a decoration these
days, so the decoration could hold onto the connection.
But I'm getting a bit out of my league here in the sense that I haven't
acutally tried using seaside with a relational database *and* with db
In our particular case, with the way omnibase works as well, it was
easier to have the connections handled automatically for us and provided
in the dynamic scope of every request. We actually ended up
implementing essentially our own transactional editing mechanism for the
model which allowed us to have editing tasks that spanned multiple
requests but only wrote to the db in the final request. It all kind of
grew into something that worked but I don't think we'd claim it was
ideal in hindsight. :)
Yanni Chiu wrote:
> It seems to me that using the http req/resp as a transaction
> boundary is an unnecessary and potentially limiting constraint.
> But as a first cut, just go for it.
More information about the Seaside