Uploaded image for project: 'Kuali Rice Development'
  1. Kuali Rice Development
  2. KULRICE-2239

Rewrite RuleBaseValuesLookupableImpl to use KNS framework

    Details

    • Type: Task
    • Status: Closed
    • Priority: Blocker
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.0
    • Component/s: Development
    • Labels:
      None
    • Rice Module:
      KEW

      Description

      org.kuali.rice.kew.lookupable.RuleBaseValuesLookupableImpl needs to be rewritten to use the KNS lookup framework

      See KULRICE-1457 for more details

        Attachments

          Issue Links

            Activity

            Hide
            ewestfal Eric Westfall added a comment -

            Jeremy, I've actually started on this particular task, you can see it by going to "Routing Rules" in the KEW "portal" in the sample app. It's just got 3 fields at the moment.

            To get yourself familiar with how the original screen worked, take a look at Kuali Test Drive. There should be a link there to "Rule Quick Links". Click on "Search" on one of those and you will see the original Rule lookup. Notice how the fields that are displayed for search change based on the RuleTemplate that is selected. The RuleTemplate defines a series of RuleAttributes. Each of those rule attributes points to a class which implements WorkflowAttribute. WorkflowAttribute has a getRuleRows method on it which returns a list of Rows. The Rows that used to be returned were the old KEW Row object. If you recall, we changed that so that it returns the KNS Row object now.

            This is helpful because there is a way on a lookup to customize the lookup. We will need to implement a LookupableHelperService for the RuleBaseValues lookup. You can see in the KEWSpringBeans.xml how this has been done already for EDocLite, Document Type, etc.

            That class has a hook point where we can customize the getRows() method. So we will need to be able to respond to the case where the RuleTemplate on the lookup is changed and then customize what is returned from getRows() so that it displays the additional Rows. Note that the KualiLookupableHelper.checkForAdditionalFields gets called after we return back to the Rule lookup from an external lookup (such as RuleTemplate). So that might likely be the hook you would need to update in order to update any internal state in the lookup itself.

            See KualiLookupAction.refresh and other methods if you want to get a better idea for how the lookup framework operates.

            A couple of other notes:

            1) You will want to look at the original KEW-lookup based implementation of the Rule lookup to make sure you are including everything. It's still in the project and is called RuleBaseValuesLookupableImpl
            2) One thing you will notice is that, in addition to WorkflowAttribute.getRuleRows() it also supports OddSearchAttribute.getSearchRows() so we will need to be sure to include support for that as well in our customized lookup
            3) It's likely that the default mechanism for executing the search in the lookup is not going to work in this case. So instead we may need to execute the search using RuleService.search as the original lookup did. We did something similar to this for the DocumentType lookup so you can see that code in DocumentTypeLookupableHelperServiceImpl

            I'm sure there are other potential issues here as I haven't had a chance to do a full analysis on this. Please take a look yourself before you get started on coding and see if there are any potential issues you can envision. I know you are new to this framework so keep me posted on progress and let me know if you have questions.

            Thanks!

            Show
            ewestfal Eric Westfall added a comment - Jeremy, I've actually started on this particular task, you can see it by going to "Routing Rules" in the KEW "portal" in the sample app. It's just got 3 fields at the moment. To get yourself familiar with how the original screen worked, take a look at Kuali Test Drive. There should be a link there to "Rule Quick Links". Click on "Search" on one of those and you will see the original Rule lookup. Notice how the fields that are displayed for search change based on the RuleTemplate that is selected. The RuleTemplate defines a series of RuleAttributes. Each of those rule attributes points to a class which implements WorkflowAttribute. WorkflowAttribute has a getRuleRows method on it which returns a list of Rows. The Rows that used to be returned were the old KEW Row object. If you recall, we changed that so that it returns the KNS Row object now. This is helpful because there is a way on a lookup to customize the lookup. We will need to implement a LookupableHelperService for the RuleBaseValues lookup. You can see in the KEWSpringBeans.xml how this has been done already for EDocLite, Document Type, etc. That class has a hook point where we can customize the getRows() method. So we will need to be able to respond to the case where the RuleTemplate on the lookup is changed and then customize what is returned from getRows() so that it displays the additional Rows. Note that the KualiLookupableHelper.checkForAdditionalFields gets called after we return back to the Rule lookup from an external lookup (such as RuleTemplate). So that might likely be the hook you would need to update in order to update any internal state in the lookup itself. See KualiLookupAction.refresh and other methods if you want to get a better idea for how the lookup framework operates. A couple of other notes: 1) You will want to look at the original KEW-lookup based implementation of the Rule lookup to make sure you are including everything. It's still in the project and is called RuleBaseValuesLookupableImpl 2) One thing you will notice is that, in addition to WorkflowAttribute.getRuleRows() it also supports OddSearchAttribute.getSearchRows() so we will need to be sure to include support for that as well in our customized lookup 3) It's likely that the default mechanism for executing the search in the lookup is not going to work in this case. So instead we may need to execute the search using RuleService.search as the original lookup did. We did something similar to this for the DocumentType lookup so you can see that code in DocumentTypeLookupableHelperServiceImpl I'm sure there are other potential issues here as I haven't had a chance to do a full analysis on this. Please take a look yourself before you get started on coding and see if there are any potential issues you can envision. I know you are new to this framework so keep me posted on progress and let me know if you have questions. Thanks!
            Hide
            jjhanso Jeremy Hanson added a comment -

            I have the screen returning the extra fields after the lookup for Rule Template, but is there a button that should be added the the screen to update for the extra field(s) if the Template Name or Id is entered manually?

            Also, I'm guessing we want to add the other default fields that show up in the Test Drive?

            Do we want the extra fields to show up in the results?

            Show
            jjhanso Jeremy Hanson added a comment - I have the screen returning the extra fields after the lookup for Rule Template, but is there a button that should be added the the screen to update for the extra field(s) if the Template Name or Id is entered manually? Also, I'm guessing we want to add the other default fields that show up in the Test Drive? Do we want the extra fields to show up in the results?
            Hide
            ewestfal Eric Westfall added a comment -

            Hmm, I thought there was a way to make a field read only in the KNS but it looks like that's only for documents and not lookups. I'm not sure if there would even be a way to render a button there using the lookup framework, so for now let's not worry about it. If they want the extra fields they will need to do a lookup on the Rule Template. Typical entry into this screen will likely be from the Rule Quick Links anyway which will pass the rule template to the lookup.

            So we will want to make sure as part of this that the Rule Quick Links are generating proper URLs for the "Search" links and that by passing the rule template it properly displays any custom fields.

            Show
            ewestfal Eric Westfall added a comment - Hmm, I thought there was a way to make a field read only in the KNS but it looks like that's only for documents and not lookups. I'm not sure if there would even be a way to render a button there using the lookup framework, so for now let's not worry about it. If they want the extra fields they will need to do a lookup on the Rule Template. Typical entry into this screen will likely be from the Rule Quick Links anyway which will pass the rule template to the lookup. So we will want to make sure as part of this that the Rule Quick Links are generating proper URLs for the "Search" links and that by passing the rule template it properly displays any custom fields.
            Hide
            ewestfal Eric Westfall added a comment -

            As far as the other fields in the test drive, yes, let's include those except change "Workgroup Reviewer" to "Group Reviewer"

            Show
            ewestfal Eric Westfall added a comment - As far as the other fields in the test drive, yes, let's include those except change "Workgroup Reviewer" to "Group Reviewer"
            Hide
            ewestfal Eric Westfall added a comment -

            Regarding fields in the result set, yes we do want to include those since the original Rule lookup did. However I'm not sure if this is possible with the lookup framework. You might want to talk to Chris since he is doing something similar to this for Document Search so you could either leverage his work or, if it's already possible, he could help you figure out how to do it.

            Show
            ewestfal Eric Westfall added a comment - Regarding fields in the result set, yes we do want to include those since the original Rule lookup did. However I'm not sure if this is possible with the lookup framework. You might want to talk to Chris since he is doing something similar to this for Document Search so you could either leverage his work or, if it's already possible, he could help you figure out how to do it.
            Hide
            jjhanso Jeremy Hanson added a comment -

            Committed a portion of the resolution. The lookup is working, but the links on the quick links page don't work yet, and the extra fields don't show up in the results yet.

            Show
            jjhanso Jeremy Hanson added a comment - Committed a portion of the resolution. The lookup is working, but the links on the quick links page don't work yet, and the extra fields don't show up in the results yet.
            Hide
            jjhanso Jeremy Hanson added a comment -

            I've commited more changes. The RuleBaseValues lookup's results now contain the columns with the extra fields. It also fixes the links on the RuleQuickLinks page to the correct lookup.

            Currently, the return location on the lookup from RuleQuickLinks just goes back to the main index page. I'm not sure where we want this to go to since the lookup is brought up in a separate page, but it seems to need to be set or errors occur.

            Show
            jjhanso Jeremy Hanson added a comment - I've commited more changes. The RuleBaseValues lookup's results now contain the columns with the extra fields. It also fixes the links on the RuleQuickLinks page to the correct lookup. Currently, the return location on the lookup from RuleQuickLinks just goes back to the main index page. I'm not sure where we want this to go to since the lookup is brought up in a separate page, but it seems to need to be set or errors occur.
            Hide
            ewestfal Eric Westfall added a comment -

            That's fine as far as return location goes, and yes it does have to be set or the lookup framework throws errors.

            Show
            ewestfal Eric Westfall added a comment - That's fine as far as return location goes, and yes it does have to be set or the lookup framework throws errors.
            Hide
            ewestfal Eric Westfall added a comment -

            Bulk change of all Rice 1.0 issues to closed after public release.

            Show
            ewestfal Eric Westfall added a comment - Bulk change of all Rice 1.0 issues to closed after public release.

              People

              • Assignee:
                jjhanso Jeremy Hanson
                Reporter:
                ewestfal Eric Westfall
              • Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: