[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
AW: AW: [jwt-dev] new view implementation
|
Hi Marc B.,
its good to see that you are making progress with your development. I had a
look at your implementations and everything works fine (except a
nullpointerexception when switching the views).
How much did you change in your jwt-we-prototype? Can the changes be
submitted to jwt-we? Maybe you could create a patch of the updated files?
Best regards and have a nice weekend,
Florian
-----Ursprüngliche Nachricht-----
Von: jwt-dev-bounces@xxxxxxxxxxx [mailto:jwt-dev-bounces@xxxxxxxxxxx] Im
Auftrag von Marc Blachon
Gesendet: 18 December 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
