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.
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, Person, inetAdmin, organizationalPerson
which clearly isn't correct. I figure that the Schema class probably
contains enough information in this to put things into the proper order
that the hierarchy implies.
( course, multiple inheritance makes things a little tricky)
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.
For instance, if we don't know how to render a node as an 'Person',
well, we could render it as an 'organizationalPerson' instead, etc.
Does it make sense to add a convenience wrapper that handles this logic
for us (and perhaps caches the schema conveniently to avoid having to
pull it down multiple times)?
Thanks,
-Philip

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, Person, inetAdmin,
>organizationalPerson
>>
>>
>which clearly isn't correct.
>
Yes, it is correct. See above.

, 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.
>>
>( 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.

composition and class hierarchy has absolutely no relation to
DIT structure and hierarchy.

so I'm not sure what you're saying. Is the Schema info not
the proper
place then to assemble the class hierarchy?
-Philip

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:

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).

composition and class hierarchy has absolutely no relation to
DIT structure and hierarchy.

>>
>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 Person's with a couple of additional fields
thrown in this extra layer of subclassing isn't important to me.

But not everyone is an Person. 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