Hi, you probably should take a look at the dynamic parameter plugins like:
Extended Choice, Extensible Choice, Git Parameter, Activce Choices or Autocomplete Parameter (I didi not check ones are currently actively maintained) on how they solve this problem. Björn Am Freitag, 7. September 2018 14:47:59 UTC+2 schrieb [email protected]: > > Thank you very much, Jesse. I've took up the task to add support for > custom gerrit labels on gerrit-trigger-plugin, and for someone that never > contributed to jenkins or jenkins plugins before, it's quite hard to make > sense of how it should be done. > > The use case: Considering a list of labels (which can contain any number > of labels at each time) and that each label object has 5 particular int > fields that represent votes (one per each build outcume - started, > successful, failed, unstable, not built) then display each label and its > corresponding votes in an entry inside the Gerrit Trigger job configure > page. > > I was able to achieve this: > > [image: job_config.PNG] > > > Problem: How can I persist the votes of each label since I don't know > beforehand how many labels I have in my label list or what their names are? > Because this means I can't use the default @DataBoundSetter mechanism that > the plugin currently uses (1-to-1 relationship between a field on the web > UI and the setter in the java class which gets called automatically). > Currently I just display hardcoded values and any modifications are not > persisted in the config.xml file. > > It's something that I've been stuck on for over 2 weeks and you shedding > some light on this will really make my day! > > Thank you, > George > > On Friday, September 7, 2018 at 3:32:28 PM UTC+3, Jesse Glick wrote: >> >> 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/267edd5b-4705-4d3e-b00e-adb8ee02f2b4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
