[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[jwt-dev] Good dev practices : About allowing to disable JWT default features

Hi all

Since we're geared more towards making JWT flexible enough for vendors to extend it, the question of disabling default JWT features has appeared several times.

Ex. :
[Bug 257195] Disable overview page https://bugs.eclipse.org/bugs/show_bug.cgi?id=257195
[Bug 256134] make original views deactivatable https://bugs.eclipse.org/bugs/show_bug.cgi?id=256134

Here are a few thoughts about how best to do it.

1. The right question is not about "disabling" but rather about "making optional". Likewise the solution is not to create an extension point that disables it, but to create an extension point that allows to externalize the default code in an optional plugin. Moreover if there already exist a similar extension point, it should be reused so as to unify and make consistent the whole architecture.

2. Required flexibility can be introduced at several architectural levels that use various technical solutions. Common architectural levels are :
* plugin level, using extension points ; typically gives flexibility to the vendor, so he can choose a plugin feature to be part of its release or not.
* application level, using preference entry ; gives flexibility to the user, so he can customize its use of JWT.
* NB. An intermediary level between both could be externalized properties.

3. A single feature may be made flexible at both levels if such flexibility is useful 1. for the vendor at packaging time and 2. for the user at use time. For instance, profile / aspect configuration files can be both plugged in using an extension point (requires the vendor to package it as a plugin) or / and put in a directory where it is autodiscovered at startup (or specified in a preference page, but this has not been done yet). However, the UI pertaining to such flexibility through plugin is any kind of release-making tool and not the PreferencePage UI (which in turn is the rather user-oriented configuration UI) !

4. I'm wondering whether there is some common patterns or code about all this to be shared / gathered in a framework... Thoughts ?