Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: pass (herse.apache.org: domain of ersin.er@gmail.com designates
 64.233.166.177 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=QMkwOQj8FmVrn1A3ebLG21Rk64q6oFH6FH1PTSthYtTPjKmVd/NCvPc0xxQIzL1MnxoEPBG6ZKEnfXHbClrMnpgk1xMxyhpA7lx8wKFJsfrCUIw75TfFLv+SzvnDa74lK5sqLPuRx40lKkBg8gUuXV0FAxxLw59aG5ANWQmYDdc=
Message-ID: <a1b4a6610705231419p53b927f1gc8a7e97e185345ae@mail.gmail.com>
Date: Thu, 24 May 2007 00:19:18 +0300
From: "Ersin Er" <ersin.er@gmail.com>
To: "Apache Directory Developers List" <dev@directory.apache.org>
Subject: Re: [jira] Created: (DIRSTUDIO-109) Schema Entry Deletes Must be
 Sequenced
In-Reply-To: <4654AD6F.4090609@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <27322535.1179947956334.JavaMail.jira@brutus>
	 <a32f6b020705231247m1a169349x53e8824e7d4c31e6@mail.gmail.com>
	 <46549D6C.5000608@gmail.com> <4654A71F.5090108@apache.org>
	 <4654AD6F.4090609@gmail.com>

Hi,

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

https://issues.apache.org/jira/browse/DIRSTUDIO-109

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

Thanks.

On 5/24/07, Ole Ersoy <ole.ersoy@gmail.com> 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
>
>
> SNIP
>


-- 
Ersin