Deliberately set empty field about schema HOT 13 CLOSED

Any reason you can't simply set the field to "" before passing the struct to the decoder?

from schema.

I may be misunderstanding, but on lines 139-141 in decoder.go, it expressly ignores the value when it is set to "". This is not the same as unsetting the value. In my code, I'm taking a pre-populated struct and having the decoder overwrite the struct. If any of the incoming data is set to "", it'll just skip it instead of setting the written-to struct as empty string, which leaves the original value in place. Let me know if what you said is not what I seemed to have interpreted.

from schema.

Okay, let's see if I understand correctly:

You have a struct that is prefilled with data. If the form value for a field is "", you want it to blank out the corresponding field in the struct. The current behaviour just ignores the form value and leaves the field in the struct intact.

Is that the gist of it?

from schema.

That is correct.

from schema.

Okay, I get it then :) So I think the best way to do this is to add an option to the decoder that will clear the fields. We can't change the default behaviour because it may break existing usage.

from schema.

In my use case, it's important that any omitted fields (from a form post, for example) are just ignored, yet any actually empty but submitted fields are cleared. Do you believe that such a thing can be done without the hackery I've applied in my not-to-be-used commit I've linked above? I honestly haven't thoroughly evaluated the schema code, but it seems that the absence of a field is able to be known and that it could work out. I'll see about making a workable solution and we can discuss if it is a reasonable solution. I just want to be sure there wasn't already a best practice that doesn't suck (like pre-pre-processing my inputs, for example). Thanks.

from schema.

It should work out that way since we iterate over the keys in the map you receive from the form. If the key is not there we will never try to change the field.

from schema.

This is actually partially addressed in #12 , but the solution there is not quite complete (eg: it changes the default behaviour, and no tests yet), which is why I haven't merged it.

from schema.

Oh, hah. Well I didn't even see that one apparently. That'd be probably what I want on my end. What would be helpful for moving that forward? Anything I can do?

from schema.

It looks untested and probably incomplete. I merged his changes into my HEAD^ and I'll see about adding the test cases I care about. My time today is rather tight, so I hope I actually complete it. I'm going to close this issue and let RangelReale's issue #12 carry this forward as it seems to have compatible goals. Thanks.

from schema.

Thanks for the feedback though, now I have a pretty good idea of how that PR should work. I'd like to add another function to the decoder like dec.ZeroEmpty(). When called it will set a flag on the decoder. If the decoder encounters an empty string, it will check the value of the flag. If the flag is set, then it will set the field to the zero value as it does in that PR, otherwise it will ignore it.

from schema.

Sounds good to me. Would it be helpful for me to write the tests that I'm concerned about, or shall I wait until you've made proposed changes?

from schema.

Tests would definitely help, thanks.

from schema.