[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
AW: AW: [jwt-dev] Good dev practices : About allowing to disableJWTdefault features
|
Hi Marc,
>>On another topic, Open World Forum yesterday in Paris was my last event in
a while - went very well btw, took some photos of Miguel talking about
Bonita Designer on JWT, Gaël of PEtALS fame took some of mine talking about
SOA and BPM ^^
I'm happy to hear that. Hopefully the OpenWorldForum as well as the ICT
event has been a success? I'm looking forward to your pictures! Where can I
find them? ;-)
Best regards,
Florian
Florian Lautenbacher a écrit :
> 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
>
_______________________________________________
jwt-dev mailing list
jwt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jwt-dev
