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.