Form designer setting, additional methods, and scripting of PCF control

[liun]

Hello all -

Looking at the PCF specs, I've found a few things probably missing, I am curious on how others think. 

Right now a PCF control only requires "init", "updateView", "getOutput", "destroy" methods to be implemented, I may overlook something already in place, but it seems there are more the control should be required to implemented. Give a few examples:

1. The form designer could designate a field to be read-only.  If that field is to use a custom control, the framework should let the PCF know that "you are supposed to be readyonly", and the PCF should behave accordingly. That implies the context.parameters should have something passed in to indicate this field should be readonly (thus impacting how getOutput() is implemented), but I did not see it. (See attached image). Also, the framework should also let the PCF know if the field can not be updated (in the case of calculated field, or the form is a quick view form)

2. The "standard control" has a number of methods that can be invoked: https://docs.microsoft.com/en-us/powerapps/developer/model-driven-apps/clientapi/reference/controls  some of them are handled by the parent container of the PCF, such as setVisible, and is working per my test.  However, a few others that must be handled by PCF itself, for example, setDisabled(). It's common to make certain fields readyonly based on runtime condition, only PCF itself knows how to make itself disabled correctly. That means the PCF should implement setDisabled method as part of the interface specs.

3. Different control type (again, https://docs.microsoft.com/en-us/powerapps/developer/model-driven-apps/clientapi/reference/controls) have different methods that can be called by client script.  For example, lookup control can have "addCustomFilter" method, optionsset control can have "removeOption" method. In the same line of thoughts, PCF should also allow that, say in another way, allow scripting of the control. Basically, if PCF has exposed "public" function/methods of the PCF control, it should be made available to client script to call. At this point, it's not the case. At runtime, after obtaining the reference to the control via formContext.getControl(<attrName>), the object reference has ControlType of "customcontrol:NAMESPACE.PCFCLASSNAME", but none of the extra public methods (beyound getOutput, updateVie etc) are exposed as property of the control. That should be a desired feature, or allow script to gain reference to the PCF instance itself. 

[ben-thompson]

Information on whether a field should be treated as editable or readonly can be found by checking context.mode.isControlDisabled 

If a control is made readonly during it's liftcycle on the form updateView is called to allow you to refresh the control and display the readonly version of it.

From memory Lookup controls aren't fully supported yet within PCF. I'm sure someone on the PCF team will correct me if I'm wrong here.

[liun]

Thanks! Very helpful. Did not thought about inspecting the "mode" property. Was thinking something in the lines of "context.parameters.setting". 

Your answer addressed issue 1 & 2, now I am waiting to see if someone can provide some insight on 3. 

Thanks again.  

[HemantG]

>>Different control type (again, https://docs.microsoft.com/en-us/powerapps/developer/model-driven-apps/clientapi/reference/controls) have different methods that can be called by client script.  For example, lookup control can have "addCustomFilter" method, optionsset control can have "removeOption" method.

Hemant >>  All clientAPIs exposed methods should work for custom controls too including ones which are specific to that type. This should already be working as 1^st party base controls are PCF based. Note that the lookup is not exposed yet for the custom control creation. 

>> In the same line of thoughts, PCF should also allow that, say in another way, allow scripting of the control. Basically, if PCF has exposed "public" function/methods of the PCF control, it should be made available to client script to call. At this point, it's not the case. At runtime, after obtaining the reference to the control via formContext.getControl(<attrName>), the object reference has ControlType of "customcontrol:NAMESPACE.PCFCLASSNAME", but none of the extra public methods (beyound getOutput, updateVie etc) are exposed as property of the control. That should be a desired feature, or allow script to gain reference to the PCF instance itself. 

Hemant >> Internal PCF methods are not exposed to the clientAPI developer beyond what the specific control exposes via documented clientAPIs already. So the getOutput, updateView should not be used from clientAPI. PCF control design is to be isolated from the clientAPI layer and all custom controls should be swappable with the same type.  Going forward as we merge canvas and model concepts, other consumers like expressions need to have that abstration. 

Having said that, there might be cases where additional APIs/Properties make sense or there are bugs for specific control types . You can use https://aka.ms/PCFIdeas for these topics.

Thanks,

Hemant 

[liun]

Thanks Hemant.

I was not refering to calling getOutput from client script, since those are meant to be called by the framework only. I was refering to those potential "Extra" methods. Say, I have a MyNameSpace.DogPCFControl I'd like to expose a "bark()" method in the same line of exposing "removeOption()" method for the optionset control. It should not impacting the "swappability" of teh controls as they are still comforming to the higher level ComponentFramework.StandardControl specs.

Allowing access to the reference of the PCF itself from the parent control (which include label etc) would address this need without too much complication. Basically:

var ctrl = formContext.getControl ("someattribute");
if (ctrl.getControlType() == "customcontrol:MyNameSpace.DogPCFControl") {
    var mypcf= ctrl.getCustomControl(); // this is the asked feature, and can be generic enough with minimal API change
    mypcf.bark(); 
} 

I'll put in the ideas section.

[HemantG · Accepted solution]

MyNameSpace.DogPCFControl is bound to some base type is CDS like say text or number. So the client API calling bark() will not work on the text and numbers when the control is unconfigured. 

We want clientAPIs to be agnostic of the specific control configured and only know the type which cannot be changed once created.  I do see the intent of having more flexibility in terms of signalling the control, we are evalauting eventing and custom parameters support to enable these kind of scenarios.  In the interim you can create additional input parameters to the controls and use them to signal control for specific behaviours. So i can define input parameter as bark and when the bark value is set to true using the client API, MyNameSpace.DogPCFControl can bark. 

Please log the idea so that we have handle on the ask.