Hello,
While working on the XML impex component I had a look around the web part of BKNR (which is the least documented). What would be the best project to use as a starting point? One would think that hello-web would be it, however I have been unable to to past hunchentoot internal errors, perhaps because the code doesn't reflect the current API. The same things happens with quickhoney, which is a bit stranger since I think that this one is more recent.
Any advice welcome. As my previous message regarding XML impex I'm not looking for hand-holding or fixes (which is why I don't even post any concrete errors), merely a general pointer to where to start: this and that is a bit old, you would liekly be more lucky with that other one (or even forget about it, at this stage it would not be trivial to give any sort of indication).
PS: My motivation is only that since I like the datastore component (with the indices, and now the XML impex) it would not be surprising if the rest is also something that I could use. However one can always use the datastore with other frameworks (e.g. weblocks, which seems to have some traction from what I've read, and uses cl-prevalence and Elephant as typical datastores - adding an example for the bknr datastore would be trivial).
Hi Frederico,
in order to get an impression how the web stuff works, have a look at the projects/ directory in the subversion repository (http://bknr.net/trac/browser/trunk/projects/quickhoney). Unfortunately, many of the projects have regressed.
The quickhoney project works off the current trunk version. If you want to give it a try, load the :quickhoney system and evaluate (quickhoney::startup). To make your life easier, please check out the complete trunk from subversion and add all thirdparty/ directories to your asdf:*central-registry* (see src/make-core.lisp for a function that does that automatically).
The "bos" project is another customer project that I maintain, but it is deployed off a branch and I don't know if it works off the trunk. It is the project that I put most work into, so you may want to look at it to get some idea how the web environment is used.
There is a "hello-web" project that is meant to be a template for new projects, but I have not maintained it in a while and it does not currently work.
One thing that I regret having done is that I used to import framework packages into my application. This makes it much harder to study source code, as the symbols do not immediately reflect the package that they're coming from. I've moved away from that practice a few years ago, but in the projects directory, you'll have to learn which of the symbols are actually from the framework packages.
Cheers, Hans
On Wed, Jun 2, 2010 at 19:10, Frederico Muñoz fsmunoz@gmail.com wrote:
Hello,
While working on the XML impex component I had a look around the web part of BKNR (which is the least documented). What would be the best project to use as a starting point? One would think that hello-web would be it, however I have been unable to to past hunchentoot internal errors, perhaps because the code doesn't reflect the current API. The same things happens with quickhoney, which is a bit stranger since I think that this one is more recent.
Any advice welcome. As my previous message regarding XML impex I'm not looking for hand-holding or fixes (which is why I don't even post any concrete errors), merely a general pointer to where to start: this and that is a bit old, you would liekly be more lucky with that other one (or even forget about it, at this stage it would not be trivial to give any sort of indication).
PS: My motivation is only that since I like the datastore component (with the indices, and now the XML impex) it would not be surprising if the rest is also something that I could use. However one can always use the datastore with other frameworks (e.g. weblocks, which seems to have some traction from what I've read, and uses cl-prevalence and Elephant as typical datastores - adding an example for the bknr datastore would be trivial).
bknr-devel mailing list bknr-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/bknr-devel
Hi Hans,
Thank you for your feedback.
2010/6/3 Hans Hübner hans.huebner@gmail.com:
The quickhoney project works off the current trunk version. If you want to give it a try, load the :quickhoney system and evaluate (quickhoney::startup). To make your life easier, please check out the complete trunk from subversion and add all thirdparty/ directories to your asdf:*central-registry* (see src/make-core.lisp for a function that does that automatically).
I have several complete checkouts of trunk (some from 2006, I've used them to trace the code changes in XML impex), and I'm already using the thirdparty directories (which are quite convenient). I'm not able to get it running without some code massaging (e.g. hunchentoot changed the API, there is not start-server and stop-server, just start/stop upon an hunchentoot:acceptor instance), but that's minor. I've going to further investigate while I'm getting internal server errors on all pages. If it is supposed to work with trunk then there is something wrong on my end which I will try to fix.
The "bos" project is another customer project that I maintain, but it is deployed off a branch and I don't know if it works off the trunk. It is the project that I put most work into, so you may want to look at it to get some idea how the web environment is used.
Will do.
There is a "hello-web" project that is meant to be a template for new projects, but I have not maintained it in a while and it does not currently work.
I've also changed some parts of the code of that one, and at least it starts. But I get similar internal servers errors. If I reach a dead-end in terms of debugging I'll go into more detail.
One thing that I regret having done is that I used to import framework packages into my application. This makes it much harder to study source code, as the symbols do not immediately reflect the package that they're coming from. I've moved away from that practice a few years ago, but in the projects directory, you'll have to learn which of the symbols are actually from the framework packages.
Ok, no problem, SLIME helps a bit with that.
Regards,
Frederico
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
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@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):
- BKNR adds an handler to hunchentoot's *dispatch-table*
- 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
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@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@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):
- BKNR adds an handler to hunchentoot's *dispatch-table*
- 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
Hi Hans,
Thank you for both the quick reply and going through the effort of changing the code; without I would not easily understand how to proceed, even because the hunchentoot documentation omits that option... had I read the class documentation I would likely have found it out...eventually.
2010/6/4 Hans Hübner hans.huebner@gmail.com:
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.
Exactly, I understand it now.
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.
Right, I (sort of) see.
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.
I'm looking at the projects, but the way I tend to learn is by starting small and doing it myself, otherwise I get lost very quickly; in this case I can't really understand what is going on (and thus benefit from what is already written) without at least understanding the basics and being able to make something as simple as something that prints "Hello world". Since now I can already do that it is easier to pick code from the projects and understand what they do.
The hello-web project is now working, as is my own small experiment.
Best regards,
Frederico
PS: Actually I still have a small issue, but this one will be easier for myself to fix: I get "URI scheme :HTTP not supported" errors on the index, which Is likely tied with cxml not loading http DTDs. This is probably something related to the template mechanism.
2010/6/4 Frederico Muñoz fsmunoz@gmail.com:
PS: Actually I still have a small issue, but this one will be easier for myself to fix: I get "URI scheme :HTTP not supported" errors on the index, which Is likely tied with cxml not loading http DTDs. This is probably something related to the template mechanism.
Right, you need to have the XHTML DTDs in your local file system in order for the messages to go away. I don't currently have the time to look it up, but there is a dtd related special variable that needs to point to the directory with the DTDs, IIRC.
-Hans
Just a small update
PS: Actually I still have a small issue, but this one will be easier for myself to fix: I get "URI scheme :HTTP not supported" errors on the index, which Is likely tied with cxml not loading http DTDs. This is probably something related to the template mechanism.
Found it, it is something related to the initial setting of the cxml:*catalog*, which is done in template-handler.lisp but is apparently not working for me automatically. Setting the *template-dtd-catalog* by hand to an absolute path and remaking the catalogue fixes it, I'll take a look.
Regards,
Frederico
-
Frederico Muñoz -
Hans Hübner