[Twisted-web] Livepage, ClientHandle and context [continued]

[Donovan Preston]

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