[Twisted-web] Livepage, ClientHandle and context [continued]
Donovan Preston
dp at ulaluma.com
Tue Jun 28 12:51:46 MDT 2005
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
More information about the Twisted-web
mailing list