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).
The idea, though not explicitely stated is that it would be a list, with one item if there's only one occurance, etc...
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?
ZLDAPEntries (blank ones anyway) are instantiated by the Connector. Changing attributes will be commited by the transaction manager, as with all other changes. As for schema check, no, not today ;-) One day.
thought 3: return multiples as a list
Actually, it will be ALWAYS a list, even if a list of one item. THerefore you can always say <!--#in-->
thought 4: means all dtml has to check for a list. damn.
Nope, it's just always 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.
Well, we're having someone else work on this, this is just a view on how the solution should wokr. Thanks! Chris -- | Christopher Petrilli Digital Creations | petrilli@digicool.com http://www.digicool.com