AddressNL - overarching epic #4431
Comments
sergei-maertens
added
triage
joeribekker
added
meta
and removed
triage
stevenbal
added a commit
to open-formulieren/formio-builder
that referenced
this issue
Jul 8, 2024
…omponent the following components can now be validated using regex: * postcode * house number * street name * city
stevenbal
added a commit
to open-formulieren/formio-builder
that referenced
this issue
Jul 8, 2024
the following components can now be validated using regex: * postcode * house number * street name * city
stevenbal
added a commit
to open-formulieren/formio-builder
that referenced
this issue
Jul 8, 2024
the following components can now be validated using regex: * postcode * house number * street name * city
stevenbal
added a commit
to open-formulieren/formio-builder
that referenced
this issue
Jul 8, 2024
the following components can now be validated using regex: * postcode * house number * street name * city
stevenbal
added a commit
to open-formulieren/formio-builder
that referenced
this issue
Jul 8, 2024
the following components can now be validated using regex: * postcode * house number * street name * city
|
@sergei-maertens can you let your mind go over this. I tried to incorporate all features. The AddressNL-component features these fields: A. postalcode, housenumber The letters are referenced in the text below. Tasks
To discuss: Registration
--OR--
--OR --
Prefill attribute-sets:
Registration attribute-sets:
Mode-behaviourIn regular mode:
In Autofill mode:
In Prefill mode:
|
sergei-maertens
added a commit
that referenced
this issue
Nov 22, 2024
sergei-maertens
added a commit
that referenced
this issue
Nov 22, 2024
This way we don't need to add a data migration to update the options, the old configuration (pre 3.0) will continue to work.
sergei-maertens
added a commit
that referenced
this issue
Nov 22, 2024
The code was already starting to look like a rather fine Italian pasta
before the addressNL mapping because of component-specific handling of
values that was necessary, but now with the additional configuration
options specific to the component type, readability and maintainability
was in serious danger.
I've opted to look at the broader structure on what information we
need, what information we have and what it is exactly that we need
to do with the information:
* We know all the variable values (keys and value), coming from user
input, derived from user input or entirely independent from user
input.
* When we know the key of a variable and we know the variable source is
a form component, we can look up the definition of the form
component and pass it along as additional context
* We know some user input (file uploads) is processed differently _in
the context of the objects API_ and we have data storage that allows
us to translate
* We need to normalize some values to make them suitable for use in the
Objects API, because a JSON Schema contract is used. Looking at you,
file uploads with multiple=false.
* We may have additional mapping configuration for a specific variable,
typically because the variable points to a particular component type
with special requirements (looking at you, addressNL)
* We must be able to construct the record data for the objects API. The
keys to be used are specified in the mapped variables configuration,
namely the target paths.
* We must process all the mapped variables to construct the entire
object to send to the API.
* We can map all kinds of variables (form, user defined, static,
registration).
So, working backwards, what we needed was for each mapped variable to
make it return instructions which paths of the final object need to
be set to which value. This is solved with AssignmentSpec data classes,
they simply encode the {key: value} information in a well-typed manner.
Next, a single mapping may result in multiple assignments being done
to different parts of the object - this is the newest requirement from
AddressNL type. We can express that as a sequence of AssignmentSpecs.
Finally, we collect all this information, bundle it up and hand it over
to glom which constructs our actual data object, from the mappings.
That leaves us with the requirement of a thing that produces
AssignmentSpec instructions given a mapping configuration and a value.
Because we already know that the value must be transformed depending
on its meaning (=which component produced it), we also pass the
resolved component configuration along for additional context.
For good measure and better code organization, the bulk of the
implementation is moved into handlers/v2.py. More code will be moved
around if this passes the initial reviews.
sergei-maertens
added a commit
that referenced
this issue
Nov 25, 2024
The code was already starting to look like a rather fine Italian pasta
before the addressNL mapping because of component-specific handling of
values that was necessary, but now with the additional configuration
options specific to the component type, readability and maintainability
was in serious danger.
I've opted to look at the broader structure on what information we
need, what information we have and what it is exactly that we need
to do with the information:
* We know all the variable values (keys and value), coming from user
input, derived from user input or entirely independent from user
input.
* When we know the key of a variable and we know the variable source is
a form component, we can look up the definition of the form
component and pass it along as additional context
* We know some user input (file uploads) is processed differently _in
the context of the objects API_ and we have data storage that allows
us to translate
* We need to normalize some values to make them suitable for use in the
Objects API, because a JSON Schema contract is used. Looking at you,
file uploads with multiple=false.
* We may have additional mapping configuration for a specific variable,
typically because the variable points to a particular component type
with special requirements (looking at you, addressNL)
* We must be able to construct the record data for the objects API. The
keys to be used are specified in the mapped variables configuration,
namely the target paths.
* We must process all the mapped variables to construct the entire
object to send to the API.
* We can map all kinds of variables (form, user defined, static,
registration).
So, working backwards, what we needed was for each mapped variable to
make it return instructions which paths of the final object need to
be set to which value. This is solved with AssignmentSpec data classes,
they simply encode the {key: value} information in a well-typed manner.
Next, a single mapping may result in multiple assignments being done
to different parts of the object - this is the newest requirement from
AddressNL type. We can express that as a sequence of AssignmentSpecs.
Finally, we collect all this information, bundle it up and hand it over
to glom which constructs our actual data object, from the mappings.
That leaves us with the requirement of a thing that produces
AssignmentSpec instructions given a mapping configuration and a value.
Because we already know that the value must be transformed depending
on its meaning (=which component produced it), we also pass the
resolved component configuration along for additional context.
For good measure and better code organization, the bulk of the
implementation is moved into handlers/v2.py. More code will be moved
around if this passes the initial reviews.
This was referenced Jan 8, 2025
|
A small overview of the different items that need to be picked up to complete this epic: Critial todos: Other todos:
This should include all items described in Joeri's comment and some items from the first message. |
|
Rough estimate ~8 weeks |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
(Provide a non "column" view of AddressNL component #4423)
Changing postcode does not trigger update of "DeriveStreetName" #2566 (blocked, refine on July 15th)
Validate (or show validation errors) only when a field has been touched (AddressNL validation on city & postcode issues #4699) @robinmolen
Allow specifying validation regular expressions for nested fields - we can leverage the JSON nature for this (Validation for fields within AddressNL component #4420):
{ "type": "addressNL", "key": "address", "label": "Your address", "components": { "postcode": { "validate": {"pattern": "1015 [a-zA-Z]{2}"}, "translatedErrors": { "en": { "pattern": "Must be at 1015 XX" } } } }Figure out a "transform" mechanism for (AddressNL) component(s) when registering them in the Objects API #4418
AddressNL autocomplete: handle empty response #4430
<address>content - this is now the browser default which is italic and looks out of place -> I believe the Utrecht community components have something for thisThe text was updated successfully, but these errors were encountered: