The Dojo Widget system offers greate flexibility and customizability. That said, its evolution over the past year has led us to believe that we need some significant refactoring and reworking to make it easier to use, manage, and build widgets. This page will be the summary of information and ideas related to the refactoring.

Instantiation/inheritance/debugging

Under the hood nomenclature makes it difficult to get started, and easy to make mistakes

API unification for common actions across widgets

Container, replacement, add-on, and fromScript approaches

CSS interning, inheritance, themes

conditional templates based on browser, widget instantiation conditions, etc.

External widget registration / namespaces - Alex (but looking for a volunteer)

Goals

• easier interface to register external widgets (See http://dojotoolkit.org/~psowden/newapis.html#ns and http://trac.dojotoolkit.org/ticket/40 for details)
• support widget namespaces, so you can say dojoType="ids:Foo"... (see above link for API to declare namespaces)
• templatePath shouldn't be in the context of dojo root?

Status: discussion finished, ready to implement

Refactor inheritance / packaging - Dylan

Goals

• make it easy to write widgets (without code duplication) for the different browser environments (which support svg/vml/etc. in addition to plain html)
• leave door open for future widget support such as running swing widgets from rhino
• fix confusing directory structure (some widgets are in html/ and some are just in widget/)?

The suggestion was to refactor the widget inheritance as per http://trac.dojotoolkit.org/ticket/73

This was the subject of a long discussion on 2006/01/07 and in the end it wasn't clear if it was a good idea or not.

One point we all seemed to agree on was that we should split up widgets based on rendering environment, rather than by "html", "svg", and "vml". For example, safari and firefox are "html+svg+canvas", and IE is "html+vml", whereas konqueror (I could be wrong) is just "html". But that was more of a packaging issue than an inheritance issue.

Another suggestion was that widgets should be instantiated via new() rather than by createWidget():

	var menu = new Menu(/* args */, domNode);

Menu would then do mixins, etc., to provide the right functionality depending on the rendering environment (ie, which browser it was running in.)

The behavioral widget question was also on the table (behavioral widgets don't replace the original dom node).

http://staff.vbi.vt.edu/dmachi/structure-irc.log

Mapping from domNode to widget object - Bill

Set a widgetId property on the DOM node, which we can use to quickly look up the widget. I think we'll need to do something like this for high-speed lookup of widgets from events anyway.

Refactoring path resolution

As discussed on todays irc (03/09/2006), a plausible solution has been derived that should fit most use cases.

Previous tickets created to reference are http://trac.dojotoolkit.org/ticket/504, http://trac.dojotoolkit.org/ticket/501, http://trac.dojotoolkit.org/ticket/40.

Root namespace definitions

The ultimate conclusion was that everyone wanted to be able to reference resources in an intuitive way, such that if you have a widget being defined in myNs/widgets/FooWidget.js, defining a cssPath for that widget should only have to be something like

cssPath = dojo.uri.uri("templates/FooWidget.css")

The hardest part to figure out is breaking the dependency on having everything resolve back to dojo..So the new methodology would be that everyone, including dojo, needs to define their own baseRelativePath for a particular namespace. So, the baseRelativePath config value would go away, at least in its current general form. The new method would be some form of

djConfig{ myNameSpacePath: "../javascript/myNameSpace", dojoNameSpacePath: "../javascript/dojo" }

Something close to that. Then, all resources can be relatively resolved to ~that~ namespace root path, if the context of where they are defined is something that lives under that namespace. It was suggested that the dojo.provide() method be used to establish relativety. It seems like a point that will be quickly resolved once implementation details are ironed out.

I plan on writing most of this up tomorrow (03/09/2006) starting in the morning (EST). (jesse kuhnert) Will post back what happens to someone when there is something to see.