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.