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

[Hans Hübner]

Frederico,

I made a few more changes to make :HELLO-WEB behave better.  Please
update from svn.

Cheers,
Hans

2010/6/4 Hans Hübner <hans.huebner at gmail.com>:
> 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
>>
>