directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pierre-Arnaud Marcelot ...@marcelot.net>
Subject Re: [Studio] Switch the 'default' property value of the LDIF Editor extension to 'false'
Date Fri, 10 Dec 2010 16:19:21 GMT

On 10 déc. 2010, at 17:10, Kiran Ayyagari wrote:

> On Fri, Dec 10, 2010 at 6:00 PM, Pierre-Arnaud Marcelot <pa@marcelot.net> wrote:
>> 
>> On 10 déc. 2010, at 16:49, Kiran Ayyagari wrote:
>> 
>>> On Fri, Dec 10, 2010 at 5:28 PM, Pierre-Arnaud Marcelot <pa@marcelot.net>
wrote:
>>>> Hi Dev,
>>>> I'm facing an interesting issue in the writing of the Apache DS 2.0
>>>> Configuration Editor.
>>>> As the ApacheDS' configuration is now based on an LDIF file, Studio's LDIF
>>>> Editor always show up when opening the 'config.ldif' file from disk.
>>>> This is due to the fact that the 'default' property value is set to 'true'
>>>> in the LDIF Editor extension definition.
>>>> It is defined as is in the following file, '[Studio
>>>> Checkout]/plugins/ldifeditor/plugin.xml':
>>>> 
>>>>   <extension
>>>>          point="org.eclipse.ui.editors">
>>>>     <editor
>>>>           class="org.apache.directory.studio.ldifeditor.editor.LdifEditor"
>>>> 
>>>> contributorClass="org.apache.directory.studio.ldifeditor.editor.LdifEditorContributor"
>>>> ======>   default="true"
>>>>           extensions="ldif, ldiflog"
>>>>           icon="resources/icons/ldifeditor.gif"
>>>>           id="%Editor_LdifEditor_id"
>>>>           name="%Editor_LdifEditor_name"/>
>>>>    </extension>
>>>> 
>>>> I'd like to pass this value to "false" in order to allow the ApacheDS 2.0
>>>> Configuration Editor to be opened specifically if the filename is
>>>> 'config.ldif'.
>>> hmm, this might confuse users who are connecting to other servers(and
>>> they have accidentally trying
>>> to open their custom ldif file named 'config.ldif' ).
>> 
>> Are there any other servers using 'config.ldif' as default configuration file?
>> 
> it is not that other servers have a special file named 'config.ldif' ,
> any ignorant user can create
> a new ldif file and save it as config.ldif and he will be surprised to
> see a error popup while trying to
> open it in studio.

I understand, you're probably right.
From a user POV, that makes sense.


>> If yes, I have the possibility to pre-scan the file and validate or invalidate the
editor for a particular given file (but this has to be as lightweight as possible, especially
is there are multiple editor candidates).
> this is an option but I would prefer not to do any such checks while
> opening a file with
> plain File -> Open option.

I think that's the way to go. It's really a lazy-implementation and should only be triggered
for files named 'config.ldif'.
That's the way Eclipse handles a lot of specific formats.


>> Or, we could also rename the file to 'adsconfig.ldif' to avoid name collisions.
>> 
>>> Can we have a "Open With" or something similar tab to open the config
>>> file with different editor?
>> 
>> This is already provided a standard functionality for file in the workspace (as in
the Java perspective), but not when you open a file from the 'File > Open...' menu item.
>> In that case, Eclipse goes through a list of editor candidates based on their extension
definition (supported extensions, supported filenames, priority) and tries to find the good
one.
>> 
> I would prefer to leave this default functionality intact and let user
> decide if he wants to open
> the configuration ldif file with a plain ldif editor or with our
> configuration editor.

The problem is that he can only decide that if the file is in his workspace (Studio installed
in Eclipse).
In the RCP app, there's no workspace involved and we only have the 'File > Open...' menu
item to open files from disk.

That's why I think our only option is to check if the file starts with the correct 'ou=config'
and 'ads-directoryServiceId=default,ou=config' entries.
It will excluded files that should not be open with the Configuration Editor.


>>> P.S:- This open a custom editor if file name is 'config.ldif' reminds
>>> me of classing linux windowing
>>>         environments which sometimes *hard* to predict why they are
>>> crashing or behaving
>>>         differently. It turns out, that it is due to some casing of
>>> letter names of a file or other
>>>         but leave no clue to the user about what it is expecting.
>>> 
>>> --
>>> Kiran Ayyagari
>> 
>> 
> 
> 
> 
> -- 
> Kiran Ayyagari


Mime
View raw message