Provide optional Mutators for Path Mappings

[jblayneyXpanxion]

As a Developer working with complex mappings between domain entities and models that represent views, I want more custom control over the type manipulation between the model/view and the domain entity. More specifically I want to be able to mutate primitive and complex types between domain entities and the models as determined by my application-specific domain logic. Eg:

Primary Domain entity:

@Domain(value="someDomainEntities", includeListeners={ListenerType.persistence})
@Repo(alias="someDomainEntities",value=Database.rep_mongodb, cache=Cache.rep_device)
@Getter @Setter
public class SomeDomainEntity {

        private String bossman = "Antonio";

        private Boolean isAnthemAwesome = true;
}

Other Domain Entity:

@Domain(value="otherDomainEntities", includeListeners={ListenerType.persistence})
@Repo(alias="otherDomainEntities",value=Database.rep_mongodb, cache=Cache.rep_device)
@Getter @Setter
public class OtherDomainEntity {

        private Boolean importantYesOrNoVar = false
}

Model Example (with suggested mutators)

@Model
@Getter
@Setter
@Type(SomeDomainEntity.class)
public static class SomeModel {

         // Typical simple Path usage
        @Path
        @FieldValue
        @Label("Current Bossman")
        private String bossman;

        // Example Path mutator populating Boolean from String
        @Path(value = "/bossman", mutator = IsAntonio.class)
        @FieldValue
        @Label("Is Antonio the man at the top?")
        private Boolean isBossmanAntonio;

        // Example Path mutator populating String from Boolean
        @Path(value = "/isAnthemAwesome", mutator = BoolToYesNoStr.class)
        @FieldValue
        @Label("Is Anthem Great?")
        private String isAnthemAwesome;

        // Suggestion for mutator with Path annotation to a var in a different domain entity.
        @Path(value = "/p/otherDomainEntities:<!/.m/localIdReference!>/importantYesOrNoVar/_get", linked = false, detachedState = @MapsTo.DetachedState(loadState = MapsTo.LoadState.AUTO, mutator = BoolToYesNoStr.class))
        @Label(value = "Look Anthem, its a string populated from a Boolean")
        private String yesOrNo;
}

Where mutators might look something like this (Java-ish pseudo code)

	public interface Mutator<R, T> {
		public R getMutationFromSource(T source);
		public T getMutationFromTarget(R target);
	}
	
	public static class IsAntonio<String, Boolean> implements Mutator {
		@Override
		public String getMutationFromSource(Boolean source) {
			if (source) {
				return "Antonio";
			}
			return "Cannot Determine";
		}
		
		@Override
		public boolean getMutationFromTarget(String target) {
			return target.toLowerCase().equals("antonio");
		}
	}

	public static class BoolToYesNoStr<String, Boolean> implements Mutator {
		@Override
		public String getMutationFromSource(Boolean source) {
			if (source) {
				return "Yes";
			}
			return "No";
		}
		
		@Override
		public boolean getMutationFromTarget(String target) {
			return target.toLowerCase().equals("yes");
		}
	}

Issue Details

Type of Issue (check one with "X")

[ ] Bug Report => Please search GitHub for a similar issue or PR before submitting
[X] Feature Request => Please ensure feature is not already in progress
[ ] Support Request => Please do not submit support requests here, instead see: https://discourse.oss.antheminc.com/

Current Behavior

• Currently type manipulation requires either one or more configs, or a request to the nimbus team for an additional annotation (which often either isn't requested or can't be provided in time)
• It is a frequent practice for Boolean types to be stored as Strings, because it is easier to manage within the framework. An example would be a String stored as either "Yes" or "No", where the application does frequent string comparisons against Yes or No to determine if it is true/false/null.
• Similar to booleans stored as strings, types that could be enums are also frequently stored as strings.

#Advantages

• Would require fewer config annotations, thus a high potential for fewer http calls.
• Per first point, a performance improvement due to conversion on initial lookup vs additional lookups/http calls for conditionals.
• Less indirection. The population of the var is indicated directly in the annotation, whereas a current implementation of type manipulation often involves various config annotations in disparate parts of the code to achieve the desired output.
• More extensible. As this is similar to the Source interface pattern for populating UI Element values/ParamValues which is currently widely used, documented & adopted, it would be simpler for developers to extend and take advantage of.
• Data type accuracy. Developers will opt to use the type that makes the most sense in the domain repo class - I.E. enum, boolean, etc and less likely to use the type that would be the easiest to get working & maintain in the views.

Expected Behavior

• Simple & extensible type mutator option for type/path mappings.
• In uses of the Nimbus framework for apps, var-types in domain entities should consistently map to the simplest type that makes sense to store, rather than the type that will be easiest to pass around and display in all model views.

How to Reproduce the Issue

Not a Defect.

Code Snippet

Not a Defect

Comments/Discussion/Feedback encouraged. Thanks.

Environment Details

• Nimbus Version:
  Current/All/Any