On 2/16/11 9:29 PM, Alex Karasulu wrote:
On Wed, Feb 16, 2011 at 10:02 PM, Alex Karasulu<akaras...@apache.org>  wrote:
On Wed, Feb 16, 2011 at 4:50 PM, Emmanuel Lecharny<elecha...@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

Reply via email to