Opened 14 years ago

Closed 13 years ago

Last modified 12 years ago

#5485 closed enhancement (wontfix)

Dijit should mimic the way Base requires objects and lists to be expressed in markup

Reported by: ptwobrussell Owned by: bill
Priority: high Milestone: 1.4
Component: Dijit Version: 1.0
Keywords: Cc: [email protected]…, [email protected]
Blocked By: Blocking:

Description (last modified by bill)

I just realized that the constraints attribute for dijits requires use of the curly braces i.e. constraints="{min:0,max:100}" while other stuff outside of dijit does not i.e. djConfig="parseOnLoad:true" I'm slightly confused by why that would be the case because it seem that the behavior should be identical in either case.

The error I'm seeing in Firebug when I don't use the enclosing {} is

SyntaxError?: missing ) in parenthetical message=missing ) in parenthetical.

Test case w/ 1.0.2:

<input dojoType="dijit.form.NumberSpinner" readOnly=true constraints="min:0,max:100" value=0>

Now, with that said, it looks like the documentation actually confirms that curly braces are required, so I realize that I'm not reporting a defect; however, I can't imagine why the syntax would need to differ. Unless there's a compelling technical reason to keep the curly braces, it seems that it would be much better to lose them. When people get used to one kind of syntax in Base and Core, this kind of difference can really trip them up when they come over to dijit.

Attachments (1)

5485.patch (61.9 KB) - added by bill 13 years ago.
possible patch to parser.js and all the test files, to parse "foo: {}" as a hash w/optional braces, but "foo: null" as full JSON

Download all attachments as: .zip

Change History (12)

comment:1 Changed 14 years ago by bill

Milestone: 2.0

Hmm, I see your point.

Currently if the parser encounters a parameter like foo or bar

<input foo=".."   bar="...">

where foo and bar are declared as null or {}, like:

foo: null,
bar: {}

Then it just treats the parameter as a javascript expression (ie, JSON). This allows the user to set the parameter to any value, such as 5 or [1,2,3] or of course a plain hash like {min: 0, max: 100} .

I don't think anyone is using that kind of functionality though, so I guess we could assume the parameter is a hash, and add curly braces if they aren't there. Or assume the parameter is a hash if the prototype declares it as {} rather than null.

comment:2 Changed 14 years ago by ptwobrussell

Summary: Remove the mandatory requirement for curly braces to surround "constraints" in markupDijit should mimic the way Base requires objects and lists to be expressed in markup

As a related note as it pertains to having a consistent API, I just noted another difference in how values are passed into dijits, which IMHO, raises the barriers to entry ever so slightly. This time though, it relates to lists of values.

Specifically, I know that in Editor, you provide plugins with enclosing brackets like so: plugins="['foo','bar']" whereas with Tooltip, you provide multiple connectId values without the brackets (and thus necessarily without embedded quotes) i.e. connectId="multiple,connect,ids,go,here"

My recommendation remains that Dijit should mimic Base's syntax, which is to provide the explicit brackets i.e. djConfig="extraLocale=es?"

comment:3 Changed 14 years ago by ptwobrussell

Trac ate my square brackets in that last post for extraLocale:


comment:4 Changed 14 years ago by ptwobrussell

Just noticed that Menu's targetNodeIds accepts a list of values like targetNodeIds="foo,bar,baz", which does not require square brackets. Logging this here so that it'll eventually aggregate to tell the whole story for dijit and show us where any inconsistencies are at.

comment:5 Changed 14 years ago by bill

djConfig is complicated; it's a hash which contains an array. I guess hypothetically to make things consistent across dojo/dijit/dojox (if we ignored backwards-compatibility), then hashes and arrays would be specified without the outermost curly or square brackets, but otherwise as a valid JSON string, for example:

djConfig = "isDebug: true, extraLocale: ['es']"
plugins = "foo, bar"
constraints="min:0, max:100"

Probably hard/impossible to get all the way there but probably can do something w/out breaking back-compat [too much].

comment:6 Changed 14 years ago by alex

Milestone: 2.01.3

Milestone 2.0 deleted

comment:7 Changed 14 years ago by bill

Milestone: 1.31.4

bumping 1.4 tickets to 1.5, and most 1.3 tickets to 1.4

comment:8 Changed 13 years ago by bill

Description: modified (diff)

Note that the editor's plugin and extraPlugin parameters are troublesome as they are arrays but with possible complex markup.

An abbreviated example from our test files:

plugins="['bold',{name:'dijit._editor.plugins.FontChoice', command:'fontName', generic:true},'insertImage']"

comment:9 Changed 13 years ago by bill

Another complicated case is the query attribute for data stores (passed to ComboBox, Tree, etc). Since that can be either a string or a hash, it needs to be declared in markup as unabbreviated JSON, like:

query="{name: '*'}"


query=" '/foo/bar/baz' "

However, the cases below would benefit from letting the user leave off the braces:

  • constraints parameter for form widgets (ValidationTextBox, Slider, NumberSpinner, etc.)
  • Declaration.defaults
  • FilteringSelect/ComboBox.fetchProperties
  • Chart2D.margins
  • BarGauge, AnalogGauge: majorTicks, minorTicks, background, color
  • InlineEditBox: editorParams

comment:10 Changed 13 years ago by bill

(In [17401]) Fix documentation of plugins/extraPlugins parameters, which are arrays that can contain Objects in addition to Strings.

Since these are not simple lists of strings they need to be expressed in markup with the [ and ], as a full valid JSON string.

Refs #5485 !strict.

Changed 13 years ago by bill

Attachment: 5485.patch added

possible patch to parser.js and all the test files, to parse "foo: {}" as a hash w/optional braces, but "foo: null" as full JSON

comment:11 Changed 13 years ago by bill

Resolution: wontfix
Status: newclosed

I'm going to close this ticket unless/until we can think of a good solution. It just seems like allowing

constraints="min: 0"

but not

query=" name: '*' "

will cause more confusion than it solves.

It's really a toss up though.

Note: See TracTickets for help on using tickets.