@@ -28,34 +28,6 @@ In the same time, user is able to adjust database fields definition with
2828specific settings as on stage of Document model definition, as on form generation stage.
2929This allows to create several forms for same model, for different circumstances.
3030
31- [ // ] : # ( TODO: Read below )
32- For complex or custom cases user can bypass additional Flask-WTF/WTForms fields
33- arguments , on form generation with {func}` ~WtfFormMixin.to_wtf_form ` as
34- {attr}` fields_kwargs ` parameter.
35-
36- For extremely complex cases, or cases when some field not yet supported by
37- Flask-Mongoengine user is able to implement special database model field with
38- completely independent field converter for forms, that will be used, ignoring
39- Flask-Mongoengine internals. To do this:
40-
41- 1 . Inherit from database model field type.
42- 2 . Implement {func}` to_wtf_field ` method with additional {attr}` model ` ,
43- {attr}` field_args ` arguments, that will return form field. Check
44- {attr}` .ModelConverter.convert ` first lines for details.
45-
46- ``` {note}
47- {func}`to_form_field` was undocumented feature, even before **2.0.0**, but was not
48- in priority of {attr}`.ModelConverter.convert` execution order. I.e. some
49- transformations was made before this function existance check, even full form field
50- could be generated in some cases.
51- ```
52-
53- ``` {warning}
54- Usage of {func}`to_form_field` approach assume that there will not be any
55- tranformation from Flask-Mongongine side. So user is fully responsible for all
56- validators, labels, etc.
57- ```
58-
5931## Requirements
6032
6133For correct integration behavior several requirements should be met:
0 commit comments