Opened 8 years ago

Closed 8 years ago

Last modified 7 years ago

#13854 closed defect (fixed)

Browser-specific patches undefine declaredClass

Reported by: Adam Peller Owned by: bill
Priority: high Milestone: 1.7
Component: Dijit Version: 1.7.0b1
Keywords: Cc: Douglas Hays
Blocked By: Blocking:

Description

dijit.form.TextBox has two browser branches (e.g. "dijit.form.TextBox.MozMixin") that declare an anonymous mixin based on TextBox and replace the original class definition. The declaredClass is lost. As a result, TextBox gets a declaredClass of uniq_nnn which breaks back-compat for apps expecting it to be "dijit.form.TextBox"

Setting TextBox.prototype.declaredClass = "dijit.form.TextBox"; after applying the branch fixes the problem. Not sure if that can be wrapped in the declare instead.

Change History (3)

comment:1 Changed 8 years ago by bill

Either

TextBox.prototype.declaredClass = "dijit.form.TextBox"

or adding

declaredClass: "dijit.form.TextBox"

to the prototype break the tests/_BidiSupport/form/robot/Textarea.html test, among others. In tests/_BidiSupport/form/test_Textarea.html, when the Textarea widgets are created _TextBoxMixin::_setTextDirAttr() calls applyTextDir(), but that call goes to the empty _WidgetBase.applyTextDir() rather than the _BidiSupport.applyTextDir() method.

Last edited 8 years ago by bill (previous) (diff)

comment:2 Changed 8 years ago by bill

Owner: set to bill
Resolution: fixed
Status: newclosed

In [26473]:

TextBox.js declares an initial "TextBox" class, but depending on the browser either returns that class or a subclass. In both cases, for the user's benefit, the returned (aka public) class must have declaredClass == "dijit.form.TextBox?". Conversely, in the case where there is a base class and a subclass, the base class must *not* have declaredClass == "dijit.form.TextBox?", as this breaks inheritance.

On the flip side, regardless of whether or not there is a subclass, we need the base class to appear in the documentation as dijit.form.TextBox?.

This change hopefully achieves that.

Fixes #13854 !strict.

comment:3 Changed 7 years ago by bill

In [28599]:

Use simpler design to implement TextBox browser specific code paths.

Colin fixed the doc parser to understand the old design (ie, a TextBox base class and browser specific TextBox subclasses), but this new design seems easier for the doc viewer, and given browser-specific builds, I don't see that one design is better than the other.

Refs #13854 !strict

Note: See TracTickets for help on using tickets.