On Fri, May 30, 2008 at 03:49:46PM +0200, Martijn Faassen wrote:
Brian Sutherland wrote: [snip]
I'll note that there is a difference between where things are published (IAbsoluteURL) and where you should go to find their canonical representation.
One problem I've found with using IAbsoluteURL and location proxies is getting the object directly from the database. In this situation you don't have an LocationProxy and IAbsoluteURL doesn't work.
It's pretty nasty when IAbsoluteURL sometimes works and sometimes doesn't for what essentially is the same object.
Agreed, we should ideally always get our objects from the db already properly wrapped in a location proxy (or providing ILocation directly). I think we can do this with containers based on relations; those containers are under our control after all.
I've just decided to jettison IAbsoluteURL and make a new interface ICanonicalURL. The adapters for ICanonicalURL are available anywhere without specially wrapping the object in a location proxy.
Is a direct one on one relation possible in SQLAlchemy? I.e. an object foo that has an attribute 'bar' that is another ORM-ed object. If so we also need to take care of that case somehow.
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: /adresses/address1 /people/person1/address1 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.
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.
Regards,
Martijn
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
-- Brian Sutherland