Add web_link property to resources

yes, having such a method for recources would be really cool, I'm using something similiar to
   url = self_url.replace("api.", "").replace("beta/", "")
very often.

Isn't this rather a lazr.restful feature request?

Since the rule to derive the web url from the resource URL are fixed, it makes sense to implement this on the client side in a convenient method instead of bloating the representation.

Is it really guaranteed this relationship will always be the same? If not, maybe it should be in the server.

Anyhow, for those using Markus's code, note that the thing you start from is typically 'self_link' not 'self_url'.

For those copy-and-pasting, the change will be somewhat safer as

launchpad_object.self_link.replace('api.', '', 1).replace('/beta/', '/', 1)

This is about to change, if I ever manage to land the multi-version branch. The self_link will no longer start with '/api/beta/', but instead will start with '/api/devel/'.

On 17 February 2010 23:25, Leonard Richardson
<email address hidden> wrote:
> This is about to change, if I ever manage to land the multi-version
> branch. The self_link will no longer start with '/api/beta/', but
> instead will start with '/api/devel/'.

That sounds like a really good reason to put the .web_url code into
Launchpadlib, because that change will break most launchpad client
programs.

Sorry, I thought we were talking only about Launchpad Ajax here. We're changing the Launchpad web site so that instead of making requests to /beta/ it makes requests to /devel/, which of course makes the URLs have /devel/ in them. If you've got a launchpadlib program you can continue to make requests to /beta/ and the URLs will continue to have /beta/ in them.

However, I agree that the .web_url should be provided as part of the representation.

Should it really be part of the representation? Why not implement it in the client-side API.

On Thu, 2010-02-18 at 15:36 +0000, Francis J. Lacoste wrote:
> Should it really be part of the representation? Why not implement it in
> the client-side API.

Because the implementation changes. If we had already implemented it in
the client-side API, our implementation would become incomplete when I
land the multi-version branch. Implementing URL generation on the server
lets us change it however we want. Especially because the trend is for
the implementation to become more complex over time.

I don't believe that this is an incredibly powerful argument here,
because it's unlikely this implementation will _keep_ changing or become
_very_ complex, but this is why we send links in general instead of
defining rules and having the clients implement those rules.

See https://bugs.edge.launchpad.net/bzr/+bug/619412 for another request

Fixed in stable r12324 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/12324>.

I posted http://blog.launchpad.net/cool-new-stuff/new-web_link-property please edit/comment to taste.

This is now deployed, but I can't see it directly in launchpadlib without going through the WADL resource.

Fwiw, rm -r ~/.launchpadlib/*/cache got it working for me.

Huh, indeed. Perhaps there was some WADL cached inappropriately.

The WADL will be cached for a week. I filed bug 714621 to reevaluate our caching strategy in light of our new continuous deployment.

I had cache problems with this too, much more than a week after this was landed. See bug 752107.

I am still seeing this issue in current oneiric, using launchpadlib via requestsync.

Thanks.

Dave, can you please post some small example code?