[Jxplorer-users] Question about deletion in JXPLORER

[Chris Betts]

Hi Wendy,

I'm not sure I understand - how can you delete an entry without
deleting the children first?

When deleting, JXplorer does a depth-first tree delete of all
the children - I'm not sure how else to do it? Is the problem that
you are using an LDAP interface to something that isn't really a
directory?

cheers,

- Chris

Hi Chris,
We are using JXPlorer as a LDAP client, and find that it's
impossible to delete an entry without checking the children, as
before when we were using LDAP Browser, there's an option that
'with children' when deleting an entry. The reason we want this
option is that when deleting an entry, our framework would delete
all the children, but when deleting the child only, we would do
certain check and if that check failed the deletion would failed.
With JXPlorer, we couldn't delete an entry as the children would be
always deleted first and some deletion would failed.
Thanks for your reply in advance.
Best Regards,
Wendy

...

[Chris Betts]

Hi Wendy,

thanks for explaining!

the problem is that this would be a very non-standard feature...
and also, does it apply to *every* entry in your directory? Or are
there other parts of your DIT where you would still want a normal
tree delete?

A more robust solution might be to modify your code to ignore
deletion requests for these child entries? Alternatively, you could
define security rules to 'hide' them from the JXplorer user.

Otherwise, you could certainly modify the 'AdvancedOps.java'
class and change the 'recursive deletion' code quite easily to make
yourself a customised version, but I'm very reluctant to make it a
part of the standard product; maintaining this sort of 'special case'
code can be quite difficult as more and more 'special cases' are
added :-/. I'm happy to point you to the right location if you want
to do it yourself though!

cheers,

Chris

Hi Chris,
Sorry I didn't make myself clear, your understanding is correct,
when deleting an entry, our code would iterate all the children and
delete them without any check, then delete the parent itself. it's
reduandent with the feature of JXPlorer's 'depth-first tree
deletion of all the children'.
The problem in our case is that as the child couldn't be deleted
alone(they must co-exist with the parent), when JXplorer does a
depth-first tree deletion of all the children, it goes first
directly to delete the child, and it would failed as our code
always block the child deletion alone. What we want is that
JXplorer just go directly to delete the parent, then our code
would take care of the deletion of children.
I guess in JXplorer, you would translate the 'deletion an entry'
click in GUI to several LDAP commands starting with the deletion of
each child and ending with the deletion of parent. What we want is
that could JXplorer also give an option to translate the GUI
command 'deletion an entry' to one LDAP command 'deleting the
parent directly'.
Thanks a lot for your help.
Best Regards,
Wendy
Sent: 2006$BG/(B8$B7n(B28$BF|(B 18:09
To: Wendy Luo (QA/EMC)
Subject: Re: Question about deletion in JXPLORER
Hi Wendy,
I'm not sure I understand - how can you delete an entry without
deleting the children first?
When deleting, JXplorer does a depth-first tree delete of all
the children - I'm not sure how else to do it? Is the problem that
you are using an LDAP interface to something that isn't really a
directory?
cheers,
- Chris

Hi Chris,
We are using JXPlorer as a LDAP client, and find that it's
impossible to delete an entry without checking the children, as
before when we were using LDAP Browser, there's an option that
'with children' when deleting an entry. The reason we want this
option is that when deleting an entry, our framework would delete
all the children, but when deleting the child only, we would do
certain check and if that check failed the deletion would failed.
With JXPlorer, we couldn't delete an entry as the children would
be always deleted first and some deletion would failed.
Thanks for your reply in advance.
Best Regards,
Wendy

...