From hans.huebner at gmail.com Tue Jun 1 08:53:55 2010 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Tue, 1 Jun 2010 10:53:55 +0200 Subject: [bknr-devel] Problems with XML import/export, can't follow the tutorial In-Reply-To: References:

Message-ID: 2010/5/31 Frederico Mu?oz : > 1) As it is write-to-xml defaults to *standard-output*. It seems > sensible to me to do so, and one can always provide a different > stream. The tutorial, however, seems to indicate that write-to-xml > should return the XML output as a return value... not sure if adapting > the tutorial is the best course, or changing the way write-to-xml > works by using a string stream and returning the output (I've tried, > it works, but returns everything escaped, which is aesthetically > doubtful) I would stay with WRITE-TO-XML writing to a stream that defaults to *STANDARD-OUTPUT*. If you like, add a trivial wrapper WRITE-TO-XML-STRING that returns an XML string instead. Writing to a string consumes more memory and it would be stupid to first serialize into a string when one really wants to write to a stream. > 2) As it is one can't use lists (including cons) as slot values. I've > found this by having a "location" slot in my "army" class which is > represented by a cons like (X . Y). This returns an error (since the > test is made with consp, but the cdr isn't a list). For cons the "fix" > is easy (e.g. use alexandria's proper-list-p), but when a slot value > is really a list the output isn't as expected: a class which has '(1 2 > 3) has a slot value will produce: > > 1 > 2 > 3 > > instead of what would be expected: > > '(1 2 3) I do not think that a quoted list in Lisp syntax is expected in XML output. I rather think that the current behavior that you describe is correct, and the XML deserializer should combine the individual elements that occur multiple times into one list. The XML produced should, by default, try to serialize everything into proper XML and not use Lisp data formats. Cheers, Hans From fsmunoz at gmail.com Tue Jun 1 18:40:00 2010 From: fsmunoz at gmail.com (=?ISO-8859-1?Q?Frederico_Mu=F1oz?=) Date: Tue, 1 Jun 2010 19:40:00 +0100 Subject: [bknr-devel] Problems with XML import/export, can't follow the tutorial In-Reply-To: References:

Message-ID: Hi Hans, Thanks for the comments! 2010/6/1 Hans H?bner : > I would stay with WRITE-TO-XML writing to a stream that defaults to > *STANDARD-OUTPUT*. ?If you like, add a trivial wrapper > WRITE-TO-XML-STRING that returns an XML string instead. ?Writing to a > string consumes more memory and it would be stupid to first serialize > into a string when one really wants to write to a stream. Yes, good idea. I've added another macro that does exactly that. > I do not think that a quoted list in Lisp syntax is expected in XML > output. ?I rather think that the current behavior that you describe is > correct, and the XML deserializer should combine the individual > elements that occur multiple times into one list. ?The XML produced > should, by default, try to serialize everything into proper XML and > not use Lisp data formats. I had the wrong approach, and what you say makes much more sense. I've played around with exporting/importing, and by specifying adequate parsers for the slots my example works as expected, in the sense that the exported XML produces the correct values when imported. At this stage the only other issue I can think of is the containment parsing, which isn't being done (I mean, the containment slot isn't being initialised to :* or :+ depending on the DTD, and so any multi-element slot only contains the last element). It works correctly when one explicitly sets the :container though, so the issue is only with setting the initial value. So, my plans at this stage are: 1) Tackle the containment issue 2) In the end of the changes update the tutorial 3) Eventually look at the "xml-update" file which is lingering there, could be useful. I'll come back when I have something worth seeing. As it is right now I have successfully used XML impex to export and import objects, almost in a datastore kind of way. Regards, Frederico From fsmunoz at gmail.com Wed Jun 2 17:10:48 2010 From: fsmunoz at gmail.com (=?ISO-8859-1?Q?Frederico_Mu=F1oz?=) Date: Wed, 2 Jun 2010 18:10:48 +0100 Subject: [bknr-devel] BKNR web, best place to start digging Message-ID: 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). From hans.huebner at gmail.com Thu Jun 3 06:01:50 2010 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Thu, 3 Jun 2010 08:01:50 +0200 Subject: [bknr-devel] BKNR web, best place to start digging In-Reply-To: References: Message-ID: 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 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 at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/bknr-devel > From fsmunoz at gmail.com Thu Jun 3 17:00:48 2010 From: fsmunoz at gmail.com (=?ISO-8859-1?Q?Frederico_Mu=F1oz?=) Date: Thu, 3 Jun 2010 18:00:48 +0100 Subject: [bknr-devel] BKNR web, best place to start digging In-Reply-To: References:

Message-ID: Hi Hans, Thank you for your feedback. 2010/6/3 Hans H?bner : > 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 From fsmunoz at gmail.com Fri Jun 4 02:06:33 2010 From: fsmunoz at gmail.com (=?ISO-8859-1?Q?Frederico_Mu=F1oz?=) Date: Fri, 4 Jun 2010 03:06:33 +0100 Subject: [bknr-devel] BKNR web, best place to start digging In-Reply-To: References:

Message-ID: 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 " (... 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 From hans.huebner at gmail.com Fri Jun 4 05:23:08 2010 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Fri, 4 Jun 2010 07:23:08 +0200 Subject: [bknr-devel] BKNR web, best place to start digging In-Reply-To: References:

Message-ID: 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 : > 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 " > (... 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 > From hans.huebner at gmail.com Fri Jun 4 06:42:09 2010 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Fri, 4 Jun 2010 08:42:09 +0200 Subject: [bknr-devel] BKNR web, best place to start digging In-Reply-To: References:

Message-ID: 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 : > 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 : >> 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 " >> (... 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 >> > From fsmunoz at gmail.com Fri Jun 4 13:21:06 2010 From: fsmunoz at gmail.com (=?ISO-8859-1?Q?Frederico_Mu=F1oz?=) Date: Fri, 4 Jun 2010 14:21:06 +0100 Subject: [bknr-devel] BKNR web, best place to start digging In-Reply-To: References:

Message-ID: 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 : > 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. From fsmunoz at gmail.com Fri Jun 4 13:29:59 2010 From: fsmunoz at gmail.com (=?ISO-8859-1?Q?Frederico_Mu=F1oz?=) Date: Fri, 4 Jun 2010 14:29:59 +0100 Subject: [bknr-devel] BKNR web, best place to start digging In-Reply-To: References:

Message-ID: 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 From hans.huebner at gmail.com Fri Jun 4 13:25:52 2010 From: hans.huebner at gmail.com (=?ISO-8859-1?Q?Hans_H=FCbner?=) Date: Fri, 4 Jun 2010 15:25:52 +0200 Subject: [bknr-devel] BKNR web, best place to start digging In-Reply-To: References:

Message-ID: 2010/6/4 Frederico Mu?oz : > 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