I have setup up a demonstration of this weird behaviour on the Sandbox.
_template code:
[[form]]
fields:
day:
before: Day
type: select
default: james
join: true
values:
james: Select
01: 1
02: 2
03: 3
04: 4
05: 5
06: 6
07: 7
08: 8
09: 9
10: 10
11: 11
12: 12
13: 13
14: 14
15: 15
16: 16
17: 17
18: 18
19: 19
20: 20
21: 21
22: 22
23: 23
24: 24
25: 25
26: 26
27: 27
28: 28
29: 29
30: 30
31: 31
month:
before: Month
type: select
default: 00
join: true
values:
00: Select
01: Jan
02: Feb
03: Mar
04: Apr
05: May
06: Jun
07: Jul
08: Aug
09: Sep
10: Oct
11: Nov
12: Dec
[[/form]]
Actual results
When trying to create a new page (click here), there are a few issues:
- The default day selected is "9" instead of "Select"
- The default month selected is "Sep" instead of "Select"
- The HTML source code reveals that all “values” (hint, VALUE=01, not "Jan") have had their leading zeros removed
- The HTML source code reveals that option 08 has been removed entirely
- The HTML source code reveals where val="09" should be is instead val="0"
It's all very confusing. I think it has something to do with leading zeros.
I realise that I could simply remove the leading zeros, but I do require leading zeros for my date formatting (so I don't have any options other than reporting this bug and waiting patiently).
You can put the values in quotes:
Kenneth Tsang (@jxeeno)
That fixes it!
Although the original problem still exists…
Like value "08" being stripped out entirely. And value "09" being transformed into "0", and then selected as the default option.
λ James Kanjo
Blog | Wikidot Expert | λ and Proud
Web Developer | HTML | CSS | JavaScript
Looking at this with my database manager hat on you need to consider each value as a row in a table. And in this case the row numbers start at 1. You can't use your own syntax with this: it is expecting 1,2,3…
So using row numbers this works properly:
So it's not actually weird behaviour: it's just that you were using an incorrect syntax the database was not expecting: not using row numbers and mixing datatypes james and 01. So you got a weird result.
Note the default is the row number.
Rob Elliott - Strathpeffer, Scotland - Wikidot first line support & community admin team.
Don't have any spares of those hats hanging around do you? =D
λ James Kanjo
Blog | Wikidot Expert | λ and Proud
Web Developer | HTML | CSS | JavaScript
Here ya go mate - what every Wikidot guru/data manager should be wearing this season
Rob Elliott - Strathpeffer, Scotland - Wikidot first line support & community admin team.
Did you know that when you pre-pad a number with a "0" you switch to octal system? It is valid in most programming languages I know, including PHP. Apparently YAML also parses it this way.
Things go crazy when you enter 08 and 09 since they are not valid octal numbers and the YAML parser silently change them to 0.
To test this, enter any valid octal number, e.g. 011 (which is 9 in decimal) - and you will get 9.
If you want your keys in the format "0<number>", use quotation marks and treat keys as strings, as tsangk suggested. There is no other way, neither in forms, or any other reasonable database or key-value store.
A tricky one! Cheers! :-D
Michał Frąckowiak @ Wikidot Inc.
Visit my blog at michalf.me
Ahh, thankyou for that education!
I think that it might be something worth documenting… would you agree?
Doesn't necessarily need to document octal numbering, but perhaps something along the lines of:
λ James Kanjo
Blog | Wikidot Expert | λ and Proud
Web Developer | HTML | CSS | JavaScript
We will look into this tomorrow and see if it needs to be documented.
Michał Frąckowiak @ Wikidot Inc.
Visit my blog at michalf.me
But only if you are using numbers in a 01,02,03 format rather than 1,2,3 which works fine.
Rob Elliott - Strathpeffer, Scotland - Wikidot first line support & community admin team.
Either way, I am rejecting this as a bug since it is not. Thanks for the discussion!
Michał Frąckowiak @ Wikidot Inc.
Visit my blog at michalf.me