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
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
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
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 - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -