Brian Sutherland wrote:
This was a problem with sqlos containers as well. It gets nasty quickly.
Say you have 2 containers, of people and addresses. Also people can have
an address.

So you can get to an address in 2 different ways:


What should the url for address1 be? I'd vote for /adresses/address1.
But due to the LocationProxy, you'll get different results for different
IAbsoluteURL calls depending on how you traversed to the object.

I've seen this complaint coming from quite a few people a number of times, so this needs some thinking about.

One interesting observation is that if you do this in the ZODB you'd get the exact same problem, and then people use things like zc.shortcut to get around it. So, in the ZODB, we typically don't give the same object two URLs.

I guess one difference here is that it seems more common in the RDB scenario to have multiple ways to reach the same object, and even if you just publish one, you can get to the actual object in multiple ways.

In this case it'd be nice to convince IAbsoluteURL to somehow know which URL option is the best, or alternatively, give the object somehow its 'canonical' location (parent, etc) even if you don't get it that way.

This is the "it should work like ZODB-backed objects" pattern I've been trying to follow as a design guideline. Since for contained objects I can always get the URL, it should work that way for RDB-based contained objects too.

I'm not sure it's worthwhile following the "it should work like
ZODB-backed objects" pattern.

The nice property of ZODB-backed objects is that they're just plain Python objects, and it's also familiar to me, so that's why I look for special reasons to diverge from it.



Zope-Dev maillist  -
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to