Open HitmanInWis opened 1 month ago
FWIW seems similar issues exist trying to use parameterized vars within granite:class
and granite:data
attributes as well.
For modern versions of AEM, I wonder if this feature could/should be reworked to use ExpressionCustomizer
?
Required Information
Expected Behavior
When I use the Parameterized Include feature (https://adobe-consulting-services.github.io/acs-aem-commons/features/parameterized-namespace-include/subpages/parameter-example.html) I expect to be able to use variables for the
granite:hide
property so that the parent dialog that is including a dialog snippet can signal to hide certain fields.Actual Behavior
Putting a variable of
${{myvar}}
into thegranite:hide
attribute causes the dialog to fail to load, with a stack trace that looks like the following.It appears that the
granite:hide
attribute is evaluated prior tocom.adobe.acs.commons.granite.ui.components.NamespacedTransformedResourceProvider#transformResourceWithNameSpacing
getting a chance to transform the variables. I validated this in a debugger, where the function is not called at all for my field when a parameterized var is ingranite:hide
. I also hacked the value ofgranite:hide
fromNamespacedTransformedResourceProvider
via the debugger with "true" and my field was still not hidden, further backing the theory thatgranite:hide
is processed prior toNamespacedTransformedResourceProvider
executing to transform variables.Steps to Reproduce
Simply use a parameterized variable in a child dialog snippet within the
granite:hide
property of a dialog field.cc: @niekraaijmakers