On 07/12/2010 06:23 PM, Sebastian Benthall wrote:
> I have double checked with Galen and more than two contacts can be
> attached, the schema specifies those two contacts as a minimum. The
> API I implemented allows accessing the poc and metadata_author
objects
> as layer properties so the use is not complicated by having the more
> liberal many-to-many relationship and we get the benefit of
being able
> to use the layer/contact/role/permission architecture to allow some
> level of per-object permissions based on the contact role.
These shortcut methods will error if, for whatever reason a layer, has
more than one poc or metadata_author. It doesn't seem unreasonable to
expect multiple of either, so if we are going this way then we should
probably ditch the properties and make developers deal with the idea
that there might be more than one party playing any particular
role for
any particular layer. Otherwise, we should add a uniqueness
constraint
on ContactRole on (layer, role).
Is there a way to write the shortcut method in a way that it doesn't
fail when there are multiple authors? Maybe return them all in a
collection, or else return just one of them?
In fact we can return anything from a property's getter that we can from
a full-fledged method. At this point though, we are talking about the
difference between:
layer.contact_set.find(role=AUTHOR)
and
layer.poc_author
I'd prefer to just expose the already polished Django ORM methods rather
than try to dumb things down any further.
More explicitly, I am:
-0 on having a property that returns a collection
-1 on having a property that returns some arbitrary single element of
the collection
I am concerned about some related user interface recommendations
according to which in certain places (on the Data grid, for example).
According to these designs, these rows have an "Author" or "Owner"
column that has a singular name in it. So far, nobody has specified
the logic for choosing one of many points of contact or authors as the
primary owner of a resource. What I'm trying to figure out is whether
this is a flaw in our design, or whether there is some kind of
appropriate logic for determining this. Maybe a hierarchy of the
"roles" used in the metadata could be used to select the person who is
_most_ responsible for the resource. This could easily be an
orthogonal point, but it could also be a point of inspiration.
The UI design discussion should be separate from the API design discussion.
<snip cause="already in the repo!">bit about using a fixture for
roles</snip>
Everything else looks good to me too[1]. Let's figure out how we want
to handle contacts before merging this into master though.
[1] Well, we might have some issues with caching logged-in-ness
across
all GeoServer/GeoNetwork access later, but we can deal with that
when/if
it becomes a problem. It's not a new issue anyway.
--
David Winslow
OpenGeo - http://opengeo.org/
--
Sebastian Benthall
OpenGeo - http://opengeo.org
