Alex Karasulu wrote:
On Wed, Jul 22, 2009 at 7:27 PM, Emmanuel Lecharny <[email protected]>wrote:
Hi guys,
following one thread started more than a month ago, I would like to get
your opinion about the DeleteRequest implementation.
We currently have the following methods (Thanks to Kiran who implemented
them) :
delete( LdapDN )
delete( LdapDN, boolean deleteChildren )
delete( LdapDN, DeleteListener )
delete( LdapDN, boolean deleteChildren, DeleteListener )
delete( DeleteRequest );
delete( DeleteRequest, DeleteListener );
Why not have a delete() and a deleteTree() method and do away with the
deleteChildren parameter? The parameter permutes the number of method
overloads and I think it's just more clear to use another method name all
together due to the nature of the operation. Here's what this looks like:
delete( LdapDN )
deleteTree( LdapDN )
delete( LdapDN, DeleteListener )
deleteTree( LdapDN, DeleteListener )
That's an idea. We should also add some methods in order to allow a user
to pass a String instead of a DN :
delete( String )
deleteTree( String )
delete( String, DeleteListener )
deleteTree( String,DeleteListener )
I don't see the point to having delete take the DeleteRequest. I guess this
is for convenience in the codec? If so then might this not be best a
package friendly method overload?
It's just convenient if you have to add some controls.
If we exclude the last parameter, used only for asynchronous requests, we
have some other options :
- delete( String ) // instead of a LdapDN
- the boolean (deleteChildren) is associated with a control, we can pass it
to the DeleteRequest Object.
is the following list of methods enough then ? :
delete( String [, DeleteListener] )
delete( LdapDN [, DeleteListener] )
delete( DeleteRequest [, DeleteListener] )
Hmmm if I want to delete a tree of entries then I will have no choice but to
wrap my LdapDN in a DeleteRequest which I must now create, just to add the
control to delete the subtree.
Yes, true. IMO, your proposal (deleteTree) is probably better.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
