Sorry for replying twice, I missed addressing one paragraph and I think its a fairly important one.
On Wed, Feb 22, 2012 at 6:00 AM, Aaron Bentley <aa...@canonical.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 12-02-20 11:55 PM, Robert Collins wrote: >> So, going back at least 18 months, maybe more, there has been a >> long slow-running conversation amongst us about what we render >> were, with different projects choosing different answers. >> >> I think we have enough data now, that we can consolidate on a good >> default answer and ask that everyone pick that answers *by >> default* with variation needing to be experiments - explicit >> decisions to learn something new. >> >> tl;dr: lets: * render searchable content on server side and client >> side using a common template language * render the forms needed to >> file a bug server side and optionally client side * render all >> other forms exclusively client side and have them communicate >> exclusively via the API > > I think that this approach makes sense. The current API is not > roundtrip-efficient for multiple-item listings, but forms are usually > related to a small number of items, so this should not be a problem. > > You didn't specify that the API must be used when rendering searchable > content on the client side. The JSONCache is roundtrip-efficient for > this purpose, and can also deliver identical data to client-side and > server-side templates, so I think we should prefer it for now. Lists of content such as lp.net/bzr/2.0 have a bunch of different data to assemble, *and* we want server rendering for Google. That means we need a View class, and we will have the data locally so shoving it into the LP JSONCache is a simple and effective means of handing it off to the client. That said, its also a waste: we have already rendered the content at that point (because we want to show it to Google) so we may as well just hand over the rendered HTML (or browser-sniff and render exclusively on the client for non-search-bots). Transmitting the same data twice is a waste though; I am strongly in favour of rendering directly on the client all the time. It is desirable to do so because of things like the cog on the bug listings view that lets additional data not rendered by default be added to the view - we need all the data which the initial server rendered output wouldn't necessarily include (unless we change how we tackle it and hide content using css classes rather than template output - one constant render, client side visibility choices). That said, we may want to use the API anyway, because it gives us greater flexability on reuse of the results of that sort of search, and thats pretty valuable. I think it would be good for us to try building on the API for such things in the first instance; we can always fall back to the JSONCache, for all that it does (roughly) double the page size. For things like vocabularies or pretty much anything that we don't care about google indexing finding, I think the API is an ideal fit - and we can stop using the xhtml media type and get pure JSON back (which will also exclude a number of escaping headaches we keep running into :)) -Rob _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
