Lee-W commented on PR #54783:
URL: https://github.com/apache/airflow/pull/54783#issuecomment-3217063313
> > > I do not understand your concerns here. (I mean the technical reason,
maybe due to mis-understanding) - can you elaborate the reason a bit more?
> > > I would propose to make parameter input passing consistent to minimize
mental load, encoding a params dict in a single value is a lot of mental load
if somebody wants to prepare a URL, also quotes and special chars need to be
encoded.
> > > besides this proper docs are needed describing this to users as
interface, else somebody need to be expert in source tree in order to make a
parameterized call.
> >
> >
> > The main reason is that we're not just adding parameter input, but also
the option we want to preload. If there's only parameter input, I'd say we
should go with `key=value...`. But now we have 2 things to add, `options` and
`params`, and `options` might be a valid key for `params`. If we receive
`options=...`, should we view it as a `options` or show it be part of `params`
>
> Mhm, I do not understand about the "options" - this is what the user needs
to confirm anyway? We decided not making a 1-click solution so the "2 click
solution" here with pre-populated fields would anyway require to select the
user to click on "option1", "option2", "option3" manually. What would be
pre-selectable for the user with passing the "option"? Is this not the core
idea of the second click the user needs to make?
The demo video seems to miss the "options" part. But the idea is that
whenever we receive `?...=...&...=...` we'll render the page like multiple
options and have the options pre-loaded.
<img width="1049" height="425" alt="image"
src="https://github.com/user-attachments/assets/79dd17ba-2564-476b-9e5b-97a35248a8f9";
/>
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.
--
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]
