[turba] Mutiple ldap database fields

[Chuck Hagenbuch]

Quoting lenneis at wu-wien.ac.at:

>> Quoting lenneis at wu-wien.ac.at:
>>> I have looked at the latest version of the ldap driver for Turba in
>>> CVS and have noticed that there is no support for maintaining multi
>>> valued fields in an ldap database. I have modified my local install of
>>> Turba (h3-2.3.1) to support multi valued fields. Is that something of
>>> general interest and if yes, should I send a patch?
>
>> Sure, send it along. Hard to say if it's going to be accepted without
>> seeing how the patch works, of course.
>
> I was about to go into that, since I am not very familiar with Horde
> internals. So this is to solicit feedback and possibly/probably ideas
> how to make it better. This is how I have done it:
>
> - There is an additional entry in the ldap 'params' array in
>   sources.php called 'ldap_attribute_params', that lists the fields we want
>   to have multiple values. It looks like this, for example:
>
>   'ldap_attribute_params' => array('mail' => array('multi_value' =>
> true), 'homephone' => array('multi_value' => true, 'separator' =>
> ','))
>
>   If the LDAP driver sees a fields (key) in that array that points to
>   an array with an entry 'multi_value'=> true, on reading a multi
>   valued attribute the individual entries are concatanated using the
>   value for 'separator' in that array if set (like in 'homephone'
>   above) or it uses the default from the parameter
>   'multiple_entry_separator' (like in 'mail' above) that has been
>   present in the driver for a while already. This behaviour is
>   unchanged form the present one except for the possibility to
>   configure the string that is used to concatanate values.
>
> - On writing a field, the reverse operation is performed, we split the
>   field using the separator string and write the individual entries as
>   a multi valued field.
>
> 'ldap_attribute_params' could be used for more ldap specific stuff, we
> could for instance make the ldap syntax check ('checksyntax' set to
> true in params right now) configurable on a field by field basis.
>
> The main thing I am not sure about, does the above play nicely with
> the Horde form API? Of couse any other suggestions are welcome as well.

 From a design/organization perspective, all of that sounds reasonable  
to me, along with the idea of making checksyntax configurable through  
the same mechanism.

-chuck