Responding to attribute changes

[James Margaris <jm...@nexaweb.com>]

One of the the core facets of our framework is the ability to respond to
attribute change events on XML element. For example if someone changes
the "text" attribute to something on a button we want the text of the
button to change.

Originally I coded this as a big if/else statement. After doing some
testing it turns out the performance on if/else isn't so good, and it
can get a bit hard to read as well.

I was thinking instead it would be nice to have attributes map to
functions that handle them, via some standard naming scheme. For
example:

"text" -> setText()
"color" -> setColor()

So when an attribute on an Element changed, we would just look for the
setter of the same name on the bridge class and call it. 

I want to do a bit of performance testing to see how much better or
worse this is, but from a code organization perspective it seems a lot
nicer.

Thoughts?

James Margaris

RE: Responding to attribute changes

[James Margaris <jm...@nexaweb.com>]

Basic performance results:

In Mozilla, the lookup method is about 20% slower than a big if/else.

In IE, the lookup method is more than 15 times faster!

Does this sound right to anyone? I'll check in the unit test in a bit, I
am using the same test for both. It seems to be working properly, my
conclusion right now is that if/else is just amazingly slow in IE for
some reason, at least for strings. (I tried == and === as well, no
difference)

James Margaris

RE: Responding to attribute changes

[Michael Turyn <MT...@nexaweb.com>]

I'm a big fan of mapped callback functions in JS, to the extent that I'm
actively trying not to become a crank on the subject.

Still, coming from Java, if I'm going to have to do without type-safety,
and most early error detection, and the sort of optimising compilation
that probably does exactly this sort of mapping for big if/else's, I
want to make full use of functions as first-class objects and a decent
object field look-up speed.

So the short answer is:  I'm on it.  I implemented it one way
(attributeSet would automatically look for a setter method on the peer),
but on reflexion I think looking for a method on the bridge would be
better---for one thing, a bridge's schema then immediately gets
reflected in its setters and its superclass':


FryerWidgetBridge
===================
allowed attributes: width, height, x, y, temperature, crispiness
method[s] implemented in class:  setCrispinessAttribute
method[s] implemented in abstract superclass CookerToolkitBridge: 
 
setWidthAttribute,...setXAttribute,...,setTemperatureAtrribute


This is a convention-dependent mechanism, but it should be easy to
short-circuit it for
any bridge for which we want to do something special:

PlotBridge.prototype.attributeSet = function(attributeChangeEvent){
	// If it's a special event, do something special....
	if( event.getName() == "stooge" && event.getValue()="Pinky"){
		this.setTakeOverTarget("The World") ;
	} else {
		// otherwise, fall back on the conventional method
implemented 
		// in AbstractBlackBoxWidgetBridge:
	
xap.bridges.basic.AbstractBlackBoxWidgetBridge.prototype.attributeSet.ca
ll(this,event) ;
      }
}