Dynamic Property Sheet

cancel
Showing results for 
Search instead for 
Did you mean: 

Dynamic Property Sheet

resplin
Intermediate
0 0 1,146

Obsolete Pages{{Obsolete}}

The official documentation is at: http://docs.alfresco.com



JSF Component
The description of this component and it's usage is shown in the Component Library.


Manual Configuration Implementation Details


When manually configuring the property sheet using standard JSF tags is there a way we can reduce the binding expression by having some smarts built into client side representations of the Data Dictionary service and similar objects?

Using custom variable and property resolvers was investigated. The intent was to either support the standard JSF tags using value bindings like '#{_node.description}' and '#{_nodeMetaData.description.displayName}' or to allow the standard tags inside the property tag and allow value bindings like '#{_nodeProperty.value}' and '#{_nodeMetaData.displayName}'.

However, there are a couple of problems with both these approach. JSF uses a variable resolver to get the first part of the expression, this has to evaluate to an object. In the case of '_nodeMetaData' this would need to evaluate to a MetaData object (for the node) retrieved from a Data Dictionary service. The variable resolver however, does not get passed the component it is being evaluated for. So to find out which type to retrieve the meta data for, the custom variable resolver would have to get hold of the view root and walk the component hierarchy to find the property sheet component in order to retrieve the type of the node being examined. Possible but will probably have a performance hit.

In the case of using the property tag and a value binding of '#{_nodeMetaData.displayName}' there is a more serious problem. The variable resolver would be able to find the meta data object for the node type as explained previously, but when it comes to determining which property to retrieve from the meta data it will not know! As mentioned earlier this is because the component the expression is being evaluated for is not passed, it can't be looked up either as it could relate to any of the properties defined in the property sheet.

We could introduce a dependency between the property tag and the standard tags i.e. the property component could retrieve it's children and call appropriate setters but this would limit the customisation that could be achieved as certain rules would have to be put in place. It was therefore decided to have the 2 distictly different approaches for manual configuration.