Form Control Dependency In Alfresco Share

[rfernandes]

So you need to make the options available on your Alfresco Share select form html fields depending on each other? But unfortunately your content model in Alfresco does not allow you to group constraint value options and say 'show these values for this field if user selected the value X for that other field, and change it (without reload) when he selects the value Y”… There's no way right now of configuring that through out of the box Alfresco constraints.  This post shows a simple way of achieving this in a generic way with some customization (just a pair of form controls freemarker templates) allowing for any changes on the dependency configuration for your properties to be immediately recognized by Alfresco Share.



First of all you can check the source code at the Google Code Project (the code on head has been tested for Alfresco Enterprise 4.0.0): http://code.google.com/p/share-form-control-dependency/



This customization allows you to control that only some sets of values are used for a set of dependent properties at the UI (Share) level. This won't be constrained at the repository level even if the dependency control configuration is 'specified' at the content model level (it's really based on a convention that only our Share form controls know about).



In pictures, if you select value A for the main property the conditioned property One should automatically just present the corresponding allowed values. The same for any other conditioned property Two.







The basic idea is to have specific form controls for Alfresco Share aware of the convention used to configure in our content model those dependencies and also have those generic form controls empowered (through client javascript) to update the corresponding form controls according to the updates made by the user on the other associated properties.



So if we define our constraints like (check sample model on our google code project):

<constraints> 

<constraint name='sample:parentConstraint' type='LIST'> 

<parameter name='allowedValues'> 

<list> 

<value></value> <value>1 - VALUE A</value> 

<value>2 - VALUE B</value> 

<value>3 - VALUE C</value>

 </list> 

</parameter> 

</constraint> 

<constraint name='sample:constraintOne' type='LIST'> 

<parameter name='allowedValues'> 

<list> 

<value></value> 

<value>1 - SUBVALUE ONE AX</value> 

<value>1 - SUBVALUE ONE AY</value> 

<value>1 - SUBVALUE ONE AZ</value> 

<value>2 - SUBVALUE ONE BX</value> 

<value>2 - SUBVALUE ONE BY</value> 

<value>3 - SUBVALUE ONE CY</value> 

<value>3 - SUBVALUE ONE CZ</value> 

</list> 

</parameter> 

</constraint> 

<constraint name='sample:constraintTwo' type='LIST'> 

<parameter name='allowedValues'> 

<list> 

<value></value> 

<value>1.2.3 - SUBVALUE TWO ABCX</value> 

<value>2.3 - SUBVALUE TWO BCX</value> 

<value>2.3 - SUBVALUE TWO BCY</value> 

<value>2.3 - SUBVALUE TWO BCZ</value> 

<value>3 - SUBVALUE TWO CX</value> 

<value>3 - SUBVALUE TWO CY</value> 

<value>3 - SUBVALUE TWO CZ</value> 

</list> 

</parameter> 

</constraint> 

</constraints>

What we are trying to say (through convention: our repository really doesn't know about this...) is that some possible values for properties one and two (to which will apply the constraintOne and constraintTwo) just should show if the corresponding group value (the number which starts the value) was selected for the main property. If the value selected for the main property changes we will also want to change the shown values for the other properties one and two.



For cases  like 1.2.3 - SUBVALUE TWO ABCX in the constraintTwo, we will want the value to be available for property two for whatever value (1, 2 or 3) is selected  for the main property. We also don't want the values to be presented with the preceding main property association 1 -, 2 -, etc. And finally we want all updates to happen dynamically as user fulfills the form.



Well that's exactly what our custom form control components do. They are generic and can be used for any equivalent case. Just build the jar, incorporate in your project and finally configure your form for Alfresco Share:

<form> 

<field-visibility> 

<show id='sample:mainProperty' /> 

<show id='sample:propertyOne' /> 

<show id='sample:propertyTwo' /> 

<show id='sample:propertyThree' /> 

</field-visibility> 

<appearance> 

<set id='sample-2col' template='/org/alfresco/components/form/2-column-set.ftl'/> 

<field id='sample:mainProperty' set='sample-2col'> 

<control template='/org/alfresco/components/form/controls/parent-filter-selectone.ftl'> 

<control-param name='filteredProperty'>sample_propertyOne,sample_propertyTwo</control-param> 

</control> 

</field> 

<field id='sample:propertyOne' set='sample-2col'> 

<control template='/org/alfresco/components/form/controls/filtered-selectone.ftl'/> 

</field> 

<field id='sample:propertyTwo' set='sample-2col'> 

<control template='/org/alfresco/components/form/controls/filtered-selectone.ftl'/> 

</field> 

</appearance> 

</form>

As you see we are using the same custom form control filtered-selectone.ftl for both conditioned properties, and another parent-filter-selectone.ftl for the main one (if you import this into your project these two freemarker files are the only ones you should care about, everything else on the google project is for the sake of demonstration). This last one must also receive the list of conditioned properties (separated by comma) as a control-param. As the dependency is defined this way at the form control configuration level this allows for us to have many separated groups of associated properties in the same form.



And with that in place the magic will happen.







Pay attention as besides the dynamic filtering of values we also have the initial numbers who define our dependency convention ripped from the values shown in the form.



The good stuff is that this is fully generic and can be used for any form, type or aspect, including search forms, data-lists types, and so on.



Finally the last advantage is that it allows you to manage the associated dynamic behavior of your properties just by configuring your content model constraints, that can be located in a dynamic model for example and so allow for hot update without server restart.