Kuali Rice Development
  1. Kuali Rice Development
  2. KULRICE-7583

Add support to KRAD attribute field framework for RemotableSelectField.refreshOnChange

    Details

    • Similar issues:
      KULRICE-4705Add watermark support to framework
      KULRICE-5365Uif Framework - Collections: Need support for read only after add
      KULRICE-5814Add support for * wildcard on all search fields
      KULRICE-6752UI Framework - Keyboard Support
      KULRICE-6753UI Framework - Keyboard Support
      KULRICE-5370Uif Framework - Collections: Support for Total Lines and Grouping
      KULRICE-9580Update krad-data to support more standard types of validations via annotations
      KULRICE-6860Add support for specifying multiple default values for an attribute definition or field
      KULRICE-5366Uif Framework - Collections: Support for duplicate key check in collections and highlighting attributes
      KULRICE-3375Remove support for "display parameters" in the XML rule attributes
    • Rice Team:
      Framework
    • Rice Module:
      KRAD
    • Sprint:
      Core 2.5.0-m6 Sprint 1
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required
    • Story Points:
      8

      Description

      This is equivalent to the old functionality in KNS of Field.DROPDOWN_REFRESH and it indicates a situation where page state needs to be "reloaded" when the value of a select changes. Oftentimes this is used for select dropdowns which depend on each other. Obviously, it would be better to do this through AJAX or purely client side, but we'll need to figure out if that is possible in order to maintain equivalence with how the KNS handles it.

      Note that, in 2.1.1, the refreshOnChange property was added to the RemotableSelect control.

      It's possible that KRAD already has support for doing something like and we just need to hook it up in the code where we translate from RemotableSelect up to the corresponding KRAD UIF component, but at the very least that translation is not occurring at the present time.

        Activity

        Hide
        Kristina Taylor (Inactive) added a comment - - edited

        You can add fields, you just have to add them in a specific way. I'd have to check with Peter or Eric, like you said.

        I think it's okay to not have this be automatically converted as long as we document it. It's probably also okay to limit this to two fields that are both remotable.

        Show
        Kristina Taylor (Inactive) added a comment - - edited You can add fields, you just have to add them in a specific way. I'd have to check with Peter or Eric, like you said. I think it's okay to not have this be automatically converted as long as we document it. It's probably also okay to limit this to two fields that are both remotable.
        Hide
        Steve Edgar (Inactive) added a comment -

        Based on my investigation, and Jerry's comments, I think this case falls into the category of "A feature which must be architected into KRAD", and as such requires that expertise.

        This case reminds me of one I worked on shortly after I started in July, in which the expertise required to implement the feature resided only in the KRAD group. I realize that with a high workload, developing KRAD expertise is a challenge for the overall Rice development team, especially due to KRADs size and complexity.

        So I think there needs to be a change in how we approach this case. Some options I can think of are ...

        1) Reassign this to a KRAD expert, if that is practical due to other work priorities.

        2) Continue to have rework the case, but have a KRAD expert lay out the architectural solution and be available for possible implementation cons. Availability of the expert is key. (And I realize that is the hard part, with respect to practicality.)

        3) Continue to have me work the case, with "ad-hoc consulting" (that is, there might be consulting available, in varying amounts, at varying times, or not), knowing that the time frame to resolve the case may be significant, due to the amount of information which must be learned, on my own, about KRAD internals and related parts of the system.

        I am greatly enjoying learning about KRAD in-depth, and am happy to develop expertise in that area. However, I know we have a ton of work to do .

        What do y'all think?

        Show
        Steve Edgar (Inactive) added a comment - Based on my investigation, and Jerry's comments, I think this case falls into the category of "A feature which must be architected into KRAD", and as such requires that expertise. This case reminds me of one I worked on shortly after I started in July, in which the expertise required to implement the feature resided only in the KRAD group. I realize that with a high workload, developing KRAD expertise is a challenge for the overall Rice development team, especially due to KRADs size and complexity. So I think there needs to be a change in how we approach this case. Some options I can think of are ... 1) Reassign this to a KRAD expert, if that is practical due to other work priorities. 2) Continue to have rework the case, but have a KRAD expert lay out the architectural solution and be available for possible implementation cons. Availability of the expert is key. (And I realize that is the hard part, with respect to practicality.) 3) Continue to have me work the case, with "ad-hoc consulting" (that is, there might be consulting available, in varying amounts, at varying times, or not), knowing that the time frame to resolve the case may be significant, due to the amount of information which must be learned, on my own, about KRAD internals and related parts of the system. I am greatly enjoying learning about KRAD in-depth, and am happy to develop expertise in that area. However, I know we have a ton of work to do . What do y'all think?
        Hide
        Steve Edgar (Inactive) added a comment -

        Just realized a typo above. This ...

        > 2) Continue to have rework the case...

        Should say ...

        2) Continue to have me work the case [...]

        And of course, another option is, this case could be assigned to a Rice developer with more experience, and less KRAD consulting may be required.

        Show
        Steve Edgar (Inactive) added a comment - Just realized a typo above. This ... > 2) Continue to have rework the case... Should say ... 2) Continue to have me work the case [...] And of course, another option is, this case could be assigned to a Rice developer with more experience, and less KRAD consulting may be required.
        Hide
        Steve Edgar (Inactive) added a comment -

        After consulting with Kristina, we are going to park this case, to be transferred to the KRAD group at a later time. As implementing this feature has KRAD design considerations, it was determined that having the KRAD group do the implementation would be the best option.

        Show
        Steve Edgar (Inactive) added a comment - After consulting with Kristina, we are going to park this case, to be transferred to the KRAD group at a later time. As implementing this feature has KRAD design considerations, it was determined that having the KRAD group do the implementation would be the best option.
        Hide
        Claus Niesen added a comment - - edited

        Jerry:

        I am not sure. I question how important it is really. Even though it is an equiv. item, I would be suprised if it is being used that much, maybe not even at all. I would be curious to see what apps have as use cases

        James Smith:

        i don't believe KFS uses the equivalent feature of the KNS

        No other replies from other projects.

        Show
        Claus Niesen added a comment - - edited Jerry: I am not sure. I question how important it is really. Even though it is an equiv. item, I would be suprised if it is being used that much, maybe not even at all. I would be curious to see what apps have as use cases James Smith: i don't believe KFS uses the equivalent feature of the KNS No other replies from other projects.

          People

          • Assignee:
            Unassigned
            Reporter:
            Eric Westfall
          • Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

            • Created:
              Updated:

              Agile

                Structure Helper Panel