[dev] Re: Re: Adding contact to nag task [Patch]
Jeroen Huinink
j.huinink at wanadoo.nl
Mon Jan 27 11:06:16 PST 2003
"Chuck Hagenbuch" <chuck at horde.org> wrote:
> Quoting Jeroen Huinink <j.huinink at wanadoo.nl>:
>
> > Using the Turba registry I can express the fact that you can link into
it
> > with function like those I already mentioned. This is how we add
"authors"
> > to Gollem documents. How can I express through the Gollem registry that
it
> > is usefull for Turba to have an "Authored documents" button somewhere?
> > I can probably come up with something or look into the RDF, xlink or
> > similar specs and see how they handle this, but it would be usefull if
> > somebody with knowledge or ideas in this area would put in his
> > suggestions.
>
> This is exactly what the registry system is intended to provide. In this
> case, it may be useful to have an overall method (implemented by Horde
> itself), such as:
>
> listRelationships($type)
>
> ... which lists all relationships of $type, where $type could be: contact,
> project, task, etc. So Turba would call listRelationships('contact') and
get
> back that Gollem has a listFilesByContact() method (or some such). It
might
> also get back that Hermes has a listClients() method, also linked to
Turba,
> and so be able to display links for both of those.
>
> That make sense?
Sort of. Are you thinking about specifiying relationships through API
functions or do you want a relationship setup next to the current API setup.
E.g. there is this _services array. Do we want a _relationsships array to
define relationships?
In another subthread we already discussed that we could have more than one
relationship between different providers. E.g. an "author" and "editor"
relationship between Gollem and Turba and a "client" and "employee"
relationship between Hermes and Turba.
We could use the _relationsships array to specify that a certain
relationship is the reverse relationship of another and therefore only allow
reverse references if explicitly allowed. E.g.
In nag:
_relationship["contact"] = array (
provider = "contacts",
... // probably some other elements to go here as well.
description = _("Contact"),
);
_relationship["related_contacts"] = array(
reverse = "tasks/contact",
description = _("Related tasks")
);
In gollem:
_relationship["author"] = array (
provider = "contacts",
... // probably some other elements to go here as well.
description = _("Author"),
);
_relationship["authored_documents"] = array(
reverse = "documents/author", // I noticed that gollem doesn't "provide"
anything yet so I invented "documents" for the purpose of this example.
description = _("Related tasks")
);
_relationship["editor"] = array (
provider = "contacts",
... // probably some other elements to go here as well.
description = _("Editor"),
);
.....
We could also "collapse" this e.g.
_relationship["contact"] = array (
provider = "contacts",
... // probably some other elements to go here as well.
description = _("Contact"),
reverse = true,
reverse_description = _("Related contacts")
);
But I think that is for the programmer to decide.
[Explanation about 'provides' property removed]
I already got this, thanx.
> So the whole thing is pretty darn flexible, if I do say so myself.
I haven't found anything to disagree with this statement. (Yet ;-)) An
excellent piece of work. I hope to be of help.
Regards,
Jeroen
More information about the dev
mailing list