Ah, excellent. Thank you Leslie. For posterity... During the dispatch and rendering phases, nothing happens to the hunchentoot http stream until render-page gets called, which is after the widget hierarchy is rendered to a string. At any point in those two phases you can return a string (or stream?) explicitly via abort-request-handler and have it be pushed out in the reply with the current reply header settings.
Be sure to set the content type: (setf (hunchentoot:content-type*) "text/xml")) so the receiving browser does the right thing. I simply stuck a test into my top level dispatch widget which picks off URLs based on a root token (e.g. /webapp/api/...) and calls an API handler that uses the rest of the tokens, the parameters, and the session authentication object to determine what to return. Ian On Sep 10, 2009, at 12:13 AM, Leslie P. Polzer wrote: > > On Wed, Sep 09, 2009 at 07:44:56PM -0700, Ian Eslick wrote: > >> I'm trying to determine the best way to allow a weblocks webapp to >> implement a REST style API ala twitterThe problem is that any webapp >> request wraps all returned data in an <html tag with header info >> embedded. I either need to write some kind of extension in the >> weblocks request handler or add another raw dispatch handler to >> hunchentoot. Has anyone solved this problem already (providing RSS >> feeds, etc?) > > You can use Hunchentoot's ABORT-REQUEST-HANDLER (I think that's > the name) to send a direct reply from your dispatcher, thus > bypassing the Weblocks request pipeline while still using > Weblocks dispatch. > > Leslie > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
