AW: [jwt-dev] Good dev practices : About allowing to disable JWTdefault

["Florian Lautenbacher" <florian.lautenbacher@xxxxxxxxxxxxxxxxxxxxxxxxxx>]

Hi Marc,

I agree with you that it would be good practice to extend an existing plugin
with other things which are optional instead of giving a possibility to hide
or disable existing functions.

Therefore, it could also make sense to have a minimal metamodel (only the
basic constructs that are needed by everybody) and source out all additional
current metamodel elements as well as preferences, overview page, views and
other features out into separate plugins. Then nothing needs to be disabled
anymore.

But for this to become reality the aspects and profiles need to work
completely fine and I guess this will take some more time (maybe too much
time for the first vendors to build upon JWT in their next release). BTW:
what's the current status here?

Many things are currently hard-wired into our workflow editor and would
require to create additional extension points and a lot of time to separate
things out again. So for the time being I thought it would be a good idea to
give vendors the possibility e.g. to disable the overview page (as they
requested) in order to adapt JWT to their needs.

But we can also discuss this topic (which is somehow connected to the
feature request "Source out the metamodel") on bugzilla.

Best regards,

Florian





-----Ursprüngliche Nachricht-----
Von: jwt-dev-bounces@xxxxxxxxxxx [mailto:jwt-dev-bounces@xxxxxxxxxxx] Im
Auftrag von Marc Dutoo
Gesendet: 02 December 2008 15:56
An: Java Workflow Toolbox
Betreff: [jwt-dev] Good dev practices : About allowing to disable JWTdefault
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 ?

Regards,
Marc



_______________________________________________
jwt-dev mailing list
jwt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jwt-dev