[eclipse-incubator-e4-dev] Fw: [platform-ui-dev] Extending core expressi

[Mike Wilson <Mike_Wilson@xxxxxxxxxx>]

Forwarded to e4 list, for wider visibility.

Wow, that's very cool Paul! I like the direction, but I can't make up my mind whether this is a stand-alone idea, or something that needs to be fit into the larger picture. For example, on the e4 side, how would this relate to the idea of doing a whole "plugin.js"?

Even in 3.x, it would be easy for me to believe that replacing a bunch of core _expression_ xml with a call to a Java class could be a performance win, as long as you can run it without activating plug-ins.

McQ.

----- Forwarded by Mike Wilson/Ottawa/IBM on 10/10/2008 15:56 -----

From:	"Paul Webster" <pwebster@xxxxxxxxxxxxxxxxxxx>
To:	"Eclipse Platform UI component developers list." <platform-ui-dev@xxxxxxxxxxx>
Date:	10/10/2008 15:36
Subject:	[platform-ui-dev] Extending core expressions with java and _javascript_

---

While working on bug 248140 [1] I began fooling around with extending
core expressions to support other syntaxes than XML.  The core
expressions plugin supports plugging in a number of different
_expression_ generators, and it turned into comment#3 [2].

Specifying <_expression_ script="java"
expressionClass="z.ex.label.untouchable.MyExpression"/> and providing
a subclass of org.eclipse.core.expressions._expression_ was easy to do.
Existing OSGi support (Bundle-ActivationPolicy: lazy;
exclude:="z.ex.label.untouchable") can be used to insure that this
class doesn't cause plugin loading, although care has to be taking
that it doesn't reference any other classes in the bundle.  I'm not
sure what a best practice would be while coding, but you at least get
JDT support while writing the _expression_.

Plugging in something like _javascript_ was a little harder (in the
setup) but still relatively easy:
<enabledWhen>
  <_expression_ script="js">
<![CDATA[
function uses(info) {
  info.addVariableNameAccess("activeContexts");
}

function evaluate(context) {
  var result = context.activeContexts.contains("z.ex.menu.actionSet1")
    || context.activeContexts.contains("z.ex.menu.actionSet2")
  return result;
}
]]>
  </_expression_>
</enabledWhen>

I find this interesting especially if the script syntax could easily
specify a bundle .js file to load, since that would allow JS tools to
be used for writing the expressions in the .js file.  It would be cool
to see the performance impact.

This was an interesting experiment, but aside from the coolness of
including _javascript_ or my own personal preference for Java core
expressions over declarative XML, I'm not sure how much benefit
something like this could add to 3.x.  We might discuss it at our next
UI call.


We're still investigating how _javascript_ (and other languages) will be
used in e4, and what their place will be.

----
[1]  https://bugs.eclipse.org/bugs/show_bug.cgi?id=248140
      [Commands] resolve can use org.eclipse.core.variables.dynamicVariables
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=248140#c3

-- 
Paul Webster
Hi floor.  Make me a sammich! - GIR
_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev