[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
AW: AW: [jwt-dev] new view implementation
|
Hi Marc,
great to hear that you're making progress with the factoryregistry. Since
I'm currently thinking about how to implement the views and in this context
how to link your implementation with the view concept of JWT, I'd like to
ask if it would be possible to use it in the following way:
When creating a JWT view, the designer selects if he wants to use...
a) The JWT default figures, icons, editparts (=standard implementations of
the factories are registered in the factoryregistry that link to JWT's
standard resources)
b) Use his own factories (= his own factory implementations are registered
in the factoryregistry)
c) Define the settings directly in the plugin (= second standard
implementations of the factories that are capable of reading the
configuration from the view's xml file are registered in the
factoryregistry)
If this would meet your requirements, it would provide the benefit that we
could provide one single extension point for registering additional
resources to jwt-we (icons, editparts, figures, factories, ...) that are
referred to via their unique ID. Also, providers who e.g. just want to alter
the name or the figure of a model element and do not need the complete
flexibility of writing their own code could just use method c) to make the
necessary changes without writing a single line of code. However, this
concept would depend on linking the factories with the views and the
question is whether this is an acceptable solution to you. I'm going to take
a look at your current prototype over the next days.
Happy holidays to everyone,
Chris
> -----Ursprüngliche Nachricht-----
> Von: jwt-dev-bounces@xxxxxxxxxxx [mailto:jwt-dev-bounces@xxxxxxxxxxx]
> Im Auftrag von Marc Blachon
> Gesendet: Donnerstag, 18. Dezember 2008 17:08
> An: Java Workflow Toolbox
> Betreff: 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 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
> >>
> >
> >
> > _______________________________________________
> > 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
