Created on 2013-02-25 16:26 by stefan, last changed 2019-10-06 22:14 by rouilj.
|msg4808||Author: [hidden] (stefan)||Date: 2013-02-25 16:26|
The existing web frontends are rather clumsy and inconvenient to use. Browsing the results of a list or search request is a good example. In particular, when filling in (multi-)links from a search, this becomes very evident, as the process involves clicking through a cascade of popup windows and frames. This could be improved with a few small additions: The server could provide a json interface to search and query, which the different template could then make use of with some jquery.
|msg4809||Author: [hidden] (rouilj)||Date: 2013-02-25 16:51|
In message <email@example.com> <firstname.lastname@example.org>, Stefan Seefeld writes: >New submission from Stefan Seefeld: > >The existing web frontends are rather clumsy and inconvenient to use. >Browsing the results of a list or search request is a good example. In >particular, when filling in (multi-)links from a search, this becomes >very evident, as the process involves clicking through a cascade of >popup windows and frames. Hmm, there shouldn't be any frames used at all, but I agree autocomplete and a less heavyweight selection/display widget would be good. >This could be improved with a few small additions: >The server could provide a json interface to search and query, which the >different template could then make use of with some jquery. I submitted an issue to develop a rest interface to accompany the current xmlrpc interface: http://issues.roundup-tracker.org/issue2550734 (maybe a good GSoC project??) that would make this easier. It seems that an xmlrpc interface is defined to always return XML (http://xmlrpc.scripting.com/spec "The Content-Type is text/xml."), but technically I don't see a reason that it couldn't look at the http accept header or have a field in the xml request that defines the response format for the payload: <methodResponse> <param> <value format="json"> .... </value></...> but this is probably trying to drive a nail with a screwdriver. If alternate mechanisms for setting the fields are added, it should be done as a progressive enhancement and not eliminate the possibility of roundup being used with a text based browser such as elinks or w3m. Text browsers are quite useful for a fast review/change or upload of a file to an issue when used over ssh.
|msg4811||Author: [hidden] (ezio.melotti)||Date: 2013-02-25 23:00|
+1 FWIW I implemented an ajax autocomplete for the nosy list for bugs.python.org in http://psf.upfronthosting.co.za/roundup/meta/issue417 (the implementation has some b.p.o-specific things, but most of the code can be reused).
|msg6699||Author: [hidden] (rouilj)||Date: 2019-10-06 22:14|
With the current work done on issue2550734 we should have a rest interface that can be used for exploring this idea in more detail. Any takers?
components: + Web interface, API
|2016-07-09 21:03:37||rouilj||set||type: rfe|
|2013-04-10 19:23:56||ber||set||nosy: + ber|
messages: + msg4811
messages: + msg4809