Re: Suggested Schema changes

[Graham B. <gb...@po...>]

On Mon, Jan 07, 2002 at 02:36:34PM +0000, Graham Barr wrote:
> I think the root of the problems with Schema.pm is that ->item is used as
> an accessor for all types, and the the internal structures are wrong.
> Also The methods return names or OIDs, which them must be passed to item
> to retrieve.
> 
> Here is what I propose
> 
> Internals
> 
>   $schema = {
>     # OID will be a hashref mapping the OID (number or un-altered name) to the hash
>     # which holds the elements data
>     oid => { ... },
> 
>     # at will be a hash mapping the lower case version of the names and aliases
>     # of attributes to the hash for the element
>     at  => { ... },
> 
>     # Same as at for all other types
>     etc..
>   };
> 
> The API then needs to change.
> 
> We do away with ->item and make is_attribute return the element hash. This way we know
> that the given name/OID should be an attribute or syntaxrule or whatever. If we
> really want to hide the contents of the element hash, then we should just bless it
> into another package which contains accessor methods.
> 
> So now instead of
> 
>   $href = $schema->item('userName');
>   $syn  = $schema->item('userName','syntax');
> 
> you will do
> 
>   $href = $schema->is_attribute('userName');
>   $syn  = $schema->is_attribute('userName')->{syntax};
> 
> However, I dont really like the is_ prefix on these methods, but dropping that makes
> the name too close to existing methods (attributes) which return all attributes,
> so if anyone has any ideas (or they do not think it will be a problem), then fire away.

In fact it seems that what I was trying to describe is similar to the Java API.

For those not familiar with it, see

http://docs.iplanet.com/docs/manuals/dirsdk/jsdk41/Reference/index.html

And look at the LDAPSchema and LDAPSchemaElement class definitions.

Graham.