| AW: [jwt-dev] new view implementation |
|
Hi Chris,
good summary. One thing that will probably make life easier
in the coming days/weeks/month during development will be to have a different
extension for the new view files (e.g. *.workflowview), because in the
transition time we will always have different version of JWT WE deployed on our
machine and if now an "old" JWT finds a new .view-file it will be confused and
won't start anymore. Additionally, there is no necessity for converting the
existing .view-files. In the future they are simply neglected and the
.workflowview-files are loaded instead.
Concering the views and aspects: the easiest will probably
be to display everything added by aspects, since they can be turned off
nevertheless. However, if later on aspects can be build on other aspects (I'm
not sure whether this is already possible), then we will probably see the need
to hide some parts of one aspects in order to use another one. Therefore, I
would prefer the possibility to have view-files for aspects, too. My preference
would be one view-file (.workflowview ;-), but multiple view-files would also be
okay for me.
Best regards,
Florian Von: jwt-dev-bounces@xxxxxxxxxxx [mailto:jwt-dev-bounces@xxxxxxxxxxx] Im Auftrag von Christian Saad Gesendet: 09 December 2008 14:23 An: 'Java Workflow Toolbox' Betreff: [jwt-dev] new view implementation 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 |