directory-dev mailing list archives

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

Can we please keep Issue related stuff at JIRA? There is only one
comment on the Issue page here:

By looking at it people cannot know what's going on about that issue.


On 5/24/07, Ole Ersoy <> wrote:
> 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
> experience.
> 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
> Cheers,
> - Ole


View raw message