Bug 478282 - XtextResource is not formatted when being saved by Sirius
Summary: XtextResource is not formatted when being saved by Sirius
Status: NEW
Alias: None
Product: Sirius
Classification: Modeling
Component: Core (show other bugs)
Version: 3.0.0   Edit
Hardware: PC Windows 7
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Project inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords: triaged
Depends on:
Blocks:
 
Reported: 2015-09-24 05:32 EDT by Niels Brouwers CLA
Modified: 2016-07-11 06:17 EDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Niels Brouwers CLA 2015-09-24 05:32:59 EDT
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.
Comment 1 Cedric Brun CLA 2015-09-24 05:48:11 EDT
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 ?
Comment 2 Niels Brouwers CLA 2015-09-24 06:46:48 EDT
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.
Comment 3 Maxime Porhel CLA 2015-10-05 10:05:15 EDT
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.