[bknr-devel] BKNR web, best place to start digging

[Hans Hübner]

Hi Frederico,

I pushed a fix to the :HELLO-WEB project that removes the problem that
you report.  The issue is that one needs to specify a
:REQUEST-DISPATCHER argument when creating the Hunchentoot ACCEPTOR
object in order to switch off Hunchentoots internal dispatching
mechanism.

I have a patch for Hunchentoot in the works that will remove all of
the callback arguments and replace them by generic functions.  Then,
BKNR will have a BKNR-ACCEPTOR mixin class that one has to use and
that implements the required protocol callbacks.  But for now, you
should be good to go with your experiments.  I'll fix the Quickhoney
project as well, but HELLO-WEB is a better starting point for
something new.  You can always look at the other projects for
reference.

-Hans

2010/6/4 Frederico Muñoz <fsmunoz at gmail.com>:
> Hello,
>
> I've been trying to find out why I can't get any of the projects to
> work, and I've at least a reasonable idea why. Now, I don't know is
> this is because I'm doing something wrong or if something has changed
> in terms of what hunchentoot expects... I find the later strange since
> it would be quite visible, but at this stage I haven't got any other
> idea.
>
> Apologies for the length of this message (and feel free to disregard
> it if tackling this would consume to much time).
>
> I've traced how things work (simplified, I'm leaving authentication
> checking out):
>
> 1) BKNR adds an handler to hunchentoot's *dispatch-table*
> 2) Creating a website (a singleton, referenced by *website*) instance
> adds the handlers to the bknr website-handlers
> 3) When a page is requested the bknr-dispatch handle is called by hunchentoot
> 4) bknr-dispatch inspects the *request* to see if there is a match for
> the uri in the website handlers
> 5) If there is, calls invoke-handle with the handler as an argument
> 6) invoke-handle does some housekeeping, and then calls (handle handler).
> 7) This reaches a custom method, made for whatever class was specified
> in website instance. In my test it just produces some HTML
>
> And here is where things stop working: my simple test (a website class
> with one single handler, a handler class and a handle-object method)
> works up until this point, but it doesn't seem to produce what
> hunchentoot expects: just as the quickhoney project (and the
> hello-web) I get something like:
>
> -----
> The value "<?xml version=\"1.0\" encoding=\"UTF-8\"?>
> (... rest of produced HTML by the handle-object above...)
> is not of type
>  (OR FUNCTION SYMBOL).
> ------
>
> I'm very far from an expert in any of the components involved, so I've
> quite likely omitted some important step. By reading the hunchentoot
> docs I gathered that when it polls the handlers in the
> *dispatch-table* it expects as return value either a handler (from
> what I've gathered, a symbol representing a function name) or nil. I
> *think* that this could be the problem. Indeed, if I change my
> handle-object method from:
>
> -----
> (defmethod handle-object ((handler hello-object-handler) object)
>  (with-bknr-page (:title "demo handler")
>    (html (:p "This is the demo handler"))))
> -----
> to
> -----
> (defmethod handle-object ((handler hello-object-handler) object)
>  'handle-object2)
>                     ))
>
> (defun  handle-object2 ()
>    (with-bknr-page (:title "Debug")
>      (html (:p "This is the demo handler"))))
> -----
>
> it starts working: hunchentoot got a symbol as return value, and
> promptly calls it.
>
>
> What I find strange here is that I'm using the hunchentoot from the
> bknr trunk repo, so this isn't an issue with a new release.
>
> Regards,
>
> Frederico
>