[RCD] structural change proposal and LDAP issues
Daniel Mealha Cabrita
dancab at utfpr.edu.br
Fri Oct 17 22:06:13 CEST 2008
There are some changes I find appropriate to do regarding the classes, which
are stored in the include directory.
The motivation is to improve the modularization _and_ to avoid flooding the
include directory with dozens of small files.
I've got features which use LDAP (yet structurally extensible to additional
mechanisms) and I need a more basic and standard LDAP class for that.
1. - I'm currently splitting the rcube_ldap class in two:
1.1 One specific to the addressbook feature (with the very same behavior as
before), with inheritance from the classe described in 1.2.
1.2 - Another one being a superclass, for generic ldap access.
>From what I could understand on the philosophy of the classes used in RC,
although we may have several classes in the same file, only one is supposed
to be externally accessible (and it seems that the filename itself is used to
determine which one).
Once we start modularizing things (like allowing a different mechanism for
external addressbooks, instead of only LDAP as currently it is), if we follow
this logic we may end with too many files.
2. Now about what I am proposing.
I'll give an example which, hopefully, will clarify what I have in mind:
2.1 - To create a new rcube_ldap.php file with a generic LDAP class only (yes,
addressbook code would have to the moved to another place, or we could call
the former rcube_ldap_generic.php to simplify the transition).
2.2 - A rcube_XYZ.php file providing a specific feature (addressbook, user
identity etc). In that same file there are additional classes providing
services according the mechanism chosen (LDAP etc). This file would have the
XYZ-specific code when dealing with LDAP (through the generic LDAP class) and
any other mechanism which could be added in the future.
It _seems_ to me that the current philosophy expects the item 2.2 to be broken
in two or more pieces, from what I see no practical benefit (and it would add
lots of files once we start to support extra mechanisms).
If my understanding is incorrect on this, please someone tell me so.
Daniel Mealha Cabrita
Divisao de Suporte Tecnico
AINFO / Reitoria / UTFPR
List info: http://lists.roundcube.net/dev/
More information about the Dev