jscheffl commented on PR #54783:
URL: https://github.com/apache/airflow/pull/54783#issuecomment-3217068427
> The users still need to click the `Respond` button, but not necessarily
the options.
>
> > Still if mis-understood the "options", we could make this a special
field naming like "_options" and/or reserve the key such that if the form has
the same it is just not possilbe to pre-populate. Even if this is a restriction
it is much easier to be able to pass values to the form w/o the need to build
and envode a JSON dict in a URL as param value.
>
> I don't think I have enough frontend knowledge to judge whether decoding a
json dict from a frontend perspective is complicated, so I'll leave this to
@guan404ming . From the backend perspective, there will be a utility method
once this is merged, so users typically don't need to deal with JSON encoding.
If we decide to go with `_options`, I'll add another check to ensure this
unusual key is not used.
Ah, okay, so passing the "options" would be only beneficial if multiple
options should be pre-selected, as single options would render as a button
directly.
My argument is mostly not about the decoding (this can be done as code, I am
sure this is not a big challenge) but about the complexity somebody need to
invest to create a URL with the right parameters to pre-select. Making a URL
with `.../respond?key=value` is much easier than
`.../respond?params={"key":"value"}` which would need to properly URLencoded to
`.../respond?params=%7B%22key%22%3A%22value%22%7D` and if it is not working
like expected then it is very hard to debug.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
