On 6/12/08, Stefan Gehrig <[EMAIL PROTECTED]> wrote: > >-----Ursprüngliche Nachricht----- > >Von: Michael B Allen [mailto:[EMAIL PROTECTED] > >Gesendet: Mittwoch, 11. Juni 2008 20:43 > >An: Stefan Gehrig > >Cc: Zend Framework General > >Betreff: Re: [fw-general] Zend_Ldap_Ext ready for community review > > > >On 6/11/08, Stefan Gehrig <[EMAIL PROTECTED]> wrote: > >> Hi everyone, > >> > >> I'm happy to announce that Zend_Ldap_Ext > >> > (http://framework.zend.com/wiki/display/ZFPROP/Zend_Ldap_Ext+Proposal+-+Stef > >> an+Gehrig) is ready for community review. Actually the proposal was > ready > >> for review some time ago but I missed informing the mailing list (it's > the > >> second one of my first two proposals ;-). > >> The source is available from > >> http://svn2.assembla.com/svn/zf-proposals/Zend_Ldap_Ext/trunk. > >> > >> Zend_Ldap_Ext extends existing Zend_Ldap with methods to search the > >> directory and with core CRUD-methods. This can be considered a object > >> oriented wrapper around the most common ext/ldap functions. It also > provides > >> helper functions to deal with LDAP entry creation and password setting. > >> Furthermore the proposal provides methods to traverse a LDAP tree in an > >> object oriented way. > >> The source cannot be considered feature complete by now but all of the > most > >> important stuff is currently working. > >> > >> Please take a look and let us know what you think. > > > >What functional benifit does this API have over the builtin PHP LDAP API? > > > First of all I think Zend Framework should provide a first class > object-oriented approach to a LDAP directory ... > Perhaps we can join forces on this proposal as you certainly already have a > lot of experience (a lot more than myself I think) in the LDAP and ext/ldap > business.
Hi Stefan, Unfortunately I don't have a lot of time so I'm going to be blunt which I know is horribly rude and I apologize in advance for it but this is the best I can do I'm afraid. OOP is desirable when you need polymorphic behavior. And LDAP use-cases have need for polymorphic behavior. Unfortunately I don't think you have touched on those use cases and therefore much of the OOP sugar you created is not warranted IMO. One thing almost everyone is going to want to do is to retrieve information about the authenticated user. This is a good opportunity for OOP because you can have an Account class that defines how to query, create, get groups, set passwords etc and then allow different backends to extend that class (or implement that interface). Right now you have a "Helper" class for setting passwords. Whenever I see "Helper" a big red flag pops up that reads "we don't where to put this so we dumped it into this amorphic 'helper' thingy". Most people don't know much about LDAP, don't want to know, and fortunately, given the use-cases, they probably don't need to know. Your API is *way* too complicated. You claim the existing PHP LDAP API "cries for an easy to use object-oriented approach" but that's not technically true. Yes, PHP's builtin API is absolutely horrible but you could create a set of simple functions that would be just as effective as your OOP API for 90% of the use-cases. In fact, your API actually *hides* functionality (e.g. how do you use a control to sort results on the server?). AFAICT you must read the entire dataset into an array of arrays. That's a LOT of little pieces of memory that the heap needs to track. I think you should greatly strip down the API. Keep it really simple. For now anyway. It's very easy to add to the API later and very painful to remove something. In fact, I'm not convinced that there needs to be much of an "LDAP API" at all. I think perhaps you should do a Zend_Ldap_Account class first. Maybe you would need one Zend_Ldap method for searching (that uses a callback so that you can enumerate and filter on large result sets). And anticipate that there may one day be a Zend_Account_Interface that other backends such as Zend_Db can implement. Another thing that I'd like to see is what I call "attribute intelligence" so that when you get an array of account data selected elements are automatically converted from multi-valued binary to the appropriate type. So you would need to be able to specify "attribute definitions" that say givenName is a single valued string and have it automatically converted to ISO-8859-1 if necessary. Or lastLogon is automatically converted from nanos since 1601 to a double representing a time which if cast to an int is ideal for use with date(). Sorry to pooh-pooh your proposal but this is just one man's opinion. And it's probably the last you'll hear from me on the topic because I really need to get back to work now ... Mike -- Michael B Allen PHP Active Directory SPNEGO SSO http://www.ioplex.com/
