4 Replies Latest reply: Sep 1, 2008 8:19 PM by 843793 RSS

    Requiring one of a set of methods/elements

    843793
      I'm pretty sure annotations can't do this now, but what if they could?
      @Target(ElementType.METHOD)
      @Retention(RetentionPolicy.RUNTIME)
      public @interface Something {
          @Required(group="A") String displayName() default ""; 
      
          @Required(group="A") String keyName() default "";
      }
      What I mean is, what if this would make the compiler require at least one, but not both of the "A" group?

      Then you could restrict someone from doing:
      @Something()
      but allow either:
      @Something(displayName="abc")
      or:
      @Something(keyName="def")
        • 1. Re: Requiring one of a set of methods/elements
          800329
          Well, might be an interesting option. But why don't you remove default from one of the entries and have the second one optional? It's static meta-data in the end.
          • 2. Re: Requiring one of a set of methods/elements
            843793
            I guess I wasn't clear on my point, but that is normal!

            What I want is to force the entry of only one of the set of options. Setting one as required and the other as the default makes you include both of them when I want the second option only, or the first option only.

            Anyway, the way I did it was to make both the options have defaults and throw an assert in the code that processes the annotations if neither is present.

            Edited by: culli on Aug 30, 2008 3:54 PM
            • 3. Re: Requiring one of a set of methods/elements
              800329
              culli wrote:
              I guess I wasn't clear on my point, but that is normal!
              No, I got your point quite clear. My reply was to confirm your assumption that there is no such feature in annotations, and a question, whether you really need it.
              Another approach might be to have distinct annotations for each option (@SomeKey, @SomeDisplayName) having non-optional name fields.
              Anyway, the way I did it was to make both the options have defaults and throw an assert in the code that processes the annotations if neither is present.
              I am curious, what do the actual annotations imply? And wouldn't it be better solved not using annotations?
              • 4. Re: Requiring one of a set of methods/elements
                843793
                stefan.schulz wrote:
                I am curious, what do the actual annotations imply? And wouldn't it be better solved not using annotations?
                There is a (way too large) object with quite a few properties. I am building a GUI where the customer can pick which properties to display, so I created an annotation that lets me note the display name of the property and the type of field that will be displayed, among other things. That was a pretty straightforward and simple annotation. Now a wrinkle is that elsewhere in the software, the user can customize the label for a bunch of user defined fields. They pick what to name them and store in them (types are predefined). So when I annotate the getter for one of these properties that can have a custom name, I want to specify the key to go look up what the display name for the field is, instead of provide a direct display name. i18n needs to be considered here too, but let's leave it out of the mix for now.

                So some properties are annotated this way:
                @Displayable(displayName="Display Name", type=PERCENT)
                public int getSomePercent() {...}
                and others are:
                @Displayable(key="userField1") //type=STRING is default
                public String getUserField1() {...}
                For other programmers adding fields or whatever, I wanted to force either the displayName or the key. But I just realized what you might saying:
                @Displayable(displayName="Display Name", type=PERCENT)
                public int getSomePercent() {...}
                and:
                @DisplayableWithLookup(key="userField1")
                public String getUserField1() {...}