[dev] Re: Re: Adding contact to nag task [Patch]

[Hans Lellelid]

>This requires initimate knowledge of each other capabilities and/or the
>actual source code. It is good programming practice to avoid this as much
>as possible. Hence the idea of a registry and API's. If we can create a
>scheme that allows communication about these capabilities without knowing
>the inner workings you could use different versions of applications or
>different applications that could cooperate as long as they both obey to
>the rules set by the registry/API's.
>

Right, agreed:  we need a scheme :-)  Something like registry ...?  part 
of the registry?  

To me it seems like these are the basic requirements:

1- An app needs a way to expose one or more entities

At first it is probably not important to expose the actual properties of 
entities -- that might be useful at a later point, however.  At first a 
simple property of the registry entry for the app may suffice:
    'expose_content' => ('contact', 'directory'), // now other apps know 
that Turba handles 'contact' and 'directory' type content.

Question -- would that mean that instead of 'app' in the hored_crossref 
table it would make more sense to have 'content'?  (i.e. If one 
application can register different types of content)

2- Needs to be a UI for relating content.

E.g. if I'm in Gollem, I need to be able to see the list of eligible 
users to add as "authors" when I create a new document.  Maybe the 
solution here is to create a new Horde_Form element type (e.g. 
"relationship") which takes the target app / content and 
relationshp_type as parameters.   The app that is exposing content would 
need to implement a function in api.php that would return an array of 
eligible values for the specified content type & relationship:

function _turba_relate($params)
{
    // expect $params['content'] and $params['relationship_type']
    // based on those params, return valid results
}

Of course if I didn't want to use Horde_Form, I could build my own form 
and build a multi-select list based on the array that will be returned 
by $registry->call('contacts/relate', array('content'=>'contact', 
'relationship_type'=>'doc_author'));

3 - Needs to be a system for storing the relationships

A new class to handle this?

4- Needs to be an API for accessing related content.

Here's where the link idea would fit in, I assume (at least initially). 
 When displaying a Document in Gollem I would execute a method of this 
new (?) class that will handle relationships:

    $RelationshipManager->getRelated($curr_id = $curr_file_uid, 
$rel_content='contact',  $rel_type='doc_author');

What would that return?  -- a list of UIDs?  How would links be built? 
 Maybe another required api.php function?

function _turba_related_link($params)
{
    // expect $parms['content'] and $params['uid']
   // return a link to a page that will display the content contained in UID
}

What do you think about any of this?

:-)  Hans
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3299 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.horde.org/archives/dev/attachments/20030124/834b65e0/smime.bin