|
|
|
|
|
| Re: subeditor change & save wipeout content of parenteditor [message #484223 is a reply to message #484205] |
Fri, 04 September 2009 16:13   |
 Ralf Buschermoehle
Messages: 81
Registered: July 2009 |
Member |
|
|
Can I somehow make sure that all GMF Editor is generated and stored in
the diagram file?
Greetings,
Ralf
Ralf Buschermoehle wrote:
> Even more strange ... the "initialize" action generates a .diagram file
> that is nearly empty ... but shows additional classes (correctly in the
> view) ... until the environment is closed?
>
> <?xml version="1.0" encoding="UTF-8"?>
> <notation:Diagram xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI"
> xmlns:notation="http://www.eclipse.org/gmf/runtime/1.0.2/notation"
> xmlns:rmof="http:///rmof/rmof.ecore" xmi:id="_tvrNEZllEd6w34tvOXIlxg"
> type="Rmof" measurementUnit="Pixel">
> <styles xmi:type="notation:DiagramStyle"
> xmi:id="_tvrNEpllEd6w34tvOXIlxg"/>
> <element xmi:type="rmof:Model" href="placeTransition.rmof#/"/>
> </notation:Diagram>
>
> Ralf Buschermoehle wrote:
>> Additionally ... "initialize from provides a correct diagram". A
>> close/open of the runtime-environment(!) and of gmf editor opens an
>> incomplete diagram ...
>>
>> Greetings,
>>
>> Ralf
>>
>> (I attached two PDFs to illustrate the problem).
>>
>>
>>
>> Ralf Buschermoehle wrote:
>>> Hi Alex,
>>>
>>> I regenerated some code (also EMF based parts) which reduced the
>>> number of empty editors. Any hint how I could find out what is wrong
>>> in the code?
>>>
>>> BTW: Sometimes diagrams are not complete ... (e.g., like a class
>>> diagram without attributes). When I add an (arbitrary) element, save,
>>> close and open the editor again all classes are complete again.
>>>
>>> Greetings,
>>>
>>> Ralf
>>>
>>> Alex Shatalin wrote:
>>>> Hello Ralf,
>>>>
>>>> Try saving both editors, then modify sub- and save it again.
>>>> Main editor should be synchronized with sub-one automatically.
>>>>
>>>> -----------------
>>>> Alex Shatalin
>>>>
>>>>
>>
|
|
|
|
|
| Re: subeditor change & save wipeout content of parenteditor [message #484360 is a reply to message #484235] |
Mon, 07 September 2009 08:20 |
Ralf Buschermoehle
Messages: 81
Registered: July 2009 |
Member |
|
|
Hm, optimally I would like to set this information in
... ViewProvider ...
public Diagram createDiagram(IAdaptable semanticAdapter,
String diagramKind, PreferencesHint preferencesHint) {
....
diagram.persistChildren();
....
Unfortunately this has no effect regarding the outcome (_diagram file).
Again, the initialized diagram in complete as long as I open and close
the diagram in the (runtime) eclipse environment. When I restart the
environment the diagram visualizes only the stored (layout) information
which is equivalent to all "touched" diagram elements (so far) -
sometimes of the same "level" (e.g., when I touched a class in a class
diagram all classes are presented in the diagram - but no attributes /
operations of the classes - unfortunately this does not transitively,
meaning: touching all attributes of a class does not persist all
attributes of the other classes).
Any hint would be nice ... :)
Greetings,
Ralf
Ralf Buschermoehle wrote:
> Hi Alex,
>
> Alex Shatalin wrote:
> > Right. Current implementation perform full diagram initialization from
>> the domain model on diagram openning. You can mode diagram element to
>> new location and shole diagram content will be persisted on next save.
>
> Hm, in my case it's not the whole diagram that is stored ... it stores
> only the parts that have been touched ... which is quite annoying when a
> larger diagram has been initialized.
>
>> To programmatically persist all diagram nodes yo uneed to call
>> Diagram.persistChildren().
>
> When should I call this? I set a debug point in
>
> protected void performSaveAs(IProgressMonitor progressMonitor) {
>
> but this is not called during save?
>
> Greetings,
>
> Ralf
|
|
|
|
|
|
| Re: (forcing) persist all diagram elements after "initialize diagram" [message #484792 is a reply to message #484593] |
Wed, 09 September 2009 10:32 |
Ralf Buschermoehle
Messages: 81
Registered: July 2009 |
Member |
|
|
Hi,
is it possible to introduce (missing) graphical elements
programmatically? I can check what model elements are represented in
relation to the domain model definition, e.g., a generalization
relationship between two classes is missing
System.out.println("Generalization hierarchy between " + clazz.getName()
+ " and superclass " + superClazz.getName() + " not found.");
Then I would introduce them
IElementType type = ElementTypeRegistry.getInstance().getElementType(model);
ViewAndElementDescriptor viewDescriptor = new
ViewAndElementDescriptor(
new CreateElementRequestAdapter(null),
ClassSuperClassEditPart.class,
null,
null);
CreateViewAndElementRequest request = new
CreateViewAndElementRequest(viewDescriptor);
CompositeCommand cmd = new CompositeCommand("introduce new element");
cmd.add((IUndoableOperation) modelEditPart.getCommand(request));
Would this be serialized? Unfortunately the command does not seem to be
totally correct?
Greetings,
Ralf
Ralf Buschermoehle wrote:
> Hi Alex,
>
> unfortunately I loose also all the "nice" features of synchronized
> diagrams as well ...
>
> I assume the complete _diagram is not generated (after "initialize is
> executed) because of minimalization purposes? Unfortunately the diagram
> is incomplete when the environment is restarted (in particular with
> child elements). Or do I miss some properties in .gmfgen? If not I
> assume this is an error?
>
> Greetings,
>
> Ralf
>
> Ralf Buschermoehle wrote:
>> Hi Alex,
>>
>> yes, that did the trick! :)
>>
>> Thanks again,
>>
>> Ralf
>>
>> Alex Shatalin wrote:
>>> Hello Ralf,
>>>
>>> Init diagram file action currently is creating new empty diagram
>>> only. The rest will be done by updater subsystem on first editor
>>> openning.
>>> If you need to persist diagram structure completely on first diagram
>>> openning then you have to do that in generated ???DocumentProvider
>>> class.
>>>
>>> Complete diagram structure initialization will be generarted into
>>> InitDiagramFileAction only if you are working with non-synchronized
>>> diagram, so a workaround for you can be to generate complete diagram
>>> code once again with "synchronized" property set to false for
>>> GenDiagran in .gmfgen model and then reuse InitDiagram file action
>>> generated there in your original code base instead of one you have now.
>>>
>>> -----------------
>>> Alex Shatalin
>>>
>>>
|
|
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.03385 seconds
] 
Search
Help
Register
Login
Home
