Chris Petrilli wrote In order to get some new projects kicked off, we are going to be commissioning a ZLDAPMethods product that will provide OO access to the LDAP database world. In order to get this as "right" as possible on the first round, attached you will find, a PDF overview of the architecture
Ok, this has a couple of problems: firstly, it doesn't look like it can handle a result with multiple occurances of the same attr. This is legal (I'm led to believe) and made me rewrite the results section of my LDAP code. Currently I now return a list of { 'name': 'foo', 'value':'bar' } dictionaries. I'm not hugely happy with this, and have been considering a couple of options (see below). secondly, how are ZLDAPEntries tied to the LDAP backend? Will changing an attribute of an Entry object be automagically pushed through? will there be any schema consistency checks? on handling multiple values of the same attr: thought 1: ignore them. thought 2: while thought 1 has advantages (simple implementation :), it's not a good idea. thought 3: return multiples as a list thought 4: means all dtml has to check for a list. damn. thought 5: my new thought (as of earlier this week) was a new option for the query of "handleMultiple". If this is set, the query will return multiples as a list. This is optional, so that someone who doesn't care about it doesn't have to do the work of checking if the value is a list. this bastard problem has stopped me releasing a new version for a while - I'm spending most of the weekend at work tuning some databases (sql server sucks so, so bad - it's even worse than Oracle), so I expect to get a new release done. if you have any patches, please fling them my way. Anthony