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

[Marc Dutoo <marc.dutoo@xxxxxxxxxxx>]

Time to write things in the Press section, I will :)

Regards,
Marc

Florian Lautenbacher a écrit :
> 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
>
> _______________________________________________
> jwt-dev mailing list
> jwt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/jwt-dev
>