[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[jwt-dev] PaletteFactory feature proposition
|
Yes.
But I don't think view must know that. IMO, put this information in the
extension point seems to be the best choice. So i think it sould not be
a part of the view configuration (or model).
Thoughts?
--
Rodrigue
Christian Saad a écrit :
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.
_______________________________________________
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