Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 360354

Summary: [ui] Introduce Property/Preference Pages
Product: [Modeling] OCL Reporter: Ed Willink <ed>
Component: CoreAssignee: OCL Inbox <mdt-ocl-inbox>
Status: CLOSED FIXED QA Contact:
Severity: normal    
Priority: P3    
Version: 3.2.0   
Target Milestone: M6   
Hardware: PC   
OS: Windows Vista   
Whiteboard:

Description Ed Willink CLA 2011-10-09 09:01:52 EDT 
In Bug 360072 the built-in delegate URI bindings were inflexible suggesting that a user selection should be permissible.

Another built-in selection is the URI emitted by the OCLinEcore editor/pivot2ecore translator. 

----

For existing Parsing/Evaluator options, users/applications must use Java poking. This is inconvenient when using QVTo that fails to suppress the 'non-standard closure' warning.

Providing per-project/workspace settings seems helpful.

----

The current Xtext editors use a communal OCL Preference page to avoid cluttering the top level entry. This is currently a dummy page defined by the Essential OCL plugin. An independent plugin is needed to provide a communal root for all editors and possibly the console(s) and ....

----

Suggest introducing an org.eclipse.ocl.ui plugin for these pages.
Since it's a new 'core' plugin, I think it can go straight in as non-examples. It's probably easier to discuss content by reviewing a prototype. For each option, there is a compromise between giving the users flexibility and giving them freedom to do something stupid.
Comment 1 Ed Willink CLA 2011-10-13 05:24:08 EDT 
branch bug/360354 has an implementation with

Workspace and project-specific pages for all options except:
- class-valued options - needs an Object browser FieldEditor

Use of Workspace options as the defaults when an OSGI PreferenceService is available.

Still to do:
a FieldEditor for class-valued options
foldable sections like the JDT compiler options
use of project-specific options as the defaults

?? How can the IProject be discovered from an EvaluationEnvironment, BasicEnvironment ??

A new setProject API is possible but wouldn't be in use by OCL-based tools.

For an EvaluationEnvironment, the IProject containing the context object might be a plausible guess.

For a BasicEnvironment the contextProperty/Class/... may be plausible.

So I suggest a new setProject API for applications that are prepared to specify it, and a fallback to the project of the context otherwise. The workspace defaults are determined by the built-in defaults so the only compatibility hazard I see is when a spurious project that specifies project-specific preferences manages to confuse another OCL activity, but that spurious project must be new functionality, so it's not a legacy usage.
Comment 2 Ed Willink CLA 2012-03-08 07:48:23 EST 
An updated contribution is available in the bug/363639 branch.
Comment 3 Ed Willink CLA 2012-05-02 15:06:19 EDT 
On master for M6.
Comment 4 Ed Willink CLA 2013-05-20 11:37:13 EDT 
CLOSED after a year in the RESOLVED state.