public static class DataBoundBean {
@DataBound @Positive @Max(100)
private int x;
@DataBound @NotBlank
private String y;
@DataBound(trim = DataBound.Trim.TONULL)
private String z;
}
public static class DataBoundBean {(or alternatively use DataBoundSetters and a @PostConstruct method for conversion/validation)
private int x;
private final String y;
private String z;
@DataBoundConstructor
public DataBoundBean(int x, @Nonnull String y, String z) {
if (x < 0 || x > 100) throw new IllegalArgumentException("x must be positive < 100");
if (StringUtils.isBlank(y)) throw new IllegalArgumentException("y can't be blank");
this.x = x;
this.y = y;
this.z = StringUtils.trimToNull(z);
}
}
The code looks much nicer, and developers probably will have already used jsr-303 in some project.
Had a brief look at the code and it looks good (minor nit-pick for the @author tag in one of the files, maybe drop it or replace kohsuke by your user?).
Would it also work if a plugin developer tried to implement a custom ConstraintValidator?
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANMVJzkhxCcspfcNxZJTwcw%3Dg1QcmEz9n9k4homP6rXvaqYSNA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
--
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 jenkinsci-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/1172002936.1614566.1528364231154%40mail.yahoo.com.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANMVJzkhxCcspfcNxZJTwcw%3Dg1QcmEz9n9k4homP6rXvaqYSNA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
--
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 jenkinsci-de...@googlegroups.com.
Yes, such annotation would help a lot with our current issues in the code.So +1 from me to implement it.Some notes:
- I would suggest a "required" attribute in @DataBound which defaults to true
- I would recommend moving annotations to a separate library which we could include into plugins so that they do not require new core dependency to start putting annotations
- New core will be still required to do binding from Web UI forms
- Configuration-as-Code plugin and Pipeline can start using the annotations even on older cores
- It would be great to add support of custom Validator classes within the annotation
- It would be great to also define some conversion logic on the top level, so that classes can implement migration logic should the data model change (like readResolve)
- Use-case: support old submissions when a field is removed (add field converter class or so)
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/8c888e0f-7fdc-4712-bc53-4ee66388a65e%40googlegroups.com.
Some notes:
- I would suggest a "required" attribute in @DataBound which defaults to true
I also considered this, but wouldn't this be equivalent to jsr-303 annotation @NotNull ? Can do both anyway
- I would recommend moving annotations to a separate library which we could include into plugins so that they do not require new core dependency to start putting annotations
- New core will be still required to do binding from Web UI forms
- Configuration-as-Code plugin and Pipeline can start using the annotations even on older cores
this is plain javax.validation API, so already a separate librarySo you suggest plugin developer will mark fields with those annotations, without getting benefits for UI databinding ?
--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/Bb4pIdpMMIY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANMVJznpvHuQaE%2BODejhrv5H1OuzJVM26piimBirDn9j2bsf-A%40mail.gmail.com.
public static class DataBoundBean {
@DataBound(required = true) @Positive
private int x;
@DataBound @NotBlank
private String y;
@DataBound @Trim
private String z;
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLByg0xPfzOOzjYDe_4i%3DmJC0nM1EjPsYYTduTHG_GmFiA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/8c888e0f-7fdc-4712-bc53-4ee66388a65e%40googlegroups.com.
--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/Bb4pIdpMMIY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANMVJznpvHuQaE%2BODejhrv5H1OuzJVM26piimBirDn9j2bsf-A%40mail.gmail.com.
--
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 jenkinsci-de...@googlegroups.com.
I didn't look at the implementation but IMO the annotations must go on the setters (or parameters) and not on private fields, and then the checks need to be done on the setters or (injected into the constructor)Why?Because things other than DataBinding create these objects (ie calling the API directly from another piece of code). and if I can vilaote a requirement from code that would cause the UI or stapler to fail a round trip then that is a bad bug.
Also the public setters are documented as part of the javadoc but private fields are not, and as such the annotaions if defined on something public would then also be documented.
Tied to this I was wondering how this ties in the any doCheckXYZ() methods? does it need to be repeated will they be generated for formbinding?
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/99356e40-a6ab-483a-bcdc-ed25de0f0db0%40googlegroups.com.
2018-06-07 15:23 GMT+02:00 James Nord <jn...@cloudbees.com>:
I didn't look at the implementation but IMO the annotations must go on the setters (or parameters) and not on private fields, and then the checks need to be done on the setters or (injected into the constructor)Why?Because things other than DataBinding create these objects (ie calling the API directly from another piece of code). and if I can vilaote a requirement from code that would cause the UI or stapler to fail a round trip then that is a bad bug.so the question : is this a good thing to have "another piece of code" create a DataBound object ? Do you have any legitimate use case in mind ?What you call "API" is just a public class within many because java don't let us do it any other way. Do we really want anything public to be considered "an API" ? (yes I know about @Restricted. Just would like this to be the default)Another way to ask : Do you think JAX-B and JPA are all wrong in their design using field annotations ?I remember I had this exact debate with Hibernate-annotation folks some years ago, unfortunately can't remember the reasoning. Sounds to me some endless debate with various valuable argument on both sides.So, some option I can offer :
- allow this annotation both on fields and methods, just like JPA does.
public static class DataBoundBean {
@DataBound(required = true) @Positive
private int x;
@DataBound @NotBlank
private String y;
private String z;
@DataBound @Trim
public void setZ(String z) {
this.z = z;
}
@DataBound
public static class DataBoundBean {
@Required @Positive
private int x;
@NotBlank
private String y;
@Trim
private String z;
public static class ValidatedBean {
@DataBound @Required @Positive
private int x;
@DataBound @NotBlank
private String y;
private String z;
@DataBound @Trim
public void setZ(String z) {
this.z = z;
}
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANMVJzmyYke%2B7VsGUOkAHzgL1ATGfz0JsfWYi-VDeKayhH7EVg%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/99356e40-a6ab-483a-bcdc-ed25de0f0db0%40googlegroups.com.
--
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 jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANMVJzmyYke%2B7VsGUOkAHzgL1ATGfz0JsfWYi-VDeKayhH7EVg%40mail.gmail.com.
I like the idea, but could it be more focused on annotating public members? Java 9+ discourages things like setAccessible() for reflection nonsense like this. I'd prefer to annotate the constructor and/or methods only. Or public fields I suppose, but why use those?
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAEot4oxtzuN2Kv%3DEFLzoyDZ41HEL3CCka5Btt30nWS11RjEkHg%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANMVJzkJkfGqxE3KxKVZKMw%3DVTcDW_r8GMS2yqx2Hh7C_KvAbA%40mail.gmail.com.
--
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 jenkinsci-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANMVJzkhxCcspfcNxZJTwcw%3Dg1QcmEz9n9k4homP6rXvaqYSNA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
<f:entry field="foo">
--
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 jenkinsci-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr2s748BNGBQFhxbQLE_iq-N6X9FNpAWjKn45TOQs8_UrA%40mail.gmail.com.
2018-06-07 15:23 GMT+02:00 James Nord <jn...@cloudbees.com>:
I didn't look at the implementation but IMO the annotations must go on the setters (or parameters) and not on private fields, and then the checks need to be done on the setters or (injected into the constructor)Why?Because things other than DataBinding create these objects (ie calling the API directly from another piece of code). and if I can vilaote a requirement from code that would cause the UI or stapler to fail a round trip then that is a bad bug.so the question : is this a good thing to have "another piece of code" create a DataBound object ?
Do you have any legitimate use case in mind ?
What you call "API" is just a public class within many because java don't let us do it any other way. Do we really want anything public to be considered "an API" ? (yes I know about @Restricted. Just would like this to be the default)
Another way to ask : Do you think JAX-B and JPA are all wrong in their design using field annotations ?
I remember I had this exact debate with Hibernate-annotation folks some years ago, unfortunately can't remember the reasoning. Sounds to me some endless debate with various valuable argument on both sides.So, some option I can offer :
- allow this annotation both on fields and methods, just like JPA does.
- make @DataBound a class level annotation, all fields (and setters) would then be considered for databinding (same as JPA's @Entity). DataBound would then imply a @Restricted annotation, to ensure nobody does bad things with this code.
Also the public setters are documented as part of the javadoc but private fields are not, and as such the annotaions if defined on something public would then also be documented.So we have found this guy who read the doc :)
Tied to this I was wondering how this ties in the any doCheckXYZ() methods? does it need to be repeated will they be generated for formbinding?Part of this effort I've considered the jelly tags could be enhanced to integrate client side validation for comparable rules. Afaik the doCheck methods are mostly used to validate a parameter is valid within a specific context (like credentialsId), not to check they follow some formal design.
On Thursday, June 7, 2018 at 2:59:08 PM UTC+1, nicolas de loof wrote:2018-06-07 15:23 GMT+02:00 James Nord <jn...@cloudbees.com>:
I didn't look at the implementation but IMO the annotations must go on the setters (or parameters) and not on private fields, and then the checks need to be done on the setters or (injected into the constructor)Why?Because things other than DataBinding create these objects (ie calling the API directly from another piece of code). and if I can vilaote a requirement from code that would cause the UI or stapler to fail a round trip then that is a bad bug.so the question : is this a good thing to have "another piece of code" create a DataBound object ?Why not? Why should I not be able to programatically generate a collection of some things based on some runtime / environmental state in a plugin?Do you have any legitimate use case in mind ?several all in a proprietary code base you have access to :)
But also, unit tests (JenkinsRule), why should a unit test not fail with an error IllegalArgumentExcetion "MyClass.foo 10 > 4" if it tries to set a value greater than the allowed version?
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/77220835-5b84-4902-b2d6-9faafa4086cf%40googlegroups.com.
--
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 jenkinsci-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0qm3V5njrHdQuzwoQkj2Pv-RXFMEZMz4YNzegPH1m9Fw%40mail.gmail.com.
--
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 jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0R6t3MBzT%2B4rkf8AF4_1RsnWcyAowGRhWSaRoiBhjicg%40mail.gmail.com.
+1000
Which jsr-303 implementation is planned to use?
--
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 jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/e41ab6c8-856c-4c89-a560-a75016e0f713%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/324e2ffa-3f7b-4f98-b273-2f33accd431f%40googlegroups.com.