[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[jwt-dev] Good dev practices : About allowing to disable JWT default features
- From: Marc Dutoo <marc.dutoo@xxxxxxxxxxx>
- Date: Tue, 02 Dec 2008 15:56:14 +0100
- Delivered-to: firstname.lastname@example.org
- User-agent: Thunderbird 184.108.40.206 (X11/20071022)
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.
[Bug 257195] Disable overview page
[Bug 256134] make original views deactivatable
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
* 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
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 ?