Mike Jackson wrote:
Philip Prindeville wrote:
Hi.

I'm dealing with an LDAP server that answers queries with data
that has the objectClass attribute in no particular order, i.e. and
had a question for you all.

objectClass is a multivalued attribute, and RFC 2251 says that the return order of multivalued attributes is not guaranteed.


Is there an easy way to get the values of:

$mesg->entry(0)->get_value('objectClass')

into hierarchical sorted value?  I'm seeing returned values like:

iplanet-am-user-service, iplanet-am-managed-person, top, iPlanetPreferences, person, inetuser, inetOrgPerson, inetAdmin, organizationalPerson


which clearly isn't correct.

Yes, it is correct. See above.

Ok, I'll rephrase. It's not in hierarchical ordering, which is what we desire.


contains enough information in this to put things into the proper order
that the hierarchy implies.

(Of course, multiple inheritance makes things a little tricky...)
> I figure that the Schema class probably

There is the superclass() method, which will return the immediate parent object class of a given object class.

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.



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?

-Philip


Reply via email to