Namespace handlers via injection

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

Peter Yee has been working hard on integrating the Dojo build system
with our own so we can build profiles that we can build different
profiles for different types of applications.

In addition I have been thinking more about minimal builds. For example
if someone wants to use macros rarely or not at all can they simply
leave those out of the build?

Currently the answer is no because the ClientSession object requires the
NamespaceHandlerManager, which in turns requires handlers for each
namespace like mco, macro, etc.

My proposal is that have a core set of functionality then any particular
namespaces we handle are injected rather than included by default. I was
playing with the XapConfig.xml file and changed it to look like this:

	<plugins>
		<plugin-file file="src/xap/taghandling/plugin.xml"/>
		
		<!-- assume require on this name will work -->
		<plugin-class class="xap.mco.McoNamespaceHandler"/>
		<plugin-class
class="xap.xml.xmodify.XmodifyNamespaceHandler"/>
		<plugin-class class="xap.macro.MacroNamespaceHandler"/>
		<plugin-class class="xap.xml.XalNamespaceHandler"/>
	</plugins>

Basically what this says is load the file
"src/xap/taghandling/plugin.xml" and instantiate the 4 classes. These 4
classes when loaded configure themselves to be part of the overall
framework.

If you didn't want to use macros at all, you could simply leave out the
entry for MacroNamespaceHandler and leave it out of your Dojo-style
profile.

This is also nice in that if we or end users want to add their own
namespace handlers later they can do so. In fact they can add any old
classes that will get instantiated and passed a session to.

This last point is key. If the user simply wants to include their own
files they can without using this mechanism, but these classes can
follow the contract that allows us to inject a session into them so they
can do things like add themselves to the list of namespace handlers. We
want a lot of functionality scoped to the current session rather than
the current window object so simply having files perform some operation
when they are loaded is not sufficient - they need some indication of
the current session.

These objects could also dynamically add methods to the session object.
For example instead of a getMcoContainer() on session we could
dynamically add that method if MCO support is included. The downside
there is that it makes documentation a bit messier.


Proposal in short:
1: XapConfig.xml allows you to specify tag-handling file (which was
previously hardcoded for the time being)
2: XapConfig.xml also allows you to specify classes that will be
instantiated and then called with the current session.
3: Using this mechanism you can add your own handlers for new namespaces
and provide a variety of other functions as well. Each of these classes
is the root for a plugin that exposes some new functionality.
4: Along with this you can build you own Dojo-style profiles to include
in the large concatenated file whichever of these files you wish.
5: This will allow us to package a core set of functionality and let
user pick, choose and add their own functionality on top of that.
6: This defines a standard way to extend the base functionality with new
tags, functions, etc.

I have this working on my machine and it works well. I like the general
approach of having a core with plugins, it is similar to the way Eclipse
works as one example.

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) ;
      }
}

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

New tag put down, next steps

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

I created a "milestone2" tag should represent a stable copy while work
starts on some refactoring and widgets.

"milestone2" contains the changes Peter Yee contributed to use the Dojo
profile building process. As a result applications should load much
faster. The website is being updated with the new examples.

Now that the tag is down the next step is to begin work on the real XML
syntax and corresponding widgets. I put down a tag because a lot of this
work will likely break or obsolete many of the existing samples.

James Margaris

RE: Namespace handlers via injection

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

 
The naming should probably change.

I do like the name plugins, because that is what the overall idea is.
One question is for a tag-mapping file is there anything in it besides
the tag mappings? Right now the tag-mapping files just have tag mappings
and an optional class you can intialize when the file is loaded, similar
to the <plugin-class> thing. If want to eventually include other info
tag-mapping-file might not be a good name anymore. Maybe
plugin-descriptor or something like that would be better.

James


-----Original Message-----
From: Michael Turyn [mailto:MTuryn@nexaweb.com] 
Sent: Tuesday, August 15, 2006 10:47 AM
To: xap-dev@incubator.apache.org
Subject: RE: Namespace handlers via injection

Very good; just what we need.

Minor snipes----how about changing
	plugin-file
to 
	tag-mapping-file
or something equally descriptive,

and
	<plugin-class class="A">
	<plugin-class class="B">

to something more like:
	<init-load-classes>
		<class name="A">
		<class name="B">
	</init-load-classes>
...?

(There might also be a use for an optional "src" parameter as well as a
"name", not that I can justify it now.)

But, again, very good; we obviously would need something like this at
some point, and biting the bullet (before legacy code would have to be
accomodated) would probably be a good idea.
			

RE: Namespace handlers via injection

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

Very good; just what we need.

Minor snipes----how about changing
	plugin-file  
to 
	tag-mapping-file 
or something equally descriptive,

and
	<plugin-class class="A">
	<plugin-class class="B">

to something more like:
	<init-load-classes>
		<class name="A">
		<class name="B">
	</init-load-classes>
...?

(There might also be a use for an optional "src" parameter as well as a
"name", not that I can justify it now.)

But, again, very good; we obviously would need something like this at
some point, and biting the bullet (before legacy code would have to be
accomodated) would probably be a good idea.