Old codes relied on some assumptions, so:
* When a "key in form descriptor" is provided, the 'name' param can't be set otherwise the js wouldn't be able to find it.
* When a "name for submission" (with 'wp' prefix or same as the 'name' param) is provided, it works on the client-side but something might be broken on the server-side.
Since the documented usage is to use "key in form descriptor" and most use case is fine, the use of "name for submission" is explicitly disallowed here.
Use cases simply with the 'wp' prefix would still keep working on both sides though.
Depends-On: I27fd8fa9643d611b37e3f47e77b698245814d539
Change-Id: I9a42417a6161f42181badd8cdbec81ba85dc62f6
Values loaded from the default wouldn't be inverted, there is no need to copy the conditions to here, we can just simply bypass them.
Fortunately, nothing can be affected in a normal use case, since all value of fields would be set to server.
Thanks to the newly added tests, which helped me to realize this problem.
Change-Id: I5589ba7383587afdd9307c79e88849dacee02706
Fields can have some filter to process the data, for example, HTMLCheckField would return true rather than raw string '1', we should also test this.
Note that the param indicating 'checked' state is matching the state on client-side, the value would be inverted by HTMLCheckField...
Change-Id: Ia9a7a8c46b0a55ecf2d5378a0d0b6cc00cdb54eb
Follow-up changes will use cond-state params in other functions, split this out to make sure it's validated.
Change-Id: Icf358794b11a8f986fbd02c8f1b15ea9d1ef4d15
