On Fri, 23 Jul 2004 09:36:57 -0400, Pete Kazmier pete-tbnl-dev@kazmier.com wrote:
On Fri, 2004-07-23 at 09:10, Stefan Scholl wrote:
But I think it should be an exception to the rule. Let the handler return _two_ values if he is sure that the reason for not processing the request is no fatal error and dispatching should continue. Normal handlers just return a string or nil if they have a problem. Handlers which are aware of the possibility that other dispatchers could catch the request when they fail return (values nil t)
Thats a good idea. I keep forgetting about the usefulness of the ability to return multiple values. With this ability, I would be able to minimize the complexity of my dispatch functions and move some of that logic into the handler itself which could then have the option of opting to not process the request (defer to the next dispatcher).
I'm not sure what would be the right way. At the moment it is not specified what it means if a handler returns NIL so we could as well implement Pete's initial idea to let the next dispatcher take over in this case. Using a second return value would also be a possibility but it would require more work in modlisp.lisp because the HANDLER-BIND code already generates a second return value to denote errors.
Out of curiousity, what do you guys like to use for generating your HTML? Are you firm believers in the whole "separation of logic and presentation" and prefer the use of template engines? Or do you prefer to output HTML from your TBNL apps and then let folks use CSS to adjust the presentation as they see fit? Or do you use a combination of both?
I've written HTML-TEMPLATE for separation of logic and presentation. Not because I think it's "the way to go" but mostly because I sometimes have to work with web designers (graphical artists) who I can't bother to modify my Lisp code directly. It turned out that I use it very rarely - I think it's clumsy. I usually use CL-WHO.
I personally think that "separation of logic and presentation" is a good idea in theory but it rarely works in practice, unfortunately.
Cheers, Edi.