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

[Mickael Istria <mickael.istria@xxxxxxxxxxx>]

Hi all,

I'm trying to follow the discussion about (de)activating views, and I think
that the easiest and most efficient way to deal with views activation is
probably to make vendors write their own perspective where they could
choose which views are enabled by default.
Then vendors would be able to ship a product with the views they think are
important, and users could, if they want, add other views that are
currently part of the JWT WE (such as the overview).

Moreover, it seems really easier to implement...


Therefore, I am not really aware yet about vendor requirements, thus this
may not be a sufficient solution.

Regards,
Mickael

On Tue, 2 Dec 2008 16:17:48 +0100, "Florian Lautenbacher"
<florian.lautenbacher@xxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
> 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
> 
> _______________________________________________
> jwt-dev mailing list
> jwt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/jwt-dev