Community
Participate
Working Groups
Wouldn't it be nice if we could extend the defined core expression language by our own "verbs"? Recently I needed a new core expression to evaluate preferences using the IPreferencesService. It would be nice if I could just implement an Expression and define an extension to (the not-yet existing) "org.eclipse.core.expressions.expression". In my extension I would describe the name of my verb being "preference" and its attributes would be "qualifier" and "key". As a further enhancement I could specify that "key" would have to be a String and that "qualifier" could have content assistant support where I would supply all the currently loaded bundles with their bundle-symbolicname as possible values for "qualifier". <expression name="preference" compound="true"> <attributes> <attribute name="qualifier"> <values><class name="PreferenceQualifierResolver"/></values> </attribute> </attributes> </expression> By specifying "compound=true" PDE would allow me to add sub expressions to my expression. The "values" for an "attribute" could describe a list of String values, or a class that dynamically returns a list of strings during runtime. PreferenceQualifierResolver would do something like this: class PreferenceQualifierResolver { String[] resolve() { List ids; for all loaded bundles ids.add(bundle.symbolic name); return ids.toArray(); } } An expression extension would also have to provide documentation that PDE can show to the user.
Paul, what do you think?
As a meta-question, where should we put core expressions bugs now? We can leave them in Platform Runtime with an "[expressions]" header if that makes sense for you Paul (and add you as CC and/or QA Contact).
Would be fine for JDT.
> As a meta-question, where should we put core expressions bugs now? Bugs should be in the component who "owns" the plug-in. Currently, that's JDT/UI, but it's fine for me to move it to Platform/UI if you also move the map file entry to ui.map and take over the tagging for builds.
(In reply to comment #2) > As a meta-question, where should we put core expressions bugs now? We can leave > them in Platform Runtime with an "[expressions]" header if that makes sense for > you Paul (and add you as CC and/or QA Contact). > I'm fine with that. PW
(In reply to comment #4) > > As a meta-question, where should we put core expressions bugs now? > Bugs should be in the component who "owns" the plug-in. Currently, that's > JDT/UI, but it's fine for me to move it to Platform/UI if you also move the map > file entry to ui.map and take over the tagging for builds. > I'm fine with moving it to core runtime and the appropriate map (John and I had talked about this before). PW
I think there are 2 possibilities here for contributions. Use an extension point and org.eclipse.core.expressions.ExpressionConverter to allow new structure to be read out of the IConfigurationElements. I did something similar when experimenting with bug 248140. The downside to this approach is the PDE tooling. It's easy to get warnings or errors about elements that don't belong, and AFAIK it would be impossible to provide the new elements to the PDE editor content assist. Use an extension point to plug in in new org.eclipse.core.expressions.IVariableResolvers. Then you wouldn't have new structural elements, but would be able to provide new variables with <resolve/> but just like variables used with <with/> there's no direct PDE support for that either. PW
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.
