Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[xdata] Do not lookup fields of forms without FORM_TYPE in registry #462

Closed
wants to merge 3 commits into from

Conversation

Flowdalic
Copy link
Member

No description provided.

@Flowdalic Flowdalic changed the base branch from master to 4.4 February 21, 2021 12:04
@fenuz
Copy link

fenuz commented Feb 23, 2021

This nearly allows the use of forms without a FORM_TYPE. However there is still one case that gives unpredictable results:

When you parse a form without a FORM_TYPE, containing a field without a type, it will use the field type of a registered field with the same name. Instead it should use the default field type text-single.

Created PR Flowdalic#25

@fenuz
Copy link

fenuz commented Feb 23, 2021

Would you consider relaxing the requirement for a FORM_TYPE in the FilledForm class as well? It would allow the FilledForm and FillableForm API to be used for forms without a FORM_TYPE, this API is quite a bit easier to use then using the DataForm Builder when filling out a form. Using the DataForm and Field builders would probably mean duplicating the code in FillableForm.

Subclasses can (and do) use the ensureFormType method to enforce a FORM_TYPE.

The initial implementation was to restrictive, as it would throw
together differents fields, having the same field name but a different
field type. This potentially causes parsing exception, if, e.g. a
boolean value is expected, but a non-boolean string was provided.

We now simply assume that fields are of the default type, if we can
not determine the type. Which is close to the original behavior and
should be, for the most part, correct.
@Flowdalic
Copy link
Member Author

A (better?) alternative to this PR could be #464

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants