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