AW: AW: AW: AW: AW: [jwt-dev] Bonita Designer use cases andrequirements

["Christian Saad" <christian.saad@xxxxxxxxxxxxxxxxxxxxxxxxxx>]

Hi Rodrigue,

ok, if I understood you correctly, this would then be another point that
should be added to the new views implementation since the palette would be
bound to one (or more) views?

Regards,
Chris

> -----Ursprüngliche Nachricht-----
> Von: jwt-dev-bounces@xxxxxxxxxxx [mailto:jwt-dev-bounces@xxxxxxxxxxx]
> Im Auftrag von Rodrigue Le Gall
> Gesendet: Dienstag, 2. Dezember 2008 17:37
> An: Java Workflow Toolbox
> Betreff: Re: AW: AW: AW: AW: [jwt-dev] Bonita Designer use cases
> andrequirements
> 
> Hi all,
> 
> I have created a feature request in bugzilla and I've attached the
> implementation we need.
> 
> In fact, in order to be the more flexible as we can, we propose to add
> the feature to define a palette factory for each view. If you don't
> want to specify the palette factory, so the standard palette will be
> used.
> see https://bugs.eclipse.org/bugs/show_bug.cgi?id=257224
> 
> Feature detail:
> To be more flexible, we need to add our own palette to our views in
> JWT.
> Actually, there is a single dynamic palette based on the model.
> So we propose to add the capacity to specify a palette factory for a
> view in order to be able to get a specific palette with a specific
> context.
> 
> To do that we propose to add the palette factory in the view extension
> point and to modify the palette construction to take in count this
> capacity.
> 
> 
> thoughts?
> 
> --
> Rodrigue
> 
> 
> 
> Miguel Valdes Faura a écrit :
> > Hi guys,
> >
> > At Bull side we will formalise our requirements next week and we will
> bring
> > them to the meeting.
> >
> > My main effort afterwards will be to define a common roadmap and work
> with
> > you guys on the way we could join the work on the JWT "kernel".
> >
> > Best regards,
> > Miguel
> >
> > BPM Manager
> >
> > Bull, Architect of an Open World TM
> > 1, rue de Provence
> > 38130 Echirolles (France)
> > Direct Line: +33-4-76-29-72-28
> >
> >
> > *Orchestra*, The BPEL open source project: http://orchestra.ow2.org
> > *Bonita*, The XPDL open source project: http://bonita.ow2.org
> >
> > This e-mail contains material that is confidential for the sole use
> of the
> > intended recipient. Any review, reliance or distribution by others or
> > forwarding without express permission is strictly prohibited. If you
> are not
> > the intended recipient, please contact the sender and delete all
> copies.
> >
> > -----Message d'origine-----
> > De : jwt-dev-bounces@xxxxxxxxxxx [mailto:jwt-dev-bounces@xxxxxxxxxxx]
> De la
> > part de Marc Dutoo
> > Envoyé : jeudi 13 novembre 2008 14:18
> > À : Java Workflow Toolbox
> > Objet : Re: AW: AW: AW: AW: [jwt-dev] Bonita Designer use cases
> > andrequirements
> >
> >
> > Hi Chris, all
> >
> >
> >
> > I agree, it seems to me that we're close to have a common
> architecture, the
> >
> > next step is creating bugzillas, and wiki pages for complex specs or
> >
> > discussions. I'll see what I can do about it tomorrow or on Monday.
> >
> >
> >
> > Regards,
> >
> > Marc
> >
> >
> >
> > On Thu, 13 Nov 2008 10:00:25 +0100, "Christian Saad"
> >
> > <christian.saad@xxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
> >
> >
> >> Hi Marc,
> >>
> >
> >
> >
> >
> >> ok I see this would require to possibility to replace the original
> >>
> >
> > palette
> >
> >
> >> from somewhere from your plugin that provides the aspects
> functionality.
> >>
> >
> >
> >> The
> >>
> >
> >
> >> customization offered by adding custom palettes and by configuring
> the
> >>
> >
> >
> >> palette through views should however be carefully planned so that
> they
> >>
> >
> >
> >> don't
> >>
> >
> >
> >> interfere.
> >>
> >
> >
> >> We should probably record the new requirements in the bugzilla as
> soon as
> >>
> >
> >
> >> possible so that no important requirements get lost.
> >>
> >
> >
> >
> >
> >> Regards,
> >>
> >
> >
> >> Chris
> >>
> >
> >
> >
> >
> >>> -----Ursprüngliche Nachricht-----
> >>>
> >
> >
> >>> Von: jwt-dev-bounces@xxxxxxxxxxx [mailto:jwt-dev-
> bounces@xxxxxxxxxxx]
> >>>
> >
> >
> >>> Im Auftrag von Marc Dutoo
> >>>
> >
> >
> >>> Gesendet: Mittwoch, 12. November 2008 22:44
> >>>
> >
> >
> >>> An: Java Workflow Toolbox
> >>>
> >
> >
> >>> Betreff: Re: AW: AW: AW: [jwt-dev] Bonita Designer use cases and
> >>>
> >
> >
> >>> requirements
> >>>
> >
> >
> >
> >
> >>> Hi Rodrigue, Chris
> >>>
> >
> >
> >
> >
> >>> Good questions indeed...
> >>>
> >
> >
> >
> >
> >>> Maybe we could have both, and abstract our view impl of the palette
> >>>
> >
> >
> >>> behind a palette factory impl ?
> >>>
> >
> >
> >
> >
> >>> Besides I've got requirements on my own on the Palette : not only
> to be
> >>>
> >
> >
> >>> able to specify which type to create, but also which list of
> aspects to
> >>>
> >
> >
> >>> add to it once it has instanciated a type, so you could have
> different
> >>>
> >
> >
> >>> tools in the palette creating the same type but with different
> aspects.
> >>>
> >
> >
> >
> >
> >>> Regards,
> >>>
> >
> >
> >>> Marc
> >>>
> >
> >
> >
> >
> >>> Christian Saad a écrit :
> >>>
> >
> >
> >>>> Hi Rodrigue,
> >>>>
> >
> >
> >
> >
> >>>> the current JWT palette consists of a static and a dynamic part.
> The
> >>>>
> >
> >
> >>> static
> >>>
> >
> >
> >>>> part contains the standard entries like the nodes and references
> >>>>
> >
> >
> >>> while the
> >>>
> >
> >
> >>>> dynamic part allows to create references to existing elements,
> e.g.
> >>>>
> >
> >
> >>> you
> >>>
> >
> >
> >>>> define a new role 'x' and an entry is added to the palette which
> >>>>
> >
> >
> >>> creates a
> >>>
> >
> >
> >>>> new reference to 'x'. Both parts are however subject to the view,
> >>>>
> >
> >
> >>> i.e. their
> >>>
> >
> >
> >>>> elements are hidden if configured so in the view and in the future
> >>>>
> >
> >
> >>> their
> >>>
> >
> >
> >>>> names will also be read from the view and maybe the visibility in
> the
> >>>>
> >
> >
> >>>> palette will be decoupled from the visibility in the editor. In
> >>>>
> >
> >
> >>> theory, it
> >>>
> >
> >
> >>>> would be possible to replace the palette with other
> implementations
> >>>>
> >
> >
> >>> but the
> >>>
> >
> >
> >>>> question is if this is really necessary or if we could put
> everything
> >>>>
> >
> >
> >>> in the
> >>>
> >
> >
> >>>> view configuration which would provide a much easier way to
> customize
> >>>>
> >
> >
> >>> the
> >>>
> >
> >
> >>>> palette.
> >>>>
> >
> >
> >
> >
> >>>> Regards,
> >>>>
> >
> >
> >>>> Chris
> >>>>
> >
> >
> >
> >
> >
> >
> >>>>> -----Ursprüngliche Nachricht-----
> >>>>>
> >
> >
> >>>>> Von: jwt-dev-bounces@xxxxxxxxxxx [mailto:jwt-dev-
> >>>>>
> >
> >
> >>> bounces@xxxxxxxxxxx]
> >>>
> >
> >
> >>>>> Im Auftrag von Rodrigue Le Gall
> >>>>>
> >
> >
> >>>>> Gesendet: Donnerstag, 6. November 2008 13:51
> >>>>>
> >
> >
> >>>>> An: Java Workflow Toolbox
> >>>>>
> >
> >
> >>>>> Betreff: Re: AW: AW: [jwt-dev] Bonita Designer use cases and
> >>>>>
> >
> >
> >>>>> requirements
> >>>>>
> >
> >
> >
> >
> >>>>> Hi,
> >>>>>
> >
> >
> >
> >
> >>>>> In fact the Bonita use cases identify that we need a concept of
> >>>>>
> >
> >
> >>>>> PaletteFactory customizable for each view (like the figure
> Factory).
> >>>>>
> >
> >
> >
> >
> >>>>> A Palette is a very simple composant and it is acceptable and
> easy
> >>>>>
> >
> >
> >>> to
> >>>
> >
> >
> >>>>> write a PaletteFactory if we need to customize it. So JWT must
> >>>>>
> >
> >
> >>> provide
> >>>
> >
> >
> >>>>> a default PaletteFactory (with the actual logic of hidding some
> >>>>>
> >
> >
> >>>>> component by using the view configuration), but to be very
> flexible
> >>>>>
> >
> >
> >>>>> anybody must be able to provide a PaletteFactory with its own
> logic
> >>>>>
> >
> >
> >>>>> (hardcoded, configurable, ...).
> >>>>>
> >
> >
> >
> >
> >>>>> thoughts?
> >>>>>
> >
> >
> >
> >
> >>>>> --
> >>>>>
> >
> >
> >>>>> Rodrigue
> >>>>>
> >
> >
> >
> >
> >>>>> *Orchestra*, The BPEL open source project:
> http://orchestra.ow2.org
> >>>>>
> >
> >
> >>>>> *Bonita*, The XPDL open source project: http://bonita.ow2.org
> >>>>>
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >>>>> Christian Saad a écrit :
> >>>>>
> >
> >
> >
> >
> >>>>>> Hi,
> >>>>>>
> >
> >
> >
> >
> >>>>>> In order to show concrete elements in a more abstract view, the
> >>>>>>
> >
> >
> >>>>>> elements could be set to be visible in the abstract view but
> >>>>>>
> >
> >
> >
> >
> >>>>> replacing
> >>>>>
> >
> >
> >
> >
> >>>>>> their figure and caption with the figure/caption of the abstract
> >>>>>>
> >
> >
> >
> >
> >>>>> type.
> >>>>>
> >
> >
> >
> >
> >>>>>> Maybe we could also add an option to hide certain elements in
> the
> >>>>>>
> >
> >
> >>>>>> palette, so that the fake abstractcontrolnode (really forknode)
> >>>>>>
> >
> >
> >
> >
> >>>>> doesn't show up in the palette.
> >>>>>
> >
> >
> >
> >
> >>>>>> And for replacing abstract concepts with concrete ones, I think
> >>>>>>
> >
> >
> >>> that
> >>>
> >
> >
> >>>>>> this could become quite tedious for the user if the control
> really
> >>>>>>
> >
> >
> >
> >
> >>>>> has
> >>>>>
> >
> >
> >
> >
> >>>>>> to be removed and a new one should be added since connections
> and
> >>>>>>
> >
> >
> >>>>>> already set attributes must be restored (if this is the way it
> is
> >>>>>>
> >
> >
> >
> >
> >>>>> done
> >>>>>
> >
> >
> >
> >
> >>>>>> until now?). I'm thinking that we could provide a way to do this
> >>>>>>
> >
> >
> >>>>>> automatically, e.g. by offering an option in the context menu
> that
> >>>>>>
> >
> >
> >>>>>> shows all concrete subtypes and automatically changes the type
> of
> >>>>>>
> >
> >
> >>> the
> >>>
> >
> >
> >>>>>> EMF model element internally to the concrete type while keeping
> all
> >>>>>>
> >
> >
> >
> >
> >>>>> existing preferences.
> >>>>>
> >
> >
> >
> >
> >>>>>> Regards,
> >>>>>>
> >
> >
> >>>>>> Chris
> >>>>>>
> >
> >
> >
> >
> >
> >
> >
> >
> >>>>>>>> FL:
> >>>>>>>>
> >
> >
> >
> >
> >>>>>>>> Concerning the abstract activity node: the metamodel already
> >>>>>>>>
> >
> >
> >>>>>>>> includes
> >>>>>>>>
> >
> >
> >
> >
> >
> >
> >>>>>>> some
> >>>>>>>
> >
> >
> >
> >
> >
> >
> >>>>>>>> abstract nodes such as ExecutableNode or ControlNode that
> might
> >>>>>>>>
> >
> >
> >>> be
> >>>
> >
> >
> >
> >
> >
> >
> >>>>>>> used for
> >>>>>>>
> >
> >
> >
> >
> >
> >
> >>>>>>>> that purpose. For the moment they are themself abstract
> classes
> >>>>>>>>
> >
> >
> >>> and
> >>>
> >
> >
> >
> >
> >
> >
> >>>>>>> not
> >>>>>>>
> >
> >
> >
> >
> >
> >
> >>>>>>>> shown in the palette or elsewhere, but it might be possible to
> >>>>>>>>
> >
> >
> >>> add
> >>>
> >
> >
> >
> >
> >
> >
> >>>>>>> those in
> >>>>>>>
> >
> >
> >
> >
> >
> >
> >>>>>>>> one view and remove the concrete subclasses from this
> (business)
> >>>>>>>>
> >
> >
> >>>>>>>> view
> >>>>>>>>
> >
> >
> >
> >
> >
> >
> >>>>>>> and to
> >>>>>>>
> >
> >
> >
> >
> >
> >
> >>>>>>>> refine these abstract classes in a more technical view
> >>>>>>>>
> >
> >
> >>> afterwards!?
> >>>
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >>>>>>> Yes, it's what we did. By choosing elements to be displayed
> into
> >>>>>>>
> >
> >
> >>> the
> >>>
> >
> >
> >>>>>>> created view-file (Business/Technical) it becomes possible  to
> >>>>>>>
> >
> >
> >
> >
> >>>>> decide
> >>>>>
> >
> >
> >
> >
> >>>>>>> elements  that are present  into the palette of the  two views
> >>>>>>>
> >
> >
> >
> >
> >>>>> within
> >>>>>
> >
> >
> >
> >
> >>>>>>> the editor.
> >>>>>>>
> >
> >
> >>>>>>> For instance ControlNode can be displayed in the palette of
> both
> >>>>>>>
> >
> >
> >>>>>>> views (we simply added ControlNodeFigure ...) since fork/join
> node
> >>>>>>>
> >
> >
> >
> >
> >>>>> is
> >>>>>
> >
> >
> >
> >
> >>>>>>> only displayed in the palette of the Technical design.
> >>>>>>>
> >
> >
> >>>>>>> But the following use case cannot be realized:
> >>>>>>>
> >
> >
> >>>>>>> - create controlNode in Business view
> >>>>>>>
> >
> >
> >>>>>>> - switch to Technical view and "replace" controleNode by
> forkNode
> >>>>>>>
> >
> >
> >>>>>>> - switch again to Business view :   the forkNode is no more
> >>>>>>>
> >
> >
> >>> visible
> >>>
> >
> >
> >
> >
> >>>>> in
> >>>>>
> >
> >
> >
> >
> >>>>>>> this view. We would want to keep this type of element visible
> >>>>>>>
> >
> >
> >>> (even
> >>>
> >
> >
> >>>>>>> the palette of business view does not contain this element).
> >>>>>>>
> >
> >
> >>>>>>> In other word after refinement of the abstract class in a more
> >>>>>>>
> >
> >
> >>>>>>> technical view switching back to the less technical view does
> not
> >>>>>>>
> >
> >
> >>>>>>> prevent to display the refined element.
> >>>>>>>
> >
> >
> >>>>>>> May be this possibility already exists ?
> >>>>>>>
> >
> >
> >
> >
> >
> >
> >
> >
> >>>>>>>> Concerning "activity, gateways, events, connections and
> >>>>>>>>
> >
> >
> >>> artifacts.
> >>>
> >
> >
> >
> >
> >
> >
> >>>>>>> Should
> >>>>>>>
> >
> >
> >
> >
> >
> >
> >>>>>>>> all of them extend ActivityNode":
> >>>>>>>>
> >
> >
> >>>>>>>> No, definitely not. A connection can't be an ActivityNode of
> >>>>>>>>
> >
> >
> >
> >
> >>>>> course.
> >>>>>
> >
> >
> >
> >
> >>>>>>> As
> >>>>>>>
> >
> >
> >
> >
> >
> >
> >>>>>>>> already mentioned the ExecutableNode might be the activity,
> the
> >>>>>>>>
> >
> >
> >
> >
> >
> >
> >>>>>>> ControlNode
> >>>>>>>
> >
> >
> >
> >
> >
> >
> >>>>>>>> the Gateway. Events are already included in the metamodel but
> >>>>>>>>
> >
> >
> >>>>>>>> without
> >>>>>>>>
> >
> >
> >
> >
> >
> >
> >>>>>>> any
> >>>>>>>
> >
> >
> >
> >
> >
> >
> >>>>>>>> concrete subclasses, those will be needed in the future
> anyway,
> >>>>>>>>
> >
> >
> >>> as
> >>>
> >
> >
> >
> >
> >
> >
> >>>>>>> soon as
> >>>>>>>
> >
> >
> >
> >
> >
> >
> >>>>>>>> we decided what kind of events we want to model (hopefully not
> >>>>>>>>
> >
> >
> >>> the
> >>>
> >
> >
> >
> >
> >
> >
> >>>>>>> whole set
> >>>>>>>
> >
> >
> >
> >
> >
> >
> >>>>>>>> of BPMN which makes it quite confusing). For artifacts we
> >>>>>>>>
> >
> >
> >>> currently
> >>>
> >
> >
> >>>>>>>> distinguish between Role, Application and Data, which can be
> >>>>>>>>
> >
> >
> >
> >
> >>>>> refined
> >>>>>
> >
> >
> >
> >
> >>>>>>> via
> >>>>>>>
> >
> >
> >
> >
> >
> >
> >>>>>>>> aspects and those artifacts are connected with a specific edge
> to
> >>>>>>>>
> >
> >
> >>>>>>>> the Action/ExecutableNode.
> >>>>>>>>
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >>>>>>>>>> 	3. We have already talked about the implication of this
> >>>>>>>>>>
> >
> >
> >
> >
> >
> >
> >
> >
> >>>>>>>>> multiplicity edges on
> >>>>>>>>>
> >
> >
> >
> >
> >
> >
> >
> >
> >>>>>>>>>> a given node. As far as I understand, the mode is flexible
> and
> >>>>>>>>>>
> >
> >
> >>>>>>>>>> does
> >>>>>>>>>>
> >
> >
> >
> >
> >
> >
> >
> >
> >>>>>>>>> not
> >>>>>>>>>
> >
> >
> >
> >
> >
> >
> >
> >
> >>>>>>>>>> constraint this. The graphical layer does constraint action
> to
> >>>>>>>>>>
> >
> >
> >>>>>>>>>> have
> >>>>>>>>>>
> >
> >
> >
> >
> >
> >
> >
> >
> >>>>>>>>> only one
> >>>>>>>>>
> >
> >
> >
> >
> >
> >
> >
> >
> >>>>>>>>>> incoming and one outgoing transition (as UML-AD specifies).
> >>>>>>>>>>
> >
> >
> >
> >
> >
> >
> >>>>>>> However,
> >>>>>>>
> >
> >
> >
> >
> >
> >
> >>>>>>>>> if we
> >>>>>>>>>
> >
> >
> >
> >
> >
> >
> >
> >
> >>>>>>>>>> provide our own graphical layer (by extension or
> modification),
> >>>>>>>>>>
> >
> >
> >>>>>>>>>> all
> >>>>>>>>>>
> >
> >
> >
> >
> >
> >
> >
> >
> >>>>>>>>> the tools
> >>>>>>>>>
> >
> >
> >
> >
> >
> >
> >
> >
> >>>>>>>>>> should still continue to work normally if they are based on
> the
> >>>>>>>>>>
> >
> >
> >>>>>>>>>> model
> >>>>>>>>>>
> >
> >
> >
> >
> >
> >
> >
> >
> >>>>>>>>> and not
> >>>>>>>>>
> >
> >
> >
> >
> >
> >
> >
> >
> >>>>>>>>>> on the graphical layer model. Right?
> >>>>>>>>>>
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >>>>>>>>> Yes, they "should" ;) The only way to be sure is
> >>>>>>>>>
> >
> >
> >>>>>>>>>    * 1. to test them, since they have only been tested on
> >>>>>>>>>
> >
> >
> >>> workflow
> >>>
> >
> >
> >>>>>>>>> models that have been created with a constrained WE till now
> >>>>>>>>>
> >
> >
> >>>>>>>>>    * to have validation rules that validation engines can
> >>>>>>>>>
> >
> >
> >>> enforce.
> >>>
> >
> >
> >>>>>>>>> That's why I was talking about moving such constraints to a
> >>>>>>>>>
> >
> >
> >
> >
> >
> >
> >>>>>>> validation
> >>>>>>>
> >
> >
> >
> >
> >
> >
> >>>>>>>>> engine (ex. EMF's), and then why not allow vendors to
> customize
> >>>>>>>>>
> >
> >
> >
> >
> >>>>> the
> >>>>>
> >
> >
> >
> >
> >>>>>>>>> set of validation rules for their own use (profile). However,
> if
> >>>>>>>>>
> >
> >
> >
> >
> >>>>> it
> >>>>>
> >
> >
> >
> >
> >>>>>>>>> has to be done in October I'd simply make the existing edge
> >>>>>>>>>
> >
> >
> >
> >
> >
> >
> >>>>>>> constraint
> >>>>>>>
> >
> >
> >
> >
> >
> >
> >>>>>>>>> "disablable" using an extension point. Chris, what do you
> think
> >>>>>>>>>
> >
> >
> >>> ?
> >>>
> >
> >
> >
> >
> >
> >
> >
> >
> >>>>>>>> This shouldn't be a problem. For the time being, I think for
> the
> >>>>>>>>
> >
> >
> >>>>>>>> time
> >>>>>>>>
> >
> >
> >
> >
> >
> >
> >>>>>>> being
> >>>>>>>
> >
> >
> >
> >
> >
> >
> >>>>>>>> we could also simply read the constraint for the maximum
> number
> >>>>>>>>
> >
> >
> >>> of
> >>>
> >
> >
> >>>>>>>> incoming/outgoing edges from plugin.properties where it can be
> >>>>>>>>
> >
> >
> >>>>>>>> easily adapted by vendors.
> >>>>>>>>
> >
> >
> >
> >
> >>>>>>>> FL:
> >>>>>>>>
> >
> >
> >
> >
> >>>>>>>> Hmm, another thought would be to define the maximum number of
> >>>>>>>>
> >
> >
> >
> >
> >
> >
> >>>>>>> incoming and
> >>>>>>>
> >
> >
> >
> >
> >
> >
> >>>>>>>> outgoing edges for each element by the view-file? So, a
> business
> >>>>>>>>
> >
> >
> >
> >
> >
> >
> >>>>>>> manager
> >>>>>>>
> >
> >
> >
> >
> >
> >
> >>>>>>>> would be allowed to ignore such things as control nodes and
> >>>>>>>>
> >
> >
> >>> simply
> >>>
> >
> >
> >
> >
> >
> >
> >>>>>>> used
> >>>>>>>
> >
> >
> >
> >
> >
> >
> >>>>>>>> nodes and edges (as he would love to do), but in the technical
> >>>>>>>>
> >
> >
> >>> view
> >>>
> >
> >
> >
> >
> >
> >
> >>>>>>> could
> >>>>>>>
> >
> >
> >
> >
> >
> >
> >>>>>>>> then be changed and more semantics via different control nodes
> >>>>>>>>
> >
> >
> >
> >
> >>>>> added.
> >>>>>
> >
> >
> >
> >
> >>>>>>>> Probably this needs also a validation mechanism when switching
> >>>>>>>>
> >
> >
> >>> from
> >>>
> >
> >
> >
> >
> >
> >
> >>>>>>> one view
> >>>>>>>
> >
> >
> >
> >
> >
> >
> >>>>>>>> to another. What do you think?
> >>>>>>>>
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >>>>>>>>>> 	5. We would like many different ways to display properties.
> >>>>>>>>>>
> >
> >
> >
> >
> >>>>> One
> >>>>>
> >
> >
> >
> >
> >
> >
> >>>>>>>>> of them is
> >>>>>>>>>
> >
> >
> >
> >
> >
> >
> >
> >
> >>>>>>>>>> inside the task itself. There is a strict mapping between
> the
> >>>>>>>>>>
> >
> >
> >>>>>>>>>> palette
> >>>>>>>>>>
> >
> >
> >
> >
> >
> >
> >
> >
> >>>>>>>>> and the
> >>>>>>>>>
> >
> >
> >
> >
> >
> >
> >
> >
> >>>>>>>>>> model. Therefore, how can we modify the way things (and in
> our
> >>>>>>>>>>
> >
> >
> >>>>>>>>>> case
> >>>>>>>>>>
> >
> >
> >
> >
> >
> >
> >
> >
> >>>>>>>>> actions)
> >>>>>>>>>
> >
> >
> >
> >
> >
> >
> >
> >
> >>>>>>>>>> are rendered just by extension?
> >>>>>>>>>>
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >>>>>>>>> Properties are already displayed in the PropertyView. There
> you
> >>>>>>>>>
> >
> >
> >
> >
> >>>>> can
> >>>>>
> >
> >
> >
> >
> >>>>>>>>> create a custom editor for a given property (extension point
> by
> >>>>>>>>>
> >
> >
> >>>>>>>>> Mickaël), or a whole new tab (by Chris), see wiki. You can
> make
> >>>>>>>>>
> >
> >
> >>>>>>>>> them also appear in the Outline by changing the
> >>>>>>>>>
> >
> >
> >>>>>>>>> ModelContentOutlinePage's content and label provider.
> >>>>>>>>>
> >
> >
> >
> >
> >>>>>>>>> Or do you mean, display properties within the diagram, like
> >>>>>>>>>
> >
> >
> >>> above
> >>>
> >
> >
> >
> >
> >
> >
> >>>>>>> the
> >>>>>>>
> >
> >
> >
> >
> >
> >
> >>>>>>>>> task icon ?
> >>>>>>>>>
> >
> >
> >>>>>>>>> Maybe the UML View sample plugin (see bugzilla) is
> >>>>>>>>>
> >
> >
> >>> interesting...
> >>>
> >
> >
> >>>>>>>>> Chris,
> >>>>>>>>>
> >
> >
> >>>>>>>>> any idea ?
> >>>>>>>>>
> >
> >
> >
> >
> >>>>>>>>> And could your describe concrete examples of such different
> ways
> >>>>>>>>>
> >
> >
> >>> ?
> >>>
> >
> >
> >
> >
> >
> >
> >
> >
> >>>>>>>> A concrete example would definitly be good in order to get
> this
> >>>>>>>>
> >
> >
> >
> >
> >
> >
> >>>>>>> requirement
> >>>>>>>
> >
> >
> >
> >
> >
> >
> >>>>>>>> right.
> >>>>>>>>
> >
> >
> >>>>>>>> Basically, views allow to replace JWT's internal draw2d
> figures
> >>>>>>>>
> >
> >
> >
> >
> >>>>> with
> >>>>>
> >
> >
> >
> >
> >>>>>>> your
> >>>>>>>
> >
> >
> >
> >
> >
> >
> >>>>>>>> own, so you could implement a new figure that visualizes some
> of
> >>>>>>>>
> >
> >
> >
> >
> >>>>> its
> >>>>>
> >
> >
> >
> >
> >>>>>>>> element's properties.
> >>>>>>>>
> >
> >
> >
> >
> >>>>>>>> FL:
> >>>>>>>>
> >
> >
> >
> >
> >>>>>>>> Yes, I think that would be the way you were asking for. In
> >>>>>>>>
> >
> >
> >>>>>>>> additional plugins you can say that an already existing figure
> >>>>>>>>
> >
> >
> >
> >
> >>>>> shall
> >>>>>
> >
> >
> >
> >
> >>>>>>>> be replaced
> >>>>>>>>
> >
> >
> >
> >
> >
> >
> >>>>>>> by a
> >>>>>>>
> >
> >
> >
> >
> >
> >
> >>>>>>>> new figure and this new figure can be constructed however
> you'd
> >>>>>>>>
> >
> >
> >
> >
> >>>>> like
> >>>>>
> >
> >
> >
> >
> >>>>>>> it. So,
> >>>>>>>
> >
> >
> >
> >
> >
> >
> >>>>>>>> if you do not only want to have the name of the action in it,
> but
> >>>>>>>>
> >
> >
> >
> >
> >
> >
> >>>>>>> also some
> >>>>>>>
> >
> >
> >
> >
> >
> >
> >>>>>>>> properties, be it. If you'd prefer to show a monkey instead of
> >>>>>>>>
> >
> >
> >
> >
> >
> >
> >>>>>>> anything, so
> >>>>>>>
> >
> >
> >
> >
> >
> >
> >>>>>>>> just design one ;-)
> >>>>>>>>
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >>>>>>>>>> We are just starting to get knowledge of EMG/GEF stuff
> (which
> >>>>>>>>>>
> >
> >
> >>> is
> >>>
> >
> >
> >
> >
> >
> >
> >
> >
> >>>>>>>>> quite huge)!
> >>>>>>>>>
> >
> >
> >
> >
> >
> >
> >
> >
> >>>>>>>>>> Some questions may sound very simple! All our excuses for
> that!
> >>>>>>>>>>
> >
> >
> >>>>>>>>>> ;-)
> >>>>>>>>>>
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >>>>>>>>> Well, I'm not sure there is any simple one ;) Anyway, we'll
> try
> >>>>>>>>>
> >
> >
> >>> to
> >>>
> >
> >
> >>>>>>>>> make it easy to get in. And no need to learn everything,
> there
> >>>>>>>>>
> >
> >
> >>> are
> >>>
> >
> >
> >>>>>>>>> other people with other knowledge !
> >>>>>>>>>
> >
> >
> >
> >
> >
> >
> >
> >
> >>>>>>>> EMF/GEF is definitely anything but trivial and your questions
> are
> >>>>>>>>
> >
> >
> >
> >
> >
> >
> >>>>>>> very
> >>>>>>>
> >
> >
> >
> >
> >
> >
> >>>>>>>> important for us since we can decide which way the development
> >>>>>>>>
> >
> >
> >>>>>>>> should
> >>>>>>>>
> >
> >
> >
> >
> >
> >
> >>>>>>> take
> >>>>>>>
> >
> >
> >
> >
> >
> >
> >>>>>>>> in order to fulfill business requirements.
> >>>>>>>>
> >
> >
> >
> >
> >>>>>>>> FL:
> >>>>>>>>
> >
> >
> >
> >
> >>>>>>>> I fully agree. Best regards,
> >>>>>>>>
> >
> >
> >
> >
> >>>>>>>> Florian
> >>>>>>>>
> >
> >
> >
> >
> >>>>>>>> _______________________________________________
> >>>>>>>>
> >
> >
> >>>>>>>> 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
> >>>>>>
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >>>>> --
> >>>>>
> >
> >
> >>>>> Rodrigue, Le Gall
> >>>>>
> >
> >
> >>>>> Portal Technologies' Leader
> >>>>>
> >
> >
> >>>>> BULL R&D , BPM
> >>>>>
> >
> >
> >
> >
> >>>>> Bull, Architect of an Open World TM
> >>>>>
> >
> >
> >>>>> Phone: +33(0)4 7629 7464
> >>>>>
> >
> >
> >>>>> email: rodrigue.le-gall@xxxxxxxx
> >>>>>
> >
> >
> >>>>> http://www.bull.com
> >>>>>
> >
> >
> >
> >
> >>>>> *Orchestra*, The BPEL open source project:
> http://orchestra.ow2.org
> >>>>>
> >
> >
> >>>>> *Bonita*, The XPDL open source project: http://bonita.ow2.org
> >>>>>
> >
> >
> >
> >
> >>>>> This e-mail contains material that is confidential for the sole
> use
> >>>>>
> >
> >
> >>> of
> >>>
> >
> >
> >>>>> the intended recipient. Any review, reliance or distribution by
> >>>>>
> >
> >
> >>> others
> >>>
> >
> >
> >>>>> or forwarding without express permission is strictly prohibited.
> If
> >>>>>
> >
> >
> >>> you
> >>>
> >
> >
> >>>>> are not the intended recipient, please contact the sender and
> delete
> >>>>>
> >
> >
> >>>>> all copies.
> >>>>>
> >
> >
> >
> >
> >
> >
> >
> >
> >>>> _______________________________________________
> >>>>
> >
> >
> >>>> 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
> >
> > _______________________________________________
> > jwt-dev mailing list
> > jwt-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/jwt-dev
> >
> >
> >
> >
> 
> --
> Rodrigue, Le Gall
> Portal Technologies' Leader
> BULL R&D , BPM
> 
> Bull, Architect of an Open World TM
> Phone: +33(0)4 7629 7464
> email: rodrigue.le-gall@xxxxxxxx
> http://www.bull.com
> 
> *Orchestra*, The BPEL open source project: http://orchestra.ow2.org
> *Bonita*, The XPDL open source project: http://bonita.ow2.org
> 
> This e-mail contains material that is confidential for the sole use of
> the intended recipient. Any review, reliance or distribution by others
> or forwarding without express permission is strictly prohibited. If you
> are not the intended recipient, please contact the sender and delete
> all copies.