Philip Prindeville wrote:
Right, but that's a fair amount of work. I'm wondering if there might be a
more compact representation of the objectclass stacking hierarchy that
could lend itself to a quick, efficient convenience method for reordering
the objectclass array, such as:
my %objectClassIndicies = (
'top' => 0,
'person' => 1,
'organizationalPerson' => 2,
...
);
then you could just do an array sort based on:
sub ocReorder
{
$objectClassIndicies{$a} <=> $objectClassIndicies{$b};
}
or better yet, have the convenience function do it for you.
Reason is we want to be able to look at an object with a browser, and
go up the (objectClass) tree until we find a node on the tree that
(mostly)
knows how to render this object.
Please define "render".
Well, in this case, it gets printed out in HTML as part of an online
directory
CGI, with certain fields converted into links, etc. For instance, the
person's
email address gets rendered as:
<a href=mailto:@mail@>@displayName@</a>
and becomes clickable. Likewise for their pager number, their phone
number, their network share, etc.
Have a look at a program I created for emailman.com:
http://www.emailman.com/ldap/search/ldapsearch.pl
Try some searches and examine the output. Is this what you are trying to do?
Object composition and class hierarchy has absolutely no relation to
DIT structure and hierarchy.
Ok... so... I'm not sure what you're saying. Is the Schema info not
the proper
place then to assemble the class hierarchy?
Yes, it's the place. I just misunderstood what you were trying to say
initially.
However, I still don't understand your use case. Why do you need to
"know how to render an object"? Why do you need to understand a class
hierarchy, unless you are modifying subclassed objects? What is to know,
and how does it related to classing? Just render objects from the
attributes and values which are recieved. Write subs to wrap certain
named attribute's values with urls, etc...
--
http://www.netauth.com - LDAP Directory Consulting
