[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
AW: [jwt-dev] new view implementation
|
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 weve collected many new requirements (see
> > Bugs 238259, 238259, 248565, 250897, 251662, 257403) and Id like to
> > begin working on these somewhere in the next days. To get an overview
> > for the community, Ive 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
