Community
Participate
Working Groups
I was about to implement a PropertyTester for Preferences, but think it would be better to have a Core Expression similar to "systemTest" for Preferences. It could look something like this: <preferences qualifier="" key=""/> This would be implemented as an CompoundExpression that puts the preference with the given qualifier and key as default variable on the evaluation context. This would allow to use <count/> on values from the preferences field, or to iterate over an array of preference values. Example: <preference qualifier="org.eclipse.ui" key="SHOW_PROGRESS_ON_STARTUP"> <equals value="true"/> </preference> <preference qualifier="my.plugin.ui" key="numberOfLines"> <count value="+"/> </preference> Also would it be possible to open up the Core Expression Framework to allow user defined Expressions to be integrated? I know the expressions are coupled with an XML schema for PDE. There could be an extension point "org.eclipse.core.expressions.expression" that allows the adding of new "Expression" implementations. You would have to give also a XML schema for your expression that PDE could use to offer Content Assist and validation.
Paul, what do you think?
This would also need a way to pass a scope context (e.g. for project-specific preferences).
Since I was thinking about using this in RCP only without projects you would have to help me how to pass a scope context for projects.
(In reply to comment #0) > I was about to implement a PropertyTester for Preferences, but think it would > be better to have a Core Expression similar to "systemTest" for Preferences. It > could look something like this: > > <preferences qualifier="" key=""/> > > This would be implemented as an CompoundExpression that puts the preference > with the given qualifier and key as default variable on the evaluation context. > This would allow to use <count/> on values from the preferences field, or to > iterate over an array of preference values. > > Example: > <preference qualifier="org.eclipse.ui" key="SHOW_PROGRESS_ON_STARTUP"> > <equals value="true"/> > </preference> > > <preference qualifier="my.plugin.ui" key="numberOfLines"> > <count value="+"/> > </preference> I'm not sure. I can see the usefulness of being able to access preferences from core expressions, but there are a number of design issues to be addressed: 1. guessing the contents of a preference ... or we simply deal with them all as strings. 2. new expression element, resolve support, or property tester? The only reason to use a new element or resolve is that you can transform the content in some way (other than equals). If we can only guess at the content of a preference, we'll get it wrong. 3. updating the IEvaluationService when something changes ... we either start listening to preferences and requesting updates or we make the client that wants to use preferences responsible for asking the system (not so good for declarative use, but will only request updates when a preference under consideration changes). PW
Well, Preferences can be String, Integer, Float and Boolean as far as I can see. But I see the difficulties. A property could be a String or an Integer and the <count/> expression would not be able to operate on a String. But the defaultVariable that the <preference> expression creates could adapt to ICountable and try to convert the String preference to an Integer. If this results in a NumberFormatException it would not be able to adapt. As for preference changes: The IEvaluationService should register a PreferenceChange Listener for each evaluated <preference> expression when it has evaluated at least once.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
