Details

    • Type: New Feature New Feature
    • Status: Open Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: Backlog
    • Component/s: Development
    • Security Level: Public (Public: Anyone can view)
    • Labels:
    • Similar issues:
      KULRICE-9580Update krad-data to support more standard types of validations via annotations
      KULRICE-11301UIF-related annotations should not be in krad data module
      KULRICE-11178Need support for query customizers with JPA
      KULRICE-5368Uif Framework - Add support for enter key
      KULRICE-5283UIF Framework - Support for custom JSP templates (for group content)
      KULRICE-9503JPA Support for krad-data
      KULRICE-9067Implement Custom Annotation version of MetadataProvider
      KULRICE-9555Add Hibernate support to krad-data
      KULRICE-8587allow customization of workflow notification annotation
      KULRICE-12681allow customization of role-responsibility action request annotation
    • Rice Module:
      KRAD
    • KRAD Feature Area:
      Persistence Framework
    • Application Requirement:
      KFS, KC, Rice
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required
    • Code Review Status:
      Not Required
    • Include in Release Notes?:
      Yes

      Description

      In, Rice, KC, and other projects it is pretty typical to create generic attribute configurations in the DD and then inherit from those beans in many DD files. This is a way to reuse configuration so that you don't have to type so much xml.

      In KFS, examples of this would be in GenericAttributes.xml & KfsBaseAttributeDefinitions.xml as well as many other places.

      The new annotation based configuration creates the same sort of problem and so we should have a mechanism for reuse.

      I believe we should do something similar to http://java.dzone.com/articles/avoid-spring-annotation-code-smell-use-spring3-custom-annotations

      for the Uif annotations.

      For example: let's say KC wants to support the following configuration all over the place.

      @UifDisplayHints({
        @UifDisplayHint(value=UifDisplayHintType.NO_LOOKUP_RESULT)
        , @UifDisplayHint(value=UifDisplayHintType.NO_LOOKUP_CRITERIA)
        , @UifDisplayHint(value=UifDisplayHintType.NO_INQUIRY)
      })
      protected String startTime;
      
              
      @UifDisplayHints({
        @UifDisplayHint(value=UifDisplayHintType.NO_LOOKUP_RESULT)
        , @UifDisplayHint(value=UifDisplayHintType.NO_LOOKUP_CRITERIA)
        , @UifDisplayHint(value=UifDisplayHintType.NO_INQUIRY)
      })
      protected String endTime;
      

      One option is for rice to support a convenient annotation with this configuration, but this wont always make sense.

      What I would suggest is the ability to do the following:

      @Target({ ElementType.FIELD, ElementType.METHOD })
      @Retention(RetentionPolicy.RUNTIME)
      @Documented
      @UifDisplayHints({
        @UifDisplayHint(value=UifDisplayHintType.NO_LOOKUP_RESULT)
        , @UifDisplayHint(value=UifDisplayHintType.NO_LOOKUP_CRITERIA)
        , @UifDisplayHint(value=UifDisplayHintType.NO_INQUIRY)
      })
      public @interface NoLookupInquiry {
      }
      

      Then it would look like:

      @NoLookupInquiry
      protected String startTime;
      
              
      @NoLookupInquiry
      protected String endTime;
      

        Activity

        There are no comments yet on this issue.

          People

          • Assignee:
            Jonathan Keller
            Reporter:
            Travis Schneeberger
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:

              Structure Helper Panel