launchpad-dev team mailing list archive

[Tom Berger <tom.berger@xxxxxxxxxxxxx>]

2009/11/12 Tim Penhey <tim.penhey@xxxxxxxxxxxxx>

> Hi All,
>
> Everything started out wonderfully... then it all went to crap.
>
> https://code.edge.launchpad.net/~thumper/launchpad/popup-diff/+merge/14770
>
> Works - mostly.
>
> I noticed that the diff rendered in the popup is weird for some reason.
> Exactly the same code is used to render the diff on the merge proposal
> page,
> but on the popup view, the diff table ends up outside the
> <div class="boardComment attachment diff"> for some very obscure reason.
>
> I even managed to change the way it worked with very few changes to make
> the
> JS and UI reviews happy.
>
> Next I went to integrate the same view on to the bug page, and here it blew
> up
> differently.  I was just using Y.io to load a page fragment and dump that
> into
> the pretty overlay.  However can't do that from bugs.launchpad.net when
> the
> view is registered against code.launchpad.net.
>
> This led to the realisation that I should probably use the API.  That leads
> to
> another problem.  The preview_diff is an attribute of the merge proposal
> and is
> exported through the API.
>
> Now there is yet another problem - how to get the API address of the merge
> proposals.  Ideally in HTML5 we could use a data-mp attribute, but we can't
> in
> HTML4 to stay valid - so probably need some revolting javascript hacks.
>

We don't currently have a standard way of doing that, which is a shame.
Until we do, what I've done in a few places is put the link in a hidden <a>
somewhere convenient, and use YUI's DOM methods to grab it later on. Not
elegant, but still better than getting it directly into JS, which involves
another step of serialization of the data with JSON.


> The *big* issue as far as I'm concerned right now, is how to get the
> preview_diff attribute of the merge proposal formatted as HTML in order to
> dump
> it into the pretty overlay?


The API infrastructure makes it quite easy to provide a customized
representation of objects and attributes in alternative formats. You
register an adapter which takes care of rendering the value in the new
format, and when making your call from the JS client you specify the desired
return format using the accept request header (passing
application/xml+xhtml). The only complication is that this is possible for
GET and PATCH, bot not for POST, so if you do the latter, you need an
additional step after the return in which you request the value you need in
xhtml. See the top of lib/lp/bugs/browser/bugtask.py for an example of how
to write such an adapter and link_branch_to_bug in for an example of how
it's called from JS.

Hope this helps.