Currently there is a coupling of methods and resource definitions. While this makes sense in some limited fashion as a convenience to not have to pass the target_resource_def_eh into the method call, it also means we have to be careful to always change this when if we update things, since we never validate if the resource def eh is correct given the passed in resource eh. It also requires us to create methods for each resource type that will use a specific method which seems counter to the desire to have generic "programs" as methods for computing assessments along a specific dimension for a specific resource. In fact, the resource_def_eh really should only matter for filtering for specific views of specific resources.
Instead we should change things so that we need to pass the resource_def_eh into the method call function and remove the target_resource_def_eh parameter. So we need to:
[x] remove target_resource_def_eh from both the coordinator and integrity zome
[x] add the resource_def_eh parameter to the invoke method zome fn
[x] remove target_resource_def_eh from method.ts in the sensemaker client
[x] add the resource_def_eh parameter in the invoke method call in the client
[x] change AssessDimensionWidget to call runMethod with the correct parameters.
[x] change tests to reflect those changes
[x] remove target_resource_def from ConfigMethod in the client
[x] remove target_resource_def from ConfigMethod in the integrity zome and the TryFrom conversion.
[x] remove target_resource_def from mocks & tests
[x] remove target_resource_def from the sample-config
[x] update documentation
I have not checked to see what changes need to be made in apps or the nh-launcher. But those should be separate tickets.
Currently there is a coupling of methods and resource definitions. While this makes sense in some limited fashion as a convenience to not have to pass the
target_resource_def_ehinto the method call, it also means we have to be careful to always change this when if we update things, since we never validate if the resource def eh is correct given the passed in resource eh. It also requires us to create methods for each resource type that will use a specific method which seems counter to the desire to have generic "programs" as methods for computing assessments along a specific dimension for a specific resource. In fact, theresource_def_ehreally should only matter for filtering for specific views of specific resources.Instead we should change things so that we need to pass the
resource_def_ehinto the method call function and remove thetarget_resource_def_ehparameter. So we need to:target_resource_def_ehfrom both the coordinator and integrity zomeresource_def_ehparameter to the invoke method zome fntarget_resource_def_ehfrom method.ts in the sensemaker clientresource_def_ehparameter in the invoke method call in the clientAssessDimensionWidgetto callrunMethodwith the correct parameters.target_resource_deffromConfigMethodin the clienttarget_resource_deffromConfigMethodin the integrity zome and theTryFromconversion.target_resource_deffrom mocks & teststarget_resource_deffrom the sample-configI have not checked to see what changes need to be made in apps or the nh-launcher. But those should be separate tickets.