hi there,
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. Comments? Suggestions? -- Daniel Mealha Cabrita Divisao de Suporte Tecnico AINFO / Reitoria / UTFPR http://www.utfpr.edu.br _______________________________________________ List info: http://lists.roundcube.net/dev/
