strange behaviour
in [Lisp]
|
From: Captain Obvious on 23 Jun 2010 05:44 KT> On aserve we have publish-file and publish-directory* by which a logical KT> path used in an href gets translated to a physical directory the server KT> knows about, and I recall Hunch does the same albeit with diff syntax. It works same way in Hunchentoot. They are called create-static-file-dispatcher-and-handler and create-folder-dispatcher-and-handler But then one needs to put them into *dispatch-table* manually.
From: vanekl on 23 Jun 2010 06:45 Captain Obvious wrote: >> I put img instead of image and put the image in lispworks working dir >> and tried relative pathname to the image but no success. >> I guess hunchentoot has it's own current working dir >> so I should put my picture in that directory. >> How do I find out or set that directory ? > > You do not have a good understanding how web servers work. They do not > operate "in a working directory", they serve requests. If I may, I can expand on this a bit. The closest thing to a "working directory" is what many HTTP servers refer to as www-root. Many times this maps to a physical directory but hunchentoot has no such limitation. This is an artificial constraint. This constraint makes administrating file and directory privileges more convenient since all web files are located together, so to speak, but this constraint has little value other than that and hunchentoot doesn't limit developers this way. If anybody needs to know what the lisp current working directory is, just do, (truename ".") but I don't recommend working with relative directories. When doing web work, it's safer to fully specify file paths when working with paths internally within the application server. It's much safer to limit use of relative paths to "outside" the application server, when specifying URLs, and never expect the current working directory to be set to a specific value w/o first checking it (in which case you might as well fully specify the path and not use relative paths). Web work is complicated by having to be more concerned about security than a typical desktop app. Contrary to popular belief, web development is more difficult to do right. AT&T is finding that out right now.
From: Haris Bogdanovi� on 23 Jun 2010 11:29 I made folder dispatcher and handler like this: ------------------------------------------------------------------------------------------------- (push (hunchentoot:create-folder-dispatcher-and-handler "pics/" "c:mypics/") hunchentoot:*dispatch-table*) ------------------------------------------------------------------------------------------------- and have a page code like this: --------------------------------------------------------------------------------------- (defun start-page () (cl-who:with-html-output-to-string (*standard-output* nil :indent t) (:html (:body (:img :alt "alt" :src "pics/pic01.jpg"))))) ---------------------------------------------------------------------------------------- and now sometimes it shows a picture and if I change some of the slashes it doesn't. If I change it backit still doesn't show a picture ?
From: Captain Obvious on 24 Jun 2010 05:29 ??>> You do not have a good understanding how web servers work. They do not ??>> operate "in a working directory", they serve requests. v> If I may, I can expand on this a bit. The closest thing to a "working v> directory" is what many HTTP servers refer to as www-root. Many times v> this maps to a physical directory but hunchentoot has no such v> limitation. In Apache DocumentRoot merely provides a default, it is still possible to configure it in a more fine-grained way. So it is not a limitation, just a convenience feature. v> If anybody needs to know what the lisp current working directory is, v> just do, v> (truename ".") Current directory for Common Lisp image is what *default-pathname-defaults* points to. v> but I don't recommend working with relative directories. You can use it if you know _for sure_ what it is -- for example, when you set it itself, explicitly. For example, for project foobar directory structure can look like this: foobar/ static-files/ src/ whatever/ foobar.asd Then somewhere in initialization source file I do this: (setf *default-pathname-defaults* (asdf:component-pathname (asdf:find-system :foobar))) After that I'm pretty sure that *default-pathname-defaults* is foobar, and so #p"static-files/" is a foobar/static-files. This is convenient if you have multiple different versions of same project -- then you can be sure that project uses static files which are in its source tree. Also, it saves typing. v> When doing web work, it's safer to fully specify file paths when v> working with paths internally within the application server. I'm not sure about that -- if you forget updating paths after moving project, you'll be using wrong static files. That might have security implications. It is better when it is automatic.
From: Captain Obvious on 24 Jun 2010 05:35
HB> I made folder dispatcher and handler like this: HB> ----------------------------------------------------------------------- HB> (push (hunchentoot:create-folder-dispatcher-and-handler "pics/" HB> "c:mypics/") HB> hunchentoot:*dispatch-table*) It should be "/pics/" and "c:/mypics/", I think. HB> ----------------------------------------------------------------------- HB> and have a page code like this: HB> ----------------------------------------------------------------------- HB> (defun start-page () HB> (cl-who:with-html-output-to-string (*standard-output* nil :indent t) HB> (:html HB> (:body HB> (:img :alt "alt" :src "pics/pic01.jpg"))))) It should be "/pics/pic01.jpg". HB> ----------------------------------------------------------------------- HB> and now sometimes it shows a picture and if I change some of the HB> slashes it doesn't. If you change "some of the slashes" it changes meaning. I strongly recommend learning what these slashes mean. E.g.: / is the root directory. /pics/ is a directory in the root directory. pics/ is relative directory name. It depends on context. It is a good idea not to use it until you're 100% sure you actually need that. For Windows pathnames you have disk name as a prefix, e.g. c:/mypics/ means directory mypics in the root of disk C:. But it is quite similar otherwise. |