Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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.

begin:vcard
fn:Rodrigue Le Gall
n:Le Gall;Rodrigue
org:BULL SAS;BULL R&D - BPM
adr;quoted-printable:1 RUE DE PROVENCE B.P.208 CENTRE UNIX;;Boite courier: B1/397;Echirolles CEDEX ;Is=C3=A8re;38432 ;France
email;internet:rodrigue.le-gall@xxxxxxxx
title:Portal Technologies' Leader
tel;work:+33(0)4 7629 7464
tel;fax:+33(0)4 7629 7777
note;quoted-printable:*Orchestra*, The BPEL open source project: http://orchestra.objectweb.org=
	=0D=0A=
	*Bonita*, The XPDL open source project: http://bonita.objectweb.org
x-mozilla-html:FALSE
url:http://www.bull.com
version:2.1
end:vcard


Back to the top