Pick list _POST value a mess

[Bauer]

I used the picklist element added to a repeat group in a form for the first time the other day.

It all seemed to work well and the 'picks' got saved and re-shown correctly between form edits.

The problem came when I tried processing the $_POST value using the form PHP plugin.

This is the values shown for the picklist element when I do a var_dump of $_POST values...

["fb_breakouts___or_group"]=> array(1) { [0]=> array(1) { [0]=> string(24) "["[","ftes","states",""]" } }

What am I supposed to do with THAT string?

 

[cheesegrits]

What am I supposed to do with THAT string?

json_decode()

-- hugh

 

[Bauer]

json_decode()

-- hugh

Did you examine that string closely?
Here's the result (var_dump) of a json_decode on that "string"...

array(4) { [0]=> string(1) "[" [1]=> string(4) "ftes" [2]=> string(6) "states" [3]=> string(0) "" }

Surely it was not intended to be this way???
(And yeah, I know - quit calling you Shirley )

 

[cheesegrits]

You only asked what you are supposed to do with it. It's JSON. So you JSON decode it. Whether it makes sense or not depends on what your picklist values are / should be.

-- hugh

 

[Bauer]

Really? Find me another element (or any aspect of fabrik that uses json to store data) that returns a "json decoded" string that looks like that.

The value returned after decoding should be...
array(2) { [0]=> string(4) "ftes" [1]=> string(6) "states" }

I just love the way you always make excuses for bugs (that might be leading to other issues elsewhere). Maybe that's 'your job' - but I didn't just fall off the turnip truck.

And yes, I know how to pull the correct values out of that string - but that isn't the point.

 

[cheesegrits]

Where's the bug? You already said it saves and re-displays just fine.

I don't know why yours has that open [ in the first entry, mine doesn't. It always has a blank one, which is there specifically so even if you submit a picklist with no selections, it'll be a valid JSON array, not an empty string. The empty one in last place is there because you added and then removed something, which is something we strip out in the form processing, rather than dicking around in the JS un-defining array indexes.

So for instance, my test looks like:

"["","guitar","drums",""]"

... which is a perfectly valid, clear and understandable JSON string.

-- hugh

 

[cheesegrits]

Perhaps it'll make more sense if you look at the JSON "happening" in real time:

http://screencast.com/t/7FGcUzhEdU8

As you can see, it starts off as a JSON array with a single empty string, which just makes the initial encoding/decoding easier, so it's a valid array, and decoding it creates an array, not an empty string. When we process the JSON on submit, we just strip out any empty array entries.

-- hugh

 

[Bauer]

I wasn't 'complaining' about it not being saved and restored correctly - I was talking about it not playing well with javascript.

So I get it. I'm just saying - 'tricks' like that will always leave unknowing/unsupecting users in the dust. Like when the user is relying on using it with javascript and sees expected results like this rather than the array working like a normal json string/array conversion was designed/intended.

As far as the reasoning behind that - what's wrong with just checking if the var is empty? Empty array, empty string - it's still "empty" to php.

What confused me was the 'unmatched' ends - which you have now explained, thank you.