Re: copy events and content from server

Hallvord,


you seem to have not included João Eiras' answer:

Le 5 mai 2011 à 04:34, João Eiras a écrit :
> A synchronous XHR solves this use case and there are no magic locks.


Although I haven't explicitly tried to implement it and clearly feel it a synchronous XHR can block the UI in an ugly way, it can indeed be sufficient.


But, couldn't a better solution, not involving locks, be a variation of what you suggest:?

  event.clipboardData.pushDataFromRequest(flavour, xhr)

The big difference is that there is a chance for the user-agent to display that his copy action is being process. I think the flavour must stay in the hands of the script (as the map media-types -> flavors is currently very partial).

I'm surprised to be the only one pushing this considering the huge wealth of desktop-like services. Use cases such as copy-a-pdf-fragment from Google Docs Drawing, generate a complex ICS, or produce a good raster image from a graph-display...

paul

Le 17 mai 2011 à 02:30, Hallvord R. M. Steen a écrit :

>>> In many of the scenarios I have working for, the content to be put on the clipboard would come from a "luxury" knowledge structure on the server, one that has access to some semantic source and can infer useful representations out of it; these get put to the clipboard.
>>> An offline HTML would also be an example of it.
>> 
>> but I am realizing that this is probably not possible to do because the only way to do obtain something from the server is to wait until a callback is called (and this is good so) at which time the copy event might be long gone already.
> 
> Indeed.
> 
>> Would it be thinkable to *lock* the copy event until either a timeout occurs or an unlock is called?
> 
> It sounds like a quite "advanced" use case. I briefly considered something like event.clipboardData.pushContentsOfURL('/foo/bar') but that would be way to limited in options - POST/GET, post data etc. I would like to defer this to later and see if we get more demand for it. Overall, the push for web applications is a lot about removing logic from the server and adding more on the client's side, so I'm unsure how common this state (when the server knows significantly more than the client-side logic about what should be placed on the clipboard) is and will be going forward.

Received on Tuesday, 17 May 2011 06:51:43 UTC