Opened 13 years ago

Closed 5 years ago

#5703 closed defect (fixed)

Inconsistent naming dijit.form.TextBox but Textarea

Reported by: wolfram Owned by:
Priority: high Milestone: 2.0
Component: Dijit - Form Version: 1.0
Keywords: Cc: Douglas Hays, bill
Blocked By: Blocking:


TextBox (with a capital "B") but Textarea with small "a". It should be TextArea too, if i look at ComboBox?, etc. all other things are properly named camel case.

Change History (14)

comment:1 Changed 13 years ago by Adam Peller

Cc: Douglas Hays bill added

Perhaps doug remembers the discussion better, but we agonized over this in 1.0 and decided to leave it alone. We're probably stuck with it now. wontfix?

comment:2 Changed 13 years ago by wolfram

What about offering an alias? And may be deprecating it later? But I guess that had been discussed too :-)

comment:3 Changed 13 years ago by wolfram

dijit.Toolbar is the same, it should be dijit.ToolBar I know it hurts to see, but consistency is really helping easier development a lot, imho

comment:4 Changed 13 years ago by bill

Milestone: 1.1

comment:5 Changed 13 years ago by bill

Hi. In the back of my mind I meant for all this stuff to be proper cased, but I wrote #3838 poorly because I only mentioned *Box.

Searching for textarea or textarea within flash confirms that "TextArea" is more standard, and judging from MSDN, ToolBar and ToolTip should both be propercased too.

Obviously any such change would need a deprecation cycle until 2.0. Leaving this marked for 1.1 although could be moved to 1.2.

comment:6 Changed 13 years ago by Douglas Hays

dijit.Tooltip => dijit.ToolTip??

comment:7 Changed 13 years ago by Douglas Hays

What about function names? dijit/_editor/_Plugin.js: setToolbar: function() Easy to change but I'll have to create a deprecated function with the old name.

What about CSS class names? (there are lots for Toolbar, none for TextArea?)
.dijitToolbar, .dijitTooltipLeft, .dijitTooltipRight,.dijitTooltipDialog, et al
We could leave these alone but it would be a little confusing. If we change them, then deprecation is lost (assuming the user has overridden CSS rules). If we create duplicate rules with both old and new names, then there are code issues for when class names are generated to reflect widget states (disabled, hover, et al).

comment:8 Changed 13 years ago by bill

Milestone: 1.12.0

I'm deferring this to 2.0 when we are allowed to break backwards compatibility. Although it would be easy to do deprecation for changes to widget names (ie, class names) and method names, this task would also result in CSS changes (for Tooltip and Toolbar), and file name changes, which affect dojo.require() statements.

comment:9 Changed 13 years ago by alex

Milestone: 2.01.3

Milestone 2.0 deleted

comment:10 Changed 12 years ago by bill

Milestone: 1.32.0

comment:11 Changed 9 years ago by bill

Component: DijitDijit - Form
Owner: set to Douglas Hays

comment:12 Changed 7 years ago by Douglas Hays

Owner: Douglas Hays deleted
Status: newassigned

comment:13 Changed 7 years ago by Douglas Hays

Status: assignedopen

comment:14 Changed 5 years ago by bill

Resolution: fixed
Status: openclosed

Closing this as fixed in 2.0 because has tried to keep the naming consistent. Admittedly it doesn't have a Textarea widget yet, and not sure if it will, but all the *box widgets have a lowercase "b" because it "textbox" seems like one word.

Note: See TracTickets for help on using tickets.