Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: AW: [jwt-dev] new view implementation 
Hi Christian, all,
I go on on implementation of a single access to all the factories with a factoryRegistry. 
This factoryRegistry is now a point of extension of jwt-we.
The prototype contains the modified code of jwt-we plug-in and the bonita-studio plug-in (extending previous one). 
This prototype (with the 2 plug-ins) can be acceded on the forge of bonita:
svn://svn.forge.objectweb.org/svnroot/bonita
under:
- trunk/jwt-we-proto
- and trunk/studio/bonita.bonita.views
Checkout of both is required.
This prototype shows an implementation of this registry containing factories for Images and palette. 
The factoryRegistry is extended in the bonita plugin.
For ImageFactory a CompositeImageFactory has been introduced in jwt-we allowing to get imageFactories creating images with icons researched in both plug-ins (with there own iconbasepath). Therefore added BPMN icons (for palette and figures) are now located into bonita plug-in and no more into jwt-we. Interfaces for all these factories have been introduced and used into jwt-we and bonita studio code. 
It should be completed by factories for figures and editParts.
I'm in vacation for 2 weeks. Is it possible for you to have a look at this prototype in order to have your returns next year. 
Merry Christmas and happy holidays to everyone.

Regards,
Marc.

Christian Saad a écrit :

Hi Marc,

ok, if you understand you correctly there are two new requirements for the
views:

* Allow to bind view-specific EditParts to the model elements
* Switch the ImageFactory

Wow, I think we're going to source out the complete GEF part of the editor
one day ;)

The second request should at least be answered partially by the existing
plan to link model objects with icons in the view. Are there any
circumstances where this would not be sufficient and additional view
specific images need to be accessed? If not, I think we should stick with
the old method. Maybe we could provide the possibility to have multiple
figures/icons/names per model element which can be switched at run time by a
view controller or something like that.

Concerning the factories:
Actually, I was rather thinking of putting that kind of logic into the view
configuration file (XML). In that case, there will be only one (dynamic)
factory per resource type which is part of the workflow editor and
dynamically creates the needed objects (icons, figures, editparts,
palette...) according to the XML configuration. This way, we would have all
configuration information in one place (the view file) and the views can be
edited comfortably by the graphical view editor which introspects the meta
model and automatically creates a valid configuration. What do you think?

Regards,
Chris


-----Ursprüngliche Nachricht-----
Von: jwt-dev-bounces@xxxxxxxxxxx [mailto:jwt-dev-bounces@xxxxxxxxxxx]
Im Auftrag von Marc Blachon
Gesendet: Mittwoch, 10. Dezember 2008 13:12
An: Java Workflow Toolbox
Betreff: 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

_______________________________________________
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





--
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

Back to the top