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

[ptwobrussell]

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.

[bill]

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.

[ptwobrussell]

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?"

[ptwobrussell]

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

extraLocale=['es']

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

[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].

[alex]

Milestone 2.0 deleted

[bill]

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

[bill]

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']"

[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: '*'}"

or

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
• FisheyeLite.properties
• FilteringSelect/ComboBox.fetchProperties
• Chart2D.margins
• BarGauge, AnalogGauge: majorTicks, minorTicks, background, color
• InlineEditBox: editorParams

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

[bill]

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

[bill]

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.