jscheffl commented on PR #54783:
URL: https://github.com/apache/airflow/pull/54783#issuecomment-3217002203

   > > 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?
   
   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.


-- 
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]

Reply via email to