Community
Participate
Working Groups
When an XtextResource is saved by Sirius, the Xtext formatter is not being invoked. In our situation, users use either the textual representation implemented with Xtext or graphical representations implemented with Sirius to maintain the model. Our rationale is that whenever the user uses the textual editor, formatting of the document can be customized to the needs of the user. However, when switching to the graphical editor, customization of the formatter plays no role so we would have format the resource always by invoking the Xtext formatter on the resource. Furthermore, we persist the model to text to ease textual diff/merge. Also for this reason invoking the formatter by default is required. I've implemented the functionality to always format a XtextResource when it's being saved by Sirius by overriding the XtextSavingPolicy class that's contained within the Xtext integration feature: public class XtextSavingPolicy implements SavingPolicy { private final SavingPolicy delegate; /** * Create the saving policy. * * @param delegate * the delegate which is going to be called for the save * operations, but with Xtext specific options. */ public XtextSavingPolicy(SavingPolicy delegate) { this.delegate = delegate; } @Override public Collection<Resource> save(Iterable<Resource> resourcesToSave, Map<?, ?> options, IProgressMonitor monitor) { Map<Object, Object> newOptions = Maps.newHashMap(); if (options != null) { newOptions.putAll(options); } // added format option to make sure the XtextResource is formatted during the save. newOptions.putAll(SaveOptions.newBuilder().noValidation().format().getOptions().toOptionsMap()); return delegate.save(resourcesToSave, newOptions, monitor); } } My proposal is to add this option by default in the XtextSavingPolicy shipped with the Xtext integration feature.
Hi, on the other hand we want to make sure that *by default* there is not a single change in the serialization (including formatting) if there has been no "logical" change in the model. Here is an example scenario for this: - opening a project with an Xtext model with a formatting which is different from the formatter result. - this project should also have another model (Ecore, whatever..), a change should be made to this other model - Save => the Xtext file should not have been changed. - Apply some change on the Xtext model using Sirius, revert this change (like renaming in "Something" and then back to the original Value) - Save => the Xtext file should not have been changed. Does that fit with your own scenario ?
If I understand correctly, you define two scenario's: 1. Modifications to the other non-Xtext model should not result in saving the Xtext model, and as a result not invoking the formatter on the Xtext model as well. 2. Any in-memory modifications to the Xtext model (actually the intermediate EMF representation) by the Sirius editor should not lead to saving the Xtext resource, and as a result not invoking the formatter. Saving the resource and thereby invoking the formatter is initiated when the user saves modifications made to the diagram. If this is correctly understood, than this is also exactly what we want and the scenario would fit.
Note that: . doing a non-touch modification on a resource will mark it as modified (org.eclipse.sirius.business.internal.resource.ResourceModifiedFieldUpdater) . undoing it or doing a set of operations resulting in the same model state will not remove the modified state The the isModifiedSavingPolicy (which will be the delegate SavingPolicy in the XtextSavingPolicy constructor) will use the Resource.isModified field to determine if a resource needs to be saved or not.