For instance, we would like to build a masking control. That would format a number based on the country the record is associated with. Furthermore we are adding the control to Dynamic CRM. Is there a way the we could load/access the form API (i.e. Xrm.Page.getAttribute("name").getValue()) vs making a call to the database?
Using the control input property is of course the best solution for this use case, because it keeps it generic.
But what if the rules for the masking control should be stored somewhere else, allowing the customizer to define their own rules, based on the country? This configuration is not on the form.
1. One option would be to have a custom entity, where each record represents a country and a masking rule. In this case we can access the database using the Xrm.WebApi since that is stated in the sdk( The problem with that is that we need to install default data, that makes it harder to transport the solution). https://docs.microsoft.com/en-us/powerapps/developer/component-framework/reference/webapi
2. The second option would be to store the configuration in a webResource (like a JSON config). But it seems to me that the context.resources.getResource method from the sdk (https://docs.microsoft.com/en-us/powerapps/developer/component-framework/reference/resources/getreso...) is only designed to load resources from inside the control, that are not accessible to a system customizer. To write our own resource loader (for a normal webResource) we would need some context informations like the clientUrl which I didn't found, so also not possible.
3. Or is it recommended wo use another input property with a fixed value, pasting the whole JSON configuration inside?
Interesting options Diana, nice writeup. I am thinking for option 1, in order to address limitation of migrating sample data to the custom entity, may be control can have the base rules for the country in the code which control can write to custom entity when loaded first time (using fixed guid). These rules can then be edited by the customizer to fine tune in the org as needed. Something like
1. Control load very first time in the org, checks the config entity with given guild (webAPi retrive) and sees record not present. Creates the record with base rules present in the control (TS or XML).
2. When the control loads next time it finds the rules and uses them. Also control writes the relevant rule info into local storage using SetState PCF api so that the server call is not needed next time control loads. Uses the cached value to load immediately and sends a call in background to check if there is refreshed data.
3 Control can also surface the link to config entity if there is user specific customizations need, like toggle to address validaor by pressing ctrl + Y. User might be in a fixed timezone but does not mean that the addresses he is entering are same country. Toggle at the top and show hide controls default vs custom is another option.
Verry interesting ideas Hemant. Thank you for sharing
You've mentioned saving in local storage using SetState PCF api . Unfortunatelly i didn't found this feature.
Is the documentation refering this still to be done, or am I just missing it? Or maybe there is an example for that?
Are the input controls static? If so, I do not think this would work as our most common use case would be creating a new lead/contact. And in that scenario, we would not know the country they belong to until it was populated (i.e. when the form loaded we would not know the country as it is blank).
Hemant, unless I am missing something. This will only load files that I have pre-defined. In this scenario, the Xrm API would not be available until run time, as it is full managed by the application itself.