directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ole Ersoy <>
Subject Re: [jira] Created: (DIRSTUDIO-109) Schema Entry Deletes Must be Sequenced
Date Wed, 23 May 2007 21:09:03 GMT

Stefan Seelmann wrote:
> Ole,
> I don't think it makes sense to add such semantics into the default
> delete operation of the browser.

Sure.  The use case for me anyways is just to
be able to quickly delete some schema containers
while debugging junit tests...and I understand
that there are probably cross LDAP server considerations, etc...
which makes bloating the delete function less sexy...

> What we could do is the following: PAM and I would like to extend the
> current Schemas Editor to operate directly on the schema partition of
> ADS instead of .schema files. So we have to add this functionality into
> the Schemas Editor:
> - When saving a new schema into the schema partition we have to consider
> the correct order (syntaxes before matching rules before attribute types
> before object classes)
> - When deleting a schema we have to consider the inverse order
> Sounds good?

Smoookkin!!  U and PAM Da Mans!

Should I just close this then like Alex recommended?

Oh - Incidentally this thought just popped in.
Suppose I was editing the Schema partition
entries through the browser, like I was doing.

Once the Schemas editor connects directly to ADS,
might it make sense to "Switch" the delete action
to the one used by the Schemas Editor, when
connecting to the schema through the browser?

Thus the delete action implementation
being used would depend on whether the partition being
connected to is ADS's schema partition.

I need to review the IAdaptable pattern the Eclipse APIs
use, but I think that if the action were an IAdaptable
then selecting the implementation for the delete action
could made fairly elegant.

So if ou=schema is the partition, then the cascading delete
stuff becomes possible by delegating the delete action request
to the CasacdingDelete action, but for all other partitions
and connections it's the other delete action implementation.

This might provide for a better ADS dynamic schema editing

Now it's sort of like this same feature request again :-)

Anyways it might be a feature suggestion that could
just hang around on in the periphery of LS feature requests,
and then if for some reason others start requesting a pluggable/switchable
action API in LS, then then maybe it gets interesting.

Or we could just nuke it:-)  I have both keys.  Just give me the signal

- Ole


View raw message