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. Kind Regards, Stefan
