Ticket #5703 (new defect)

Opened 10 months ago

Last modified 24 hours ago

Inconsistent naming dijit.form.TextBox but Textarea

Reported by: wolfram Owned by:
Priority: normal Milestone: 2.0
Component: Dijit Version: 1.0
Severity: normal Keywords:
Cc: doughays, bill

Description

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

Changed 10 months ago by peller

  • cc doughays, 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?

Changed 10 months ago by wolfram

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

Changed 10 months 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

Changed 10 months ago by bill

  • milestone set to 1.1

Changed 10 months 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.

Changed 10 months ago by doughays

dijit.Tooltip => dijit.ToolTip??

Changed 10 months ago by doughays

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).

Changed 10 months ago by bill

  • milestone changed from 1.1 to 2.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.

Changed 9 months ago by alex

  • milestone changed from 2.0 to 1.3

Milestone 2.0 deleted

Changed 24 hours ago by bill

  • milestone changed from 1.3 to 2.0
Note: See TracTickets for help on using tickets.