[KULRICE-3319] Determine if we need to do some work on the KimTypeService interface to make return types more consistent Created: 02/Jul/09 Updated: 23/Feb/12 Resolved: 01/Aug/11
|Project:||Kuali Rice Development|
|Component/s:||Development, Documentation, Version Compatibility|
|Fix Version/s:||2.0.0-m7, 2.0|
|Reporter:||Eric Westfall||Assignee:||Travis Schneeberger|
|Remaining Estimate:||2 days|
|Time Spent:||Not Specified|
|Original Estimate:||2 days|
Ailish sent the following to the Rice dev list in response to a question about the purpose of these different methods, notice her concern on the differences in return types for these:
validateAttributes: make sure the values are the right size and shape and if there is a reference table that they exist and are active
validateUniqueAttributes: make sure the principal doesn't have another assignment with the same values for these unique attributes
validateAttributesAgainstExisting: seems like this is just giving the opportunity to provide a good error for validateUniqueAttributes, given the different return vals and the fact that the example i see in kfs... they are being used in conjunction with one another? location of the method at the end of kim type service base also leads me to believe this was an afterthought, and perhaps refatoring should have been done to make all validate methods return an attribute set instead of a boolean?
validateUnmodifiableAttributes: make sure the values on the assignment that are considered keys are not changed during an edit... for example for accounting organization hierarchy... chart, org, and doc type cannot change during an edit... but from and to amount and override code can
fwiw - i worry about the variation in which methods return List<String> vs. AttributeSet vs. boolean here
not sure if you're looking at kfs code, but the best reference implementations would be there.
|Comment by Travis Schneeberger [ 18/Jul/11 ]|
validateUnmodifiableAttributes() & validateUniqueAttributes() should probably not be on the service interface. Instead this validation checks should just be done by validateAttributesAgainstExisting(). The reasoning behind this is unmodifiable & uniqueness checks are just a type of validation against an existing attribute.
|Comment by Rice-CI User (Inactive) [ 21/Jul/11 ]|
Integrated in rice-trunk-nightly #126 (See http://ci.rice.kuali.org/job/rice-trunk-nightly/126/)
|Comment by Jessica Coltrin (Inactive) [ 23/Feb/12 ]|
Closing since these items are now in the release notes.