directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <elecha...@apache.org>
Subject Re: Some more thoughts about the Dn class
Date Wed, 16 Feb 2011 23:02:26 GMT
On 2/16/11 9:29 PM, Alex Karasulu wrote:
> On Wed, Feb 16, 2011 at 10:02 PM, Alex Karasulu<akarasulu@apache.org>  wrote:
>> On Wed, Feb 16, 2011 at 4:50 PM, Emmanuel Lecharny<elecharny@gmail.com>  wrote:
>>> Hi,
>>>
>>> we have had some convo about the Dn methods last night. Here are some of the
things we discussed and came with :
>>>
>>> o the getPrefix(N)/getSuffix(N) are cumbersome, and not easy to manipulate. The
main issue is that they depend on the RDN order, which is the opposite as what people are
used to manipulate. Everytime you have to get a prefix from a Dn, you always wonder what the
position should be, and if it's 0 based or 1 based...
>>>
>>> We propose to replace those methods by getParent(Dn) and getDescendant(Dn). Let
me give you an example :
>>>
>>> // A DN
>>> Dn dn = new Dn( "cn=test,ou=server,ou=directory,dc=apache,dc=org" );
>>>
>>> // Get the right part (equivalent to getprefix( 2 ) )
>>> Dn parent = dn.getParent( "cn=test,ou=server,ou=directory" ); // returns "dc=apache,dc=org"
>>>
>>> // Get the left part (equivalent to getSuffix( 3 ))
>>> Dn descendant = dn.getDescendant( "ou=directory,dc=apache,dc=org" ); // returns
"cn=test,ou=server"
>>>
>>> o The Add method is a bit annoying to remove, because first, the JNDI Name interface
has such a method, and people are used to it, second removing it means we have to add some
more constructors line Dn( Dn, Rdn... ). I agree that someone doing something like :
>>>
>>> Dn dn = new Dn( "dc=apache,dc=org" );
>>> dn.add( "ou=directory" );
>>>
>>> will expect that the dn is now "ou=directory,dc=apache,dc=org", when it's unchanged.
>>>
>>> This is really troublesome... What about rename it concatenate() ?
>>>
>>> Thoughts ?
>> Sounds good. But how about this:
>>
>> // not showing full Rdn but an index value representing the actual
>> rdns in the dn for pos clarity
>> Dn dn = new Dn( “9, 8, 7, 6, 5, 4, 3, 2, 1, 0” );
>>
>> dn.getAncestorDn( “9, 8, 7, 6” );
>>
>> =>  “5, 4, 3, 2, 1, 0”
>>
>> dn.getAncestorDn( 6 );
>>
>> =>  “5, 4, 3, 2, 1, 0”
>>
>> dn.getDnToAncestor( “1, 0” );
>>
>> =>  “9, 8, 7, 6, 5, 4, 3, 2”
>>
>> dn.getDnToAncestor( 2 );
>>
>> =>  “9, 8, 7, 6, 5, 4, 3, 2”
>>
>> Dn namingContext = “1, 0”;
>>
>> // all same below
>> Dn dnAfterNamingContext = dn.getDnToAncestor( "1, 0" );
>> Dn dnAfterNamingContext = dn.getDnToAncestor( namingContext );
>> Dn dnAfterNamingContext = dn.getDnToAncestor( namingContext.size() );
>> Dn dnAfterNamingContext = dn.getDnToAncestor( namingContext.toString() );
>>
>> dnAfterNamingContext ===>  “9, 8, 7, 6, 5, 4, 3, 2”
>>
>> Overloads should be provided for Dn, String and int.
>>
> Maybe some convenience methods like:
>
> dn.isAncestor( namingContext );
> namingContext.isDescendant( dn );
We may add such methods, sure. Again, I'd rather use isParent( Dn ). 
IsDescendant( Dn ) fits me.

> dn.isRelated( namingContext ); =>  i.e. two DNs in different
> namingContexts will not be related
dn.hasParent( Dn ) sounds again simpler. Every time you peek a different 
name for the same element (ancestor, related, ...), you confuse the user.
> namingContext.isParent( dn );
> dn.isChild( namingContext );
isChild is not good, as the child is supposed to be the RDN only. 
isDescendant() and hasDescendant() is ok IMO, unless we decide that 
child fits better (dn.getChild( Dn ), dn.isChild( dn ), dn.hasChild( dn ))

I'd like to get the API as simple as possible, avoiding using different 
terminology to describe the same cocept, plus to keep it simple to 
remember (and here, xxxdescendant() is problematic, because it's not 
easy to type without doing a mistake. I'd rather use 'child', if we 
don't mind about the Rdn relation)

-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com


Mime
View raw message