On 4 Apr 2008, at 19:56, Ken Tilton wrote:
Andy Chambers wrote:
On Fri, Apr 4, 2008 at 6:20 PM, Ken Tilton kennytilton@optonline.net wrote: Here's the latest source. I went back to making it work with hunchentoot becuase of the sessions thing.
Bummer. Remind me: this is because aserve does that differently, not because it cannot handle them, right?
At first I thought we'd have to implement the whole idea of sessions but someone pointed out yesterday that allegroserve has "webactions". I just wanted to see it working before I ported it to webactions.
Yep. Some allegro users will want to develop portably and use hunchentoot -- I do that for production work to avoid an ACL lock-in.
But am I correct in thinking that real allegroserve has just the same interface as portable aserve (or at least a superset of features).
So what's up with that loop gotcha. Is that because of we're collecting a macro form?
No, it has to do with all closures capturing the same lexical which gets rebound until the loop ends so at the end all closures see the same value (the last).
I have looked closer at how you minimize updates using the content- rule to do your own change detection. I think I am going to have a bunch of Ajax questions soon. :)
Do you think there is any way we can implement my idea of a browser- less test harness in which we just... hmmm, ideally we setf the REQ slot with something valid.
That's a good idea. Not sure about the best way to create the request objects but one way would be to just save them for later when they come from the browser. All we're interested in at the moment is the GET parameters so that approach should be fine.
-- Andy