From mathrick at gmail.com Wed Jul 4 14:01:10 2007 From: mathrick at gmail.com (Maciej Katafiasz) Date: Wed, 4 Jul 2007 16:01:10 +0200 Subject: [kpax-devel] class and id for generated web form fields Message-ID: <50b7e5180707040701s7b7d1fbdqbc7ced65a8f67d41@mail.gmail.com> Hello, I've been playing with KPAX, and so far it works pretty nicely (save for a couple of SLIME and misc issues I will be detailing in another email). However, I've now arrived to the point where I'd like to use DEFWEBFORM'd forms. It all looks very nice, but it seems that default renderers have no ability to specify arbitrary attributes, in particular that means no way to specify `class' and `id' for elements, and that makes attaching CSS hard. So, is there an easy way to attach those attributes to fields I'm missing? I am aware I can elect to use my own renderers, but I really don't want to recreate all that logic. Looking at the definitions of generate-text-area and friends, there's no way to inject any more parameters than they're already taking. In case it really needs hacking on KPAX source, is there any obvious approach? And what sources/version should I use as the basis? My installation of KPAX reports "$Id: nkpax.asd,v 1.26 2004/11/10 15:20:55 sven Exp $", but that's an obvious lie, in any case it was asdf-installed 2 days ago. Cheers, Maciej From mathrick at gmail.com Wed Jul 4 14:25:17 2007 From: mathrick at gmail.com (Maciej Katafiasz) Date: Wed, 4 Jul 2007 16:25:17 +0200 Subject: [kpax-devel] Miscellanous issues Message-ID: <50b7e5180707040725x213deb20w58724dfe36e3d7f1@mail.gmail.com> Hello, in this mail I detail a couple of issues I had with KPAX during my use of it: 1) Problems with SLIME, at least under SBCL. You can't run (run-kpax :server-class 's-http-server) from SLIME's REPL buffer, because it'll fail to process the request. I wasn't able to track the exact source of the problem, but it seems it's an issue with SLIME hijacking some streams. If you run it directly in *inferior-lisp* buffer (just that one call is sufficient, everything else can be done in REPL), it runs fine. It's not a huge problem once you discover that, but it ought to be mentioned somewhere, as trying to figure out why it doesn't work is really frustrating. 2) Can't stop S-HTTP-SERVER CHAMSTER> (stop-kpax :server-class 's-http-server) ==> The value (("s-http-server" # #)) is not of type SB-THREAD:THREAD. [Condition of type TYPE-ERROR] 3) HTTP response codes handling is limited and rather weird. Why are there separate and identical handlers for s-http-server and mod_lisp? Also, it's impossible to use arbitrary response codes, and I happened to need 302 which was not included. I fixed that by defining my own copy of kpax::response-status-to-s-http-server-status, but in general it should just allow an arbitrary (code . message) response besides the predefined keyword ones Cheers, Maciej From mark at cornwell.net Thu Jul 12 07:24:39 2007 From: mark at cornwell.net (Mark Cornwell) Date: Thu, 12 Jul 2007 03:24:39 -0400 Subject: [kpax-devel] Mods for porti to CLISP Message-ID: <7B6A7D56-348B-4B0F-85AB-1F728A407617@cornwell.net> I've been spending the evening getting KPAX running under CLISP. Got the s-http-server part running the basic Hello Wrorld demo on static pages. Unsure what the process was for sending in updatss or mods, I decided to post to this list, just so the effort might do someone some good. A minor change to s-utils.lisp was needed to work around a type checking problem. CLISP apparently checks (usigned 8) to char conversion a bit more strictly than other dialects. Cheers! --Mark Changed s-utils.lisp Betty:/Volumes/iDisk/Ramses/lisp/s-utils/src mark$ diff utils.lisp.orig utils.lisp 50c50 < (write-sequence buffer out :end size) --- > (my-write-sequence buffer out :end size) 52c52 < (write-sequence buffer out) --- > (my-write-sequence buffer out) 55a56,63 > ;; write-sequence may signal an error if we write (unsigned 8) to a character stream > ;; this actually happens with CLISP. SBCL and LispWorks are probably ok with it. > ;; ref http://www.lispworks.com/documentation/HyperSpec/Body/ f_wr_seq.htm > (defun my-write-sequence (buffer stream &key (start 0) (end nil)) > (let ((len (if (null end) (length buffer) (min end (length buffer))))) > (loop for i from start upto (- len 1) do > (write-char (code-char (elt buffer i)) stream)))) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From scaekenberghe at common-lisp.net Fri Jul 13 09:52:31 2007 From: scaekenberghe at common-lisp.net (Sven Van Caekenberghe) Date: Fri, 13 Jul 2007 11:52:31 +0200 Subject: [SPAM] [kpax-devel] class and id for generated web form fields In-Reply-To: <50b7e5180707040701s7b7d1fbdqbc7ced65a8f67d41@mail.gmail.com> References: <50b7e5180707040701s7b7d1fbdqbc7ced65a8f67d41@mail.gmail.com> Message-ID: Maciej, On 04 Jul 2007, at 16:01, Maciej Katafiasz wrote: > Hello, > > I've been playing with KPAX, and so far it works pretty nicely (save > for a couple of SLIME and misc issues I will be detailing in another > email). However, I've now arrived to the point where I'd like to use > DEFWEBFORM'd forms. It all looks very nice, but it seems that default > renderers have no ability to specify arbitrary attributes, in > particular that means no way to specify `class' and `id' for elements, > and that makes attaching CSS hard. > > So, is there an easy way to attach those attributes to fields I'm > missing? I am aware I can elect to use my own renderers, but I really > don't want to recreate all that logic. Looking at the definitions of > generate-text-area and friends, there's no way to inject any more > parameters than they're already taking. In case it really needs > hacking on KPAX source, is there any obvious approach? And what > sources/version should I use as the basis? My installation of KPAX > reports "$Id: nkpax.asd,v 1.26 2004/11/10 15:20:55 sven Exp $", but > that's an obvious lie, in any case it was asdf-installed 2 days ago. > > Cheers, > Maciej > _______________________________________________ > KPAX-devel mailing list > KPAX-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/kpax-devel The way KPAX interacts with CSS is a bit old school (let's say pre- AJAX hype). Currently only hooking CSS on the existing classes and ids is possible, although there is a form-id option to defwebform. But you are right: some extra per elemment specs would be welcome. The whole defwebform concept is layered on top of the core KPAX functionality, so changing/hacking it is certainly allowed. Regards, Sven From scaekenberghe at common-lisp.net Fri Jul 13 09:55:08 2007 From: scaekenberghe at common-lisp.net (Sven Van Caekenberghe) Date: Fri, 13 Jul 2007 11:55:08 +0200 Subject: [SPAM] [kpax-devel] Mods for porti to CLISP In-Reply-To: <7B6A7D56-348B-4B0F-85AB-1F728A407617@cornwell.net> References: <7B6A7D56-348B-4B0F-85AB-1F728A407617@cornwell.net> Message-ID: Mark, On 12 Jul 2007, at 09:24, Mark Cornwell wrote: > I've been spending the evening getting KPAX running under CLISP. > > Got the s-http-server part running the basic Hello Wrorld demo on > static pages. > > Unsure what the process was for sending in updatss or mods, I > decided to post > to this list, just so the effort might do someone some good. > > A minor change to s-utils.lisp was needed to work around a type > checking problem. > CLISP apparently checks (usigned 8) to char conversion a bit more > strictly than > other dialects. > > Cheers! > --Mark > > Changed s-utils.lisp > > Betty:/Volumes/iDisk/Ramses/lisp/s-utils/src mark$ diff > utils.lisp.orig utils.lisp > 50c50 > < (write-sequence buffer out :end size) > --- > > (my-write-sequence buffer out :end size) > 52c52 > < (write-sequence buffer out) > --- > > (my-write-sequence buffer out) > 55a56,63 > > ;; write-sequence may signal an error if we write (unsigned 8) to > a character stream > > ;; this actually happens with CLISP. SBCL and LispWorks are > probably ok with it. > > ;; ref http://www.lispworks.com/documentation/HyperSpec/Body/ > f_wr_seq.htm > > (defun my-write-sequence (buffer stream &key (start 0) (end nil)) > > (let ((len (if (null end) (length buffer) (min end (length > buffer))))) > > (loop for i from start upto (- len 1) do > > (write-char (code-char (elt buffer i)) stream)))) > > > > > _______________________________________________ > KPAX-devel mailing list > KPAX-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/kpax-devel Some time ago I applied some hacks to make kpax (and s-http-server and s-sysdeps) work in single-threaded mode for CLISP. Although it did more or less work, I was unhappy with the bivalent stream issues (binary/character stream uncertainty). Thanks for playing with this - when I have more time (august) I will have another look at this. Regards, Sven From scaekenberghe at common-lisp.net Fri Jul 13 09:58:47 2007 From: scaekenberghe at common-lisp.net (Sven Van Caekenberghe) Date: Fri, 13 Jul 2007 11:58:47 +0200 Subject: [SPAM] [kpax-devel] Miscellanous issues In-Reply-To: <50b7e5180707040725x213deb20w58724dfe36e3d7f1@mail.gmail.com> References: <50b7e5180707040725x213deb20w58724dfe36e3d7f1@mail.gmail.com> Message-ID: Maciej, On 04 Jul 2007, at 16:25, Maciej Katafiasz wrote: > in this mail I detail a couple of issues I had with KPAX during my > use of it: > > 1) Problems with SLIME, at least under SBCL. You can't run (run-kpax > :server-class 's-http-server) from SLIME's REPL buffer, because it'll > fail to process the request. I wasn't able to track the exact source > of the problem, but it seems it's an issue with SLIME hijacking some > streams. If you run it directly in *inferior-lisp* buffer (just that > one call is sufficient, everything else can be done in REPL), it runs > fine. It's not a huge problem once you discover that, but it ought to > be mentioned somewhere, as trying to figure out why it doesn't work is > really frustrating. > > 2) Can't stop S-HTTP-SERVER > CHAMSTER> (stop-kpax :server-class 's-http-server) > > ==> > > The value > (("s-http-server" > # > #)) > is not of type > SB-THREAD:THREAD. > [Condition of type TYPE-ERROR] My primary development environment is LispWorks for Mac OS X, my primary deployment environment is LispWorks for Linux TTY. I do not work very often with SBCL or Emacs+SLIME. I wasn't aware of these issues, I might have a look at them later on. > 3) HTTP response codes handling is limited and rather weird. Why are > there separate and identical handlers for s-http-server and mod_lisp? > Also, it's impossible to use arbitrary response codes, and I happened > to need 302 which was not included. I fixed that by defining my own > copy of kpax::response-status-to-s-http-server-status, but in general > it should just allow an arbitrary (code . message) response besides > the predefined keyword ones You are right: in retrospect that mechanism looks a bit out dated: I'll consider adding a arbitrary response mechanism like you suggested. > Cheers, > Maciej > _______________________________________________ > KPAX-devel mailing list > KPAX-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/kpax-devel Thanks for the feedback, Regards, Sven -- Sven Van Caekenberghe - http://homepage.mac.com/svc Beta Nine - software engineering - http://www.beta9.be "Lisp isn't a language, it's a building material." - Alan Kay