Le 03/04/15 09:41, Stefan Seelmann a écrit : > On 04/01/2015 11:28 PM, Emmanuel Lécharny wrote: >> Hi, >> >> I face an issue that requires some thought - and potentially some rework >> in both the ApacheDS and OpenLDAP configuration editors -. >> >> Once upon a time, we had many versions of the ApacheDS configuration >> plugin, because every time we changed the configuration, we had to adapt >> the UI. We decided to get rid of all those plugins, to only keep the >> latest version (ie 2.0). Th pb is exactly teh same for the OpenLDAP >> configuration : it evolves... >> >> Finding the best way to deal with this problem is not simple. It's not >> only a pb of loading the right config, it's also a pb with the UI >> itself. ATM, I don't see any good solution to get an UI that is >> adaptative, but defining a new plugin for each version, which is >> extremelly heavy, or a complex handling of the UI with various checks to >> handle all the possibilities. >> >> First, I do think that for ApacheDS, we can keep going with only one >> plugin, because we expect our users to migrate to the latest ApacheDS >> version, until we reach a 2.0. It's not ideal, but this is most >> certainly the right thing to do. >> >> For OpenLDAP, it's really different, because there are tens of thousand >> users with many different versions (and I'm just talking about the 2.4 >> revision, which, as of today, has 41 versions). It makes it impossible >> to ignore older versions (up to a point), especially for all those who >> are installing the broken and antiquated versions 'provided' (so to >> speak) by distribution (RH, Debian, etc...) >> >> So, what are our options ? >> >> Currently, we define some Java bean to store the attribute's value. That >> means we have to also keep a track of which attribute exists in each >> version (this is not done atm), so that we don't inject unexisting >> attributes, or simply have missing ones. The other aspect we have to >> deal with is the GUI itself : how do we present the parameters and their >> values, when it can change fro version to version ? >> >> At some point in the future, we coud imagine to leverage the template >> editor, but that would require some adaptation (typically, if we want to >> add popups, as it's not supported). But that would be a lot of work. >> >> A simpler option would be to have templates for each configuration >> ObjectClass, but we would use a much simpler GUI : the user would have >> to use the LDAP browser to switch from one configuration element to >> another. Quite basic, but an elegant presentation is possible. >> >> Anyway, a lot to think about, and I'd liek to have your opinion about >> what could be the best way to go. > I see that in the beans we already have a @ConfigurationElement > annotation which contains the attribute name. So when rendering the UI > we can check if that attribute exists in schema or not and show/hide it. > > We can also introspect the schema and try to derive the OpenLDAP version > (or version range) from existing/missing OC and AT.
We definitively have to read the config schema from the OpenDLAP server. I was thinking about adding a parameter to the annotation (the version for which the attribute has been created) but it's a bit complex, because some parameters might be removed, and we also need a version for that. Another option is to simply use what the server returns, and only show the elements that we know the server will handle. It's just a matter of building a HashSet with all the supported elements, and to check against this HashSet when building the GUI.
