[hunchentoot-devel] Upcoming Hunchentoot release - Web design wanted
Hi, as you may have seen from the revision log (http://bknr.net/trac/log/trunk/thirdparty/hunchentoot?rev=4650), there has been a fair amount of change to Hunchentoot in the recent weeks and Edi is planning to make a new release soon. Here are the highlights of what has been changed: - Logging has been overhauled. There are now two generic function ACCEPTOR-LOG-MESSAGE and ACCEPTOR-LOG-ACCESS that perform the logging and can be specialized on a per-acceptor basis. By default, Hunchentoot now logs to the console instead of being silent. - Error handling and reporting has been reworked. Internal errors are handled more gracefully. - The default request handler is gone. By default, Hunchentoot now generates a 404 message if an unknown URL is requested. - Error message generation can now be customized on a per-acceptor fashion. Also, code to generate error messages from HTML template files has been added. - By default, Hunchentoot now serves static files. A document tree including a simple "It works!"-like home page, the documentation in HTML format and customized error pages will be distributed with Hunchentoot and served by default. - Robustness changes from ITA - Various smaller bug fixes Before making a release, I would like to improve the looks of the standard document tree and the error pages a little. Does someone have web design skills that they want to contribute? If so, please have a look at the current development version (svn co http://bknr.net/svn/ediware) and me patches. I'm not looking for anything too fancy. Good looks can't hurt, though! :) Thanks! -Hans
Hi, I started testing a new version of Hunchentoot and found that you forgot to exported "ACCEPTOR-DISPATCH-REQUEST" - it is absolutely necessary! In addition, the exported "ACCEPTOR-REQUEST-DISPATCHER" is obsolete. Andrey
On Tue, Feb 15, 2011 at 5:30 PM, Gordon Sims <gordon@itasoftware.com> wrote:
Andrey Moskvitin wrote:
In addition, the exported "ACCEPTOR-REQUEST-DISPATCHER" is obsolete. HUNCHENTOOT:*LISTENER* seems the same. Perhaps it can also be removed.
Thank you for the reports, I have fixed those two and will see if I can automatically clean up the rest of the exports. Cheers, Hans
"ACCEPTOR-STATUS-MESSAGE" also want to export. Please add to the documentation ("Tutorials and add-ons") link to the RESTAS (http://restas.lisper.ru/) - my web framework based on Hunchentoot. Andrey
On Tue, Feb 15, 2011 at 7:58 PM, Andrey Moskvitin <archimag@gmail.com> wrote:
"ACCEPTOR-STATUS-MESSAGE" also want to export.
Please add to the documentation ("Tutorials and add-ons") link to the RESTAS (http://restas.lisper.ru/) - my web framework based on Hunchentoot.
Done, thank you! Please keep bug reports coming! -Hans
Hi, Problems with calling 'error-contents-from-template in the 'acceptor-status-message: 1. Ignored variables *show-lisp-errors-p* and *show-lisp-backtraces-p* 2. Do not set content-type to "text/html; charset=iso-8859-1" 3. Path /img/made-with-lisp-logo.jpg may be invalid Maybe it does not need? (apply 'make-cooked-message http-status-code args) well suited for most occasions. IMHO, 404.html and 500.html templates only complicate the code and create problems, but virtually useless in practice. Andrey
On Wed, Feb 16, 2011 at 10:55 AM, Andrey Moskvitin <archimag@gmail.com> wrote:
Problems with calling 'error-contents-from-template in the 'acceptor-status-message:
1. Ignored variables *show-lisp-errors-p* and *show-lisp-backtraces-p*
This is intentional. The template determines whether a backtrace or error message is displayed.
2. Do not set content-type to "text/html; charset=iso-8859-1"
That is right. I am going to fix this, but while looking at the problem, I found that Hunchentoot is not currently smart about the content type that it generates. I think that the content type should automatically match the external format, and that it should default to utf-8 instead of latin-1. I'm going to address that in a separate commit.
3. Path /img/made-with-lisp-logo.jpg may be invalid
Right. The error pages supplied with Hunchentoot will work only when the images and possibly other resources that are referenced from them are available at the expected locations. My plan is to supply a standard document tree that is useful. Users are free to ignore that document tree, and Hunchentoot will automatically fall back to cooked message bodies when no template is found.
Maybe it does not need? (apply 'make-cooked-message http-status-code args) well suited for most occasions. IMHO, 404.html and 500.html templates only complicate the code and create problems, but virtually useless in practice.
I don't find the whole thing overly complicated, and you are free to ignore the feature if you don't like it or think it is useless. Thank you for reporting the problems that you've found! Edi has the last say in all this anyway. -Hans
On Wed, Feb 16, 2011 at 11:57 AM, Andrey Moskvitin <archimag@gmail.com> wrote:
you are free to ignore the feature if you don't like it
In this case, need to export "MAKE-COOKED-MESSAGE", so that I could normally call it for my acceptor.
Setting ACCEPTOR-ERROR-TEMPLATE-DIRECTORY in the acceptor to NIL and (CALL-NEXT-METHOD) from your own ACCEPTOR-STATUS-MESSAGE method should do, or am I missing something? -Hans
Setting ACCEPTOR-ERROR-TEMPLATE-DIRECTORY in the acceptor to NIL and (CALL-NEXT-METHOD) from your own ACCEPTOR-STATUS-MESSAGE method should do, or am I missing something?
Yes, thank you, but only ACCEPTOR-ERROR-TEMPLATE-DIRECTORY then also need to export ) Andrey
On Wed, Feb 16, 2011 at 1:08 PM, Andrey Moskvitin <archimag@gmail.com> wrote:
Setting ACCEPTOR-ERROR-TEMPLATE-DIRECTORY in the acceptor to NIL and (CALL-NEXT-METHOD) from your own ACCEPTOR-STATUS-MESSAGE method should do, or am I missing something?
Yes, thank you, but only ACCEPTOR-ERROR-TEMPLATE-DIRECTORY then also need to export )
I've done that, but you'll normally don't want to follow my advice literally but rather supply a :ERROR-TEMPLATE-DIRECTORY as initarg when you create your acceptor. If you're working with a derived acceptor class, consider using a :DEFAULT-INITARGS clause in your acceptor class definition to override what Hunchentoot uses for bare ACCEPTOR instances. -Hans
I've done that, but you'll normally don't want to follow my advice literally but rather supply a :ERROR-TEMPLATE-DIRECTORY as initarg when you create your acceptor. If you're working with a derived acceptor class, consider using a :DEFAULT-INITARGS clause in your acceptor class definition to override what Hunchentoot uses for bare ACCEPTOR instances.
Yes, just like I did) Thank you. Andrey
On Wed, Feb 16, 2011 at 11:40 AM, Hans Hübner <hans.huebner@gmail.com> wrote:
On Wed, Feb 16, 2011 at 10:55 AM, Andrey Moskvitin <archimag@gmail.com> wrote:
2. Do not set content-type to "text/html; charset=iso-8859-1"
That is right. I am going to fix this, but while looking at the problem, I found that Hunchentoot is not currently smart about the content type that it generates. I think that the content type should automatically match the external format, and that it should default to utf-8 instead of latin-1. I'm going to address that in a separate commit.
http://bknr.net/trac/changeset/4655 corrects this problem. Hunchentoot now determines the charset= attribute in text content type headers automatically when a handler returned a string. The content type is not touched when the handler directly writes to the stream or returns octets for Hunchentoot to send. Please let me know if there are any problems with this change. -Hans
Hunchentoot now determines the charset= attribute in text content type headers automatically when a handler returned a string. The content type is not touched when the handler directly writes to the stream or returns octets for Hunchentoot to send.
Please let me know if there are any problems with this change.
My code set content-type to "text/plain", but after this error occurs. As a result, sends to client 500.html with "content-type=text/plain". Andrey
On Wed, Feb 16, 2011 at 1:21 PM, Andrey Moskvitin <archimag@gmail.com> wrote:
Hunchentoot now determines the charset= attribute in text content type headers automatically when a handler returned a string. The content type is not touched when the handler directly writes to the stream or returns octets for Hunchentoot to send.
Please let me know if there are any problems with this change.
My code set content-type to "text/plain", but after this error occurs. As a result, sends to client 500.html with "content-type=text/plain".
Thanks for the report, the problem is fixed by this change: http://bknr.net/trac/changeset/4657 -Hans
I ended adaptation own applications for the new version of Hunchentoot. I have everything working. In general, I think Hunchentoot is improved. Thank you. Andrey
participants (3)
-
Andrey Moskvitin -
Gordon Sims -
Hans Hübner