Mike Jackson wrote:
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?
Somewhat... although we have local attributes and subclasses which I
omitted from my example.
We also have several different LDAP spaces (sigh... that could have been
planned a lot better) where disjoint information about a particular user
is kept, and it needs to be groveled out of each of them (at least until we
achieve some reunification... if that ever happens).
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...
Because users can have multiple inheritance from more than one objectClass,
and some objectClasses I don't understand (so I have to start at the
subclass
and start peeling off layers until I get to a superclass that makes
sense to me).
Not all of the subclasses are worth knowing how to render.
Some of them are just inetOrgPerson's with a couple of additional fields
thrown in... this extra layer of subclassing isn't important to me.
But not everyone is an inetOrgPerson. Some are "contacts", and have to
be rendered differently. They also don't need to be groveled for in
parallel
LDAP spaces, since they only exist locally.
-Philip
