see #2421 for the original PR that changed the behavior.

@stloyd: Can you have a look at this side-effect?

@stloyd: I' m about to revert #2421. Have you had time to look into this?

@fabpot any news about the revert ?

We just found that the change broke the custom type in FOSUserBundle as it inherits from text and add a transformer

@fabpot: @stof is referring to FriendsOfSymfony/FOSUserBundle@6cbe4da. A user of OrnicarMessageBundle alerted me to this issue.

My commit message above mentions two possible solutions. Either inheriting field types clear the text type's transformer chain before appending their own, or transformers are rewritten to no-op for empty strings in addition to null. I was in favor of the former option.

Regarding #2421: Throwing an UnexpectedTypeException for non-string and non-numeric values (e.g. arrays, objects) seems like a non-essential convenience for the developer. The alternative is that you might end up seeing Array or an object's string representation printed in a text input field. I don't think it's too much to ask that developers catch that themselves -- and who's to say someone might not want to original behavior? Lastly, the role of the text type as a common parent should lead us to be very conservative about restricting its functionality.

The given test is invalid. You should use prependClientTransformer(), otherwise your transformer is chained after ValueToStringTransformer which already converted the value to a string.

@bschussek: If FOSUserBundle's UsernameToUserTransformer transformer was prepended to the stack (ahead of ValueToStringTransformer), I assume UsernameToUserTransformer::transform() would execute before ValueToStringTransformer::transform().

During reverse transformation, would ValueToStringTransformer::reverseTransform() be called first?

Exactly.

Btw, to keep heads from exploding, I suggest to rename it to UserToUsernameTransformer too, it makes things easier.

@bschussek, if that's expected BC break, then it should be documented in UPGRADE :)