I have an application that has a notion of a current user that is lazily established on a per-request basis. For now, I have been returning a handler that is really a lambda wrapping a real handler that lexically binds the special *current-user*:
(defun page-handler (request) (multiple-value-bind (handler foundp) (gethash (script-name request) *handlers*) (when foundp (lambda () (let ((*current-user* *current-user-local-unbound-value*)) (funcall handler))))))
But it occurred to me that there is already the *request* structure. Would it make sense to be able to have a table of arbitrary keys and values in the request structure for application use? I was thinking of an accessor like this:
request-data key &optional (request *request*) => value, foundp
Then I could write CURRENT-USER something like:
(defun current-user () (multiple-value-bind (value foundp) (request-data 'user) (if foundp value (setf (request-data 'user) (cookie-user)))))
Right now it's a bit messier than that.
What do you think? If this seems reasonable I can work out and submit a patch.
Zach
On Mon, 14 Feb 2005 08:56:40 -0500, Zach Beane xach@xach.com wrote:
I have an application that has a notion of a current user that is lazily established on a per-request basis. For now, I have been returning a handler that is really a lambda wrapping a real handler that lexically binds the special *current-user*:
(defun page-handler (request) (multiple-value-bind (handler foundp) (gethash (script-name request) *handlers*) (when foundp (lambda () (let ((*current-user* *current-user-local-unbound-value*)) (funcall handler))))))
But it occurred to me that there is already the *request* structure. Would it make sense to be able to have a table of arbitrary keys and values in the request structure for application use? I was thinking of an accessor like this:
request-data key &optional (request *request*) => value, foundp
Then I could write CURRENT-USER something like:
(defun current-user () (multiple-value-bind (value foundp) (request-data 'user) (if foundp value (setf (request-data 'user) (cookie-user)))))
Right now it's a bit messier than that.
What do you think? If this seems reasonable I can work out and submit a patch.
Hi Zach!
I'm wondering if what you really want isn't just per-session info. If in your CURRENT-USER function you replace REQUEST-DATA with SESSION-VALUE isn't that the info you'd like to have? You'd get the sessions for free.
I'm a bit hesitant to add customized data to the request object because my gut feeling is that by definition it doesn't belong there. Unless you convince me that I'm wrong, of course... :)
Cheers, Edi.
On Mon, Feb 14, 2005 at 03:16:42PM +0100, Edi Weitz wrote:
Hi Zach!
I'm wondering if what you really want isn't just per-session info. If in your CURRENT-USER function you replace REQUEST-DATA with SESSION-VALUE isn't that the info you'd like to have? You'd get the sessions for free.
I'll take a look at sessions for this purpose.
Zach
On 2005-02-14 15:16:42, Edi Weitz wrote:
On Mon, 14 Feb 2005 08:56:40 -0500, Zach Beane xach@xach.com wrote:
But it occurred to me that there is already the *request* structure. Would it make sense to be able to have a table of arbitrary keys and values in the request structure for application use? I was thinking of an accessor like this:
I'm wondering if what you really want isn't just per-session info. If in your CURRENT-USER function you replace REQUEST-DATA with SESSION-VALUE isn't that the info you'd like to have? You'd get the sessions for free.
I'm sitting at a similar problem. One function is called two times and has to read some data. It would be nice if I could cache this data for one request so it only has to be read one time.
Can't use a closure because AFAIK one request doesn't always start a new process and the data could be too old in further requests.
I don't want to start a session at this time.
Or maby just two variables in a closure. One holds the data and the other *REQUEST*. Then I check against *REQUEST* with EQ and I know if the stored data is from an old request or the current one. Am I right?
Regards, Stefan
On Sun, 13 Mar 2005 19:31:16 +0100, Stefan Scholl stesch@no-spoon.de wrote:
I don't want to start a session at this time.
Why not?
Or maby just two variables in a closure. One holds the data and the other *REQUEST*. Then I check against *REQUEST* with EQ and I know if the stored data is from an old request or the current one. Am I right?
Sounds reasonable.
Cheers, Edi.
On Mon, 14 Feb 2005 08:56:40 -0500, Zach Beane xach@xach.com wrote:
Would it make sense to be able to have a table of arbitrary keys and values in the request structure for application use?
Hi Zach!
It obviously took me a while to figure out that this was a good idea... :)
Sorry for that. Here's the ChangeLog vor the new version:
Version 0.7.0 2005-09-17 Added the ability to store arbitrary data within REQUEST objects (suggested by Zach Beane) Fixed handling of *HTTP-ERROR-HANDLER* Note: *TBNL-VERSION* was wrong in 0.6.0 and 0.6.1
Download:
http://weitz.de/files/tbnl.tar.gz
Cheers, Edi.
-
Edi Weitz -
Stefan Scholl -
Zach Beane