SUP-19204: Fill roles from Handlebars (POC) #702
Conversation
| .resolver(MapValueResolver.INSTANCE, JavaBeanValueResolver.INSTANCE) | ||
| .combine("cms", new ResolvableMapWrapper(renderType.getCMSResolver())) | ||
| .build(); | ||
| ctx.combine("renderType", renderType); |
There was a problem hiding this comment.
Need a rendertype around for the access to the expression parser.
There was a problem hiding this comment.
The rendertype can be fetched from the current transaction, which is a threadlocal, so no need to inject it into the context.
|
|
||
| getPartType(HandlebarsPartType.class, tag, HBS_PART_KEYWORD) | ||
| .getValueObject() | ||
| .setValueText(Arrays.stream(roles).map(role -> String.format("'%s'", role)).collect(Collectors.joining(",", "{{#gtx_store_expr '" + VTL_ROLES_FIELD + "'}}[", "]{{/gtx_store_expr}}"))); |
There was a problem hiding this comment.
{{#gtx_store_expr 'roles'}}
[
'anonymous',
'role_b'
]
{{/gtx_store_expr}}
can also be (less flexible) expressed as
{{{gtx_store 'roles' (gtx_expr "['anonymous','role_b']")}}}
npomaroli
left a comment
npomaroli
left a comment
There was a problem hiding this comment.
I would like to have much more tests for this, and we should discuss, whether we want to add this as hotfix or as a new feature.
| */ | ||
| public static Object gtx_expr(String input, Options options) throws ParserException, ExpressionParserException { | ||
| RenderType renderType = (RenderType) options.context.get("renderType"); | ||
| return CnMapPublisher.parseExpression(renderType, input); |
There was a problem hiding this comment.
Do not use CnMapPublisher here, handlebars parts and publishing into a content repository are two separate things. Also this would make using the expression parser depend in the content repository specific feature "tagmap_useexpressionparser"
| .resolver(MapValueResolver.INSTANCE, JavaBeanValueResolver.INSTANCE) | ||
| .combine("cms", new ResolvableMapWrapper(renderType.getCMSResolver())) | ||
| .build(); | ||
| ctx.combine("renderType", renderType); |
There was a problem hiding this comment.
The rendertype can be fetched from the current transaction, which is a threadlocal, so no need to inject it into the context.
This is a heavy change, so formed as a POC, so no docu/changelog/fullfilling tests yet.