#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 )
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)
Change History (12)
comment:1 Changed 13 years ago by
Milestone: | → 2.0 |
---|
comment:2 Changed 13 years ago by
Summary: | Remove the mandatory requirement for curly braces to surround "constraints" in markup → Dijit 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 13 years ago by
Trac ate my square brackets in that last post for extraLocale:
extraLocale=['es']
comment:4 Changed 13 years ago by
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 13 years ago by
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:7 Changed 12 years ago by
Milestone: | 1.3 → 1.4 |
---|
bumping 1.4 tickets to 1.5, and most 1.3 tickets to 1.4
comment:8 Changed 12 years ago by
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 12 years ago by
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
comment:10 Changed 12 years ago by
Changed 12 years ago by
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 12 years ago by
Resolution: | → wontfix |
---|---|
Status: | new → closed |
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.
Hmm, I see your point.
Currently if the parser encounters a parameter like foo or bar
where foo and bar are declared as null or {}, like:
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.