[OpenAjaxIDE] Simplify onchangePattern

Bertrand Le Roy Bertrand.Le.Roy at microsoft.com
Thu Aug 14 14:32:24 PDT 2008


I think that pretty much removes all advantages of having a pattern. For example, the pattern for a given library could be to publish a message on a hub object (see where I'm heading with that?), something like:
HubObject.publish("{{property}}_changed", { target: {{target}}, value: {{value}} });

As a mitigation of the legitimate performance concern, could we detect the presence of {{target}} and {{value}} in the pattern and fall back to the implementation you mention if not there?

Also, I'm not convinced you couldn't do the full pattern efficiently if you have a few constraints on the form of the pattern. For example, if we transform the above pattern to:
HubObject.publish({{property}} + "_changed", { target: {{target}}, value: {{value}} });
You could "compile" it once into the following function that you'll call for each actual event:
function(property, target, value) {
HubObject.publish(property + "_changed", { target: target, value: value });
}

The other examples you mention work too:

{{target}}[{{property}}].changed({{value}})
Can be compiled to:
function(property, target, value) {
target[property].changed(value);
}

{{target}}["on" + {{property}} + "Change"]({{value}})
Gets compiled to:
function(property, target, value) {
target["on" + property + "Change"](value);
}

The constraint is that the pattern is valid JavaScript code once the target, property and value placeholders have been replaced (we could even simplify that to say that the pattern is just the body of a function of property, target and value).

From: ide-bounces at openajax.org [mailto:ide-bounces at openajax.org] On Behalf Of Jon Ferraiolo
Sent: Thursday, August 14, 2008 1:51 PM
To: ide at openajax.org; gadgets at openajax.org
Subject: [OpenAjaxIDE] Simplify onchangePattern


Due to implementation experience with the open source reference implementation, some of the engineers would like to see changes to onchangePattern. Right now, we allow the following example:

<property onchangePattern="{{target}}.{{property}}.changed({{value}})" ...>
...
</property>

But the developers are saying the {{target}} and {{value}} are problematic and not worth the effort. The way onchangePattern is formulated now, a mashup tool has to construct a string and then perform an eval() on it. That can lead to slow performance and you generally want to avoid eval() due to security concerns (possibility of code injection). We don't really need all of the flexibility offered by {{target}} and {{value}}, so the proposal is to get rid of them. (OK to keep these {{target}} and {{value}} for getterPattern and setterPattern.)

The most important requested change is to have the pattern represent a function name only (i.e., remove the custom scope object and remove the custom parameter list) and therefore remove {{target}} and {{value}} from this attribute. For example:

<properties onchangePattern="on{{propertyUCFirst}}Change" ...>
...
</properties>

Therefore, the onchange callback function will have use its own instance of its jsClass (or default wrapper class) as the "this" object, and the callback function must be on the "this" object. The onchange function must take a single parameter, which is the new value for the property. For example, under the hood, the mashup editor would invoke the following wheneven the 'color' property changes:

this['onColorChange'].call(this, newcolor);

Another possible change to consider: Only allow 'onchangePattern' on container elements such as <properties> and remove it from <property> or change its name on the <property> element from 'onchangePattern' to 'onchange' and disallow the use of {{value}}.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/ide/attachments/20080814/a23d4296/attachment-0001.html 


More information about the IDE mailing list