[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jwt-dev] new view implementation
|
Hi Christian,
We would add some requirements on the use and extension of factories in
regards to the re-implementation of view.
Currently figures factory can be extended within the view extension
point. Palette factory which depends on view should also be extended
with the view extension point. Rodrique has proposed some codes.
Our requirements show that 2 other factories shoud also depend on view :
EditPartFactory and ImageFactory. These factories should also be extended.
Specific editParts are required for the business view which are may be
not the same for the runtime view. For instance for the business view a
specific controlNodeEditPart should create complex figure (may be giving
control to children editParts) to be able to transform this abstract
node to a more refined refined one.
In order to easily extend and access to these factories, I propose to
add a factory registry. It's an easy way to centralize the access to the
factories for each view.
Jwt should have a default registry with default factories. this registry
should be extended by the plugin using jwt workflow editor and could
provide extended factories for the extended registry. An interface for
each factory and for the registry should be introduced.
Regards,
Marc.
Christian Saad a écrit :
Hi all,
as you may already know, the current view concept in JWT is scheduled
for reimplementation, since 1. it is not powerful enough to meet the
new demands and 2. the implementation has become quite confusing over
time. In the past weeks we’ve collected many new requirements (see
Bugs 238259, 238259, 248565, 250897, 251662, 257403) and I’d like to
begin working on these somewhere in the next days. To get an overview
for the community, I’ve summarized the given requirements and
suggested implementations. Please feel free to make comments,
suggestions, corrections…
A view controls:
1. Visibility: Determines if an element is visible under the given
view (affects graphical editor, standard palette, outline)
2. Naming: The names and descriptions of views (multilang) and the
icons shown in the palette (currently read from plugin.properties)
3. Figures: The graphical representation of the elements (one default
figure per element, multiple alternative figures)
4. Palette: A custom implementation of the palette
View configuration contains:
1. View Meta Data: View Name (multilang), Version, Internal ID, View Icon
2. Configuration: Visibility, Naming, Figures, Palette
Implementation:
* Configuration through an XML file (extension *.view, not compatible
with current *.view files)
* View configuration file is registered using an extension point
* Concrete files (Java implementations of Figures and Palette, Icon
files) are registered through an “resource” extension point, where
they are given a unique ID. The *.view file refers only to these IDs
Additional view-related issues:
* Support different element positions/sizes in different views
(requires modification of the meta model)
* Support bend-points for edges (requires modification of the meta model)
* Store view-related information
(position/size/icon/References/ReferenceEdges) in an external file
* Put default views (business & technical) in a separate plugin
(requires that jwt-we can run without a loaded view)
Views and aspects:
* Four possible implementations (at the moment):
1. Always display everything which is added by aspects
2.Setting a default behavior per view (display aspects or hide aspects)
3. Create ONE view file for an aspect that complements the main view
chosen by the user
4. Create MULTIPLE view files for an aspect (the user chooses: 1 view
for standard elements, 1 view for aspect related elements)
Regards,
Chris
------------------------------------------------------------------------
_______________________________________________
jwt-dev mailing list
jwt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jwt-dev
--
Marc Blachon
Bull, Architect of an Open World TM
BPM Team, Bull R&D
1, rue de Provence
38130 Echirolles (France)
Direct Line: +33-4-76-29-74-80
*Orchestra*, The BPEL open source project: http://orchestra.objectweb.org
*Bonita*, The XPDL open source project: http://bonita.objectweb.org
