launchpad-dev team mailing list archive

[Robert Collins <robertc@xxxxxxxxxxxxxxxxx>]

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 <aaron@xxxxxxxxxxxxx> 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