I expect this can be rectified in livepage.py (line 728 on my co): def locateHandler(self, ctx, path, name): ### XXX TODO: Handle path return getattr(self, 'handle_%s' % (name, ))
The path here is meant to be a string which names a Fragment or other dispatch path. As you can see, none of this is implemented yet, but this is my solution to this problem that you and others on this list have had. Basically the API in javascript would look something like this:
server.handleWithPath('onclick', 'some/path', 'someArgument')
locateHandler would change to look more like locateChild, breaking apart the path into segments and consuming them until it locates the target. I'm not sure how the default locateHandler implementation will locate action targets; perhaps with dispatch_* prefixed methods? Here is a small example:
class MainPage(Page): docFactory = loaders.xmlstring("""<html xmlns:n="http://nevow.com/ns/nevow/0.1"> <a onclick="server.handleWithPath('onclick', 'someFragment', 'someArg')"> Click me </a> <span n:render="liveid" /> <span n:render="liveglue" /> </html>""")
def dispatch_someFragment(self, ctx): return MyFragment()
class MyFragment(Fragment): def handle_onclick(self, ctx, someArg): assert someArg == 'someArg'
Suggestions on different names other than "dispatch_*" are welcome; the main reason I haven't implemented this functionality yet is because I can't decide what to call it! :-)
I'd say dispatch is fine (and not just because I'd like to see this implemented ;-) Taking from the chatola example: return context.tag(onsubmit=livepage.handler(onSubmit, getValue('inputline'))) What would be good is if something similar could be used with dispatch, perhaps the following (assuming this code is within a fragment): return context.tag(onsubmit=livepage.handler(onSubmit, getValue('inputline',self))) ie: livepage.handler(func,arg,fragment=None) if this mapped the javascript to server.handleWithPath('action','fragment','arg') and also mapped (if not there already) the dispatch_fragment in the MainPage Would something along those lines be feasible?
I suggest using a query parameter rather than an additional URL segment. xml is a different "view" of the same "object"; in my opinion, URLs should represent "objects" (Resources) and query parameters should be used to parameterize how the view renders. One might also be able to use the "Accept" header that browsers send to negotiate the rendered content type. But this is just a suggestion. Whatever works for you is fine with me :-)
I tend to agree that xml is a different "view", but I see a benefit in a REST-like approach to have /xml at the end of an existing Resource... perhaps the idea that /xml is an extended view to the existing Resource. Chris.