Perhaps my earlier message was not worded strongly enough, so I will try to expand on it.
There are, broadly speaking, two kinds of Jelly code used in Jenkins configuration pages. The familiar code, as exemplified in `ui-samples-plugin`, uses a limited set of high-level controls which all either take a `field` attribute or expect to be inside an `f:entry` defining the `field`. These may specify a `default` in certain cases, but `name` and `value` should not be used, nor should there be extra HTML tags beyond `f:advanced` and a couple of similar helpers. Each `config.jelly`, plus any associated `help.html` and/or `help-fieldName.html`, corresponds to one `Describable` type, with a `@DataBoundConstructor` defining mandatory fields and `@DataBoundSetter`s defining optional fields. `f:textbox` completion, `f:select` contents, and form validation are all done by conventionally-named web methods in the `Descriptor` using `@QueryParameter`. Structured forms are created by fields of type `SomeOtherDescribable` or `List<SomeOtherDescribable>` and the corresponding controls. Pipeline and/or JEP-201 (“configuration-as-code”) support generally comes for free or with minimal intervention like adding `@Symbol`s. This is called “modern databinding”. Virtually all plugin code should be using it, and you can file bug reports or request advice on the developer list if anything goes wrong. The other kind of code uses low-level controls like `f:repeatable`. This should generally only be used to _implement_ higher-level controls, or to handle very specialized use cases, and only experienced Jenkins developers should consider touching it as it is very tricky to get right and you will in general need to use Java and/or JavaScript source debuggers, HTML inspectors, etc. to track down issues, which may require tested Jenkins core patches. Pipeline or JEP-201 support would require custom adapters. Plenty of _existing_ plugin code still uses these controls, only because the maintainers were ignorant of modern databinding, or because it was written before modern databinding existed and no one ever felt an immediate need to rewrite the configuration forms. I have seen no indication that you need to be using the latter category. While I do not understand the exact use case, it is something like: I need a list of pairs of label and some number. So define a `Describable` for that kind of pair, and a top-level `Describable` taking a list of them. It is up to the user to select label names. You can use standard features of modern databinding to offer completion or even fixed dropdowns. If the list is incomplete or has duplicates or invalid labels or whatever, deal with it gracefully. You would need to do that anyway for JEP-201 users who are just editing a YAML file, or (if applicable) Pipeline users writing some Groovy expression. -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr1uXDB%3DcUq1sCt684as6Ruq6yKUyUZCi70H%3Dh6QkmyxCA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
