[ZPatterns] a LDAP-AttributeProvider again

[Ulrich Eck]

Hi Philip,

thanks for your answer.

the point is, that we allways need to repeat the steps of creating SQL/LDAP-
Queries and Skinscript Methods for our Specialists/Racks ..

This work cries for an tool that automates it .. it is usually a 1:1 mapping
of attributes.
I allready developed a small tool that allows me to create the DataSkin
Classes
from SQL-Tables .. but the work to fill the attributes is still made by
hand.

> Ty and I originally intended to make specialized kinds of racks such as
SQL
> racks, LDAP racks, etc., or perhaps specialized attribute providers.  We
> ran into the same types of design questions as you did, however, which led
> to the breakthrough of "generic" providers and ultimately SkinScript.
What
> we do these days is have library objects which supply functions we need to
> use from SkinScript.  Typically this is as a folder containing SQL
methods,
> external methods, etc. representing the database.  We then call these
> methods from SkinScript.

How much overhead is created through the use of skinscripts .. or better,
how can I speed up a combination of
Specialist/Rack/Skinscript/SQL-LDAP-Methods ??


>
> In the case of LDAP, we usually use external methods which operate upon a
> ZLDAPConnection (?) object to do the things we need.  We have not found
> enough useful similarities between our varied uses of LDAP to support
> creation of a general-purpose LDAP tool.

I do this as we'll .. I hoped that it could save some work and probably
speed up
the whole app when I write an Attribute-Provider ..

>
> In other words, our experience has tended to suggest that custom provider
> objects written in Python aren't all that useful in the general case.
They
> only seem to make sense as a one-off to do something really unusual.
>
>

hmm .. thinking about stopping half way ..
but don't have a better solution ..

do you have a hint ??

thanks

Ulrich Eck