Re: [Twisted-web] Livepage, ClientHandle and context [continued]
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.
On Jun 27, 2005, at 5:23 PM, Chris Were wrote:
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?
This is already possible using IClientHandle.transient. The problem with allowing arbitrary callables from arbitrary objects is that you have to identify them somehow using a string which can then later be used to retrieve the same object/callable. Forcing the developer to use strings (dispatch_*/handle_* and handleWithPath) means that everything about which callables are exposed is explicit, and the lifetime is well-defined.
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.
But this is exactly why I was proposing using query args. REST is representational state transfer of web resources; with foo/ and foo/ xml you have two separate web resources which should really only be one resource. With a query parameter and one resource, the query parameter (or header, etc) is requesting a different representation of the state of that one resource. Donovan
participants (2)
-
Chris Were -
Donovan Preston