[Grok-dev] how should we compute URLs for transient objects?
Kevin Teague
kevin at bud.ca
Thu Sep 6 23:21:51 EDT 2007
>
> Now, seems like a wonderful example of where an Adapter could step in
> and solve our problem! We could smile, and stop worrying that a
> "Person" is not Zope-aware and does not support ILocation, by just
> providing that ability ourselves, through something like:
>
> class PersonLocation(grok.Adapter):
> grok.context(Person) # or "IPerson", if one gets fancy
> grok.provides(ILocation)
> def __init__(self, context):
> self.__parent__ = PersonContainer()
> self.__name__ = str(context.id)
>
This example is close to working, but __parent__ *must* be a
reference to an object in the containment heirarchy.
Elsewhere in your code you might perhaps place a PersonContainer
instance (perhpas in the __init__ method of your grok.Application
object) that looks like this:
class MyGrokApp(grok.Application, grok.Container):
def __init__(self):
self['people'] = PersonContainer()
Then when your PersonLocation adapts your plain python object to the
ILocation interface, you would write:
class PersonLocation(grok.Adapter):
grok.context(Person)
grok.provides(ILocation)
def __init__(self, context):
self.__parent__ = grok.getSite()['people'] # This is an instance
of PersonContainer(), whose __parent__ is a reference to your Grok
Application object
self.__name__ = str(context.id)
If you look at the interface for ILocation in zope/location/
interfaces.py you will see:
class ILocation(Interface):
"""Objects that have a structural location"""
__parent__ = Attribute("The parent in the location hierarchy")
__name__ = schema.TextLine(
title=u"The name within the parent",
description=u"Traverse the parent with this name to get the
object.",
required=False,
default=None)
When your PersonLocation adapter declares that it is adapting IPerson
to ILocation, then your adapter is obligated to fulfill the ILocation
interface, so it is up to that adapter to determine how __parent__
becomes a reference to an obejct within the containment heirarchy.
More information about the Grok-dev
mailing list