Form fields pre-population

[simplynail]

Custom forms are a great feature and look like a quick way to add some calculations or other custom logic to be run from within the admin.

I've been wondering if there would be a possibility to pre-populate form fields so that the user would not only be able to type into blank fields or use hardcoded selects but rather select from a dropdown that was dyjamically generated i.e. from contents of some table?

I imagine that same way as form currently has handler function to be run on submit, there could be a init function that would set up the form fields ie with initial text or generate options for select field. You could run the piccolo ORM query in that init function and then do some logic that would modify the fields defined earlier as Pydantic model

[dantownsend]

@simplynail Yes, I like this idea.

When we render the table forms, we call an endpoint like /api/tables/some_table_name/new/. This provides all of the default values. For example:

{
"name": "",
"rating": 0,
"duration": 0,
}

As you say, we could add an option to FormConfig called defaults, which returns a Python dict. We can turn that into an endpoint for fetching the default values.

We could also inspect the Pydantic model, in case it has any defaults already.

class MyPydanticModel(BaseModel):
    name: str = "Unknown"

Choices are a bit trickier. Pydantic allows you to specify choices by using enums (see the docs). We could use these. The only problem is they're not dynamic. There would have to be another argument to FormConfig called choices to handle this scenario, unless there's some way of defining dynamic choices in Pydantic that I'm not aware of.

[dantownsend]

In version 0.19.3 we've made some progress on this. If a default value is provided on the Pydantic model, then this is rendered in the UI.

[simplynail]

Great, this looks promising.

In relation to the dynamic defaults/choices generation, could that be done similarly to what you described that is being done for table view?
I understand that you first render blank fields and after that /api/tables/some_table_name/new/ endpoint gets hit from JavaScript and upon receiving api response frontend then consumes returned dict(json) by populating the widgets/inputs accordingly.
If I understood this correctly then another endpoint could be allowed for (similar to that /new/ endpoint) that is to be hit after Form is rendered, i.e. let's call it /defaults/
Developer then would be in charge to override that endpoint/api function to do some funky logic inside but would need to return dict with keys and value types aligned to Pydantic fields defined earlier.