Paul Meurer <[email protected]> writes: > Hi, > >> I'm looking at it. It's puzzling -- this can only happen if >> update-children was never called for the selector that the navigation >> is derived from. This is something that should never happen. >> >> Paul -- any chance you could provide me with a more complete >> backtrace? >> I'd really like to know who called selector-base-uri and when. > > I tried to reproduce the problem, but it magically disappeared! The > solution to the puzzle is that I had changed two things in the > meanwhile: I used Opera instead of Safari 4 Beta, and I had set > hunchentoot::*default-content-type* to "application/xhtml+xml; > charset=utf-8". Then it works in Opera, but not in Safari or Firefox. > If I set hunchentoot::*default-content-type* back to "text/html; ...", > it doesn't work. I get the following trivial-backtrace: (see below).
Thanks, this backtrace explains things very well. But I don't think this has much to do with *default-content-type*. The problem is that after you log in, the login widget gets replaced with a navigation widget in an AJAX request. Then weblocks tries to render the dirty widgets, which include the navigation widget. However, the navigation widget does not know what its base-uri is, because it was never accessed with an URI before. It suddenly got dropped in and tree shakedown wasn't performed. I don't know what the correct solution is here. It is not something I expected when I wrote the new navigation code. I'll keep thinking, in the meantime any suggestions are welcome. --J. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "weblocks" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/weblocks?hl=en -~----------~----~----~----~------~----~------~--~---
