User Profile - only one ftl template for all dynamic user profile related actions (register, update/verify profile, IDP review)?
Vlastimil Elias
Hi,
as part of the configurable User Profile work, I'm just working
on dynamic templates for auth flow actions and I'd like to discuss
some more general change. I think now is the good time to
change/clear this area as we are going to introduce new dynamic
templates when configurable user profile is enabled, so there is
not major impact on backward compatibility (old realms with legacy
user profile will use old templates still)
Current state is that there are two "static" templates for these actions:
- register.ftl for registration form
- login-update-profile.ftl used for 'update profile' required action and for 'IDP review' - by my experience, this one mixes together two things which are a bit different (IDP review is more like new account registration) and is a bit hard to customize as context is not clearly available in it.
Both templates are very similar, register.ftl has password and
re-captcha sections on top of update. By my experience from
template customization for sso.redhat.com, customizing template
means to do a lots of duplicate work in these two templates, and
customizing login-update-profile.ftl is not easy due to its
duality and not clear context info.
So I can see three possible ways where to go:
1. use only one template for all these action, with clear CONTEXT
info available from freemarker context, so no duplicate code but
customization per action still possible - IMHO this is the best
option. Also in the light of expected future work to add more
features into the dynamic user profile form (form field types,
attribute grouping, client side validators etc)
2. keep two templates as is, add clear CONTEXT info into dynamic
version of the login-update-profile.ftl to make it's customization
a bit easier (this one will be also used for 'Verify profile'
action automatically forced by user profile rules checks) - close
to current state, a bit easier template customization
3. create separate template for each action - solves problem with
login-update-profile.ftl duality, but IMHO adds lots of duplicate
code and maintenance burden
Any opinion and experiences from template customizers? Which solutions do you prefer and why?
You can share here or in dedicate JIRA https://issues.redhat.com/browse/KEYCLOAK-18541
Thanks in advance
Vlastimil
-- Vlastimil Elias He / Him / His Principal Software Engineer, DXP Application Development Red Hat
Pedro Igor Craveiro e Silva
Hi,
as part of the configurable User Profile work, I'm just working on dynamic templates for auth flow actions and I'd like to discuss some more general change. I think now is the good time to change/clear this area as we are going to introduce new dynamic templates when configurable user profile is enabled, so there is not major impact on backward compatibility (old realms with legacy user profile will use old templates still)
Current state is that there are two "static" templates for these actions:
- register.ftl for registration form
- login-update-profile.ftl used for 'update profile' required action and for 'IDP review' - by my experience, this one mixes together two things which are a bit different (IDP review is more like new account registration) and is a bit hard to customize as context is not clearly available in it.
Both templates are very similar, register.ftl has password and re-captcha sections on top of update. By my experience from template customization for sso.redhat.com, customizing template means to do a lots of duplicate work in these two templates, and customizing login-update-profile.ftl is not easy due to its duality and not clear context info.
So I can see three possible ways where to go:
1. use only one template for all these action, with clear CONTEXT info available from freemarker context, so no duplicate code but customization per action still possible - IMHO this is the best option. Also in the light of expected future work to add more features into the dynamic user profile form (form field types, attribute grouping, client side validators etc)
2. keep two templates as is, add clear CONTEXT info into dynamic version of the login-update-profile.ftl to make it's customization a bit easier (this one will be also used for 'Verify profile' action automatically forced by user profile rules checks) - close to current state, a bit easier template customization
3. create separate template for each action - solves problem with login-update-profile.ftl duality, but IMHO adds lots of duplicate code and maintenance burden
Any opinion and experiences from template customizers? Which solutions do you prefer and why?
You can share here or in dedicate JIRA https://issues.redhat.com/browse/KEYCLOAK-18541
Thanks in advance
Vlastimil
-- Vlastimil Elias He / Him / His Principal Software Engineer, DXP Application Development Red Hat
--
You received this message because you are subscribed to the Google Groups "Keycloak Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to keycloak-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-dev/510e19bf-384a-bd41-3d29-c60b3df3d5e3%40redhat.com.
Vlastimil Elias
On Thu, Jun 24, 2021 at 9:42 AM Vlastimil Elias <vel...@redhat.com> wrote:
Hi,
as part of the configurable User Profile work, I'm just working on dynamic templates for auth flow actions and I'd like to discuss some more general change. I think now is the good time to change/clear this area as we are going to introduce new dynamic templates when configurable user profile is enabled, so there is not major impact on backward compatibility (old realms with legacy user profile will use old templates still)
Current state is that there are two "static" templates for these actions:
- register.ftl for registration form
- login-update-profile.ftl used for 'update profile' required action and for 'IDP review' - by my experience, this one mixes together two things which are a bit different (IDP review is more like new account registration) and is a bit hard to customize as context is not clearly available in it.
Both templates are very similar, register.ftl has password and re-captcha sections on top of update. By my experience from template customization for sso.redhat.com, customizing template means to do a lots of duplicate work in these two templates, and customizing login-update-profile.ftl is not easy due to its duality and not clear context info.
So I can see three possible ways where to go:
1. use only one template for all these action, with clear CONTEXT info available from freemarker context, so no duplicate code but customization per action still possible - IMHO this is the best option. Also in the light of expected future work to add more features into the dynamic user profile form (form field types, attribute grouping, client side validators etc)
2. keep two templates as is, add clear CONTEXT info into dynamic version of the login-update-profile.ftl to make it's customization a bit easier (this one will be also used for 'Verify profile' action automatically forced by user profile rules checks) - close to current state, a bit easier template customization
3. create separate template for each action - solves problem with login-update-profile.ftl duality, but IMHO adds lots of duplicate code and maintenance burden
Kind of agree about #1. Only not sure about how complex the template will be if you start having particularities for each flow. And that is what makes me think that having specific pages is a better long-term solution.
In freemarker we should also be able to use user-defined directives for the code that is common across the different theme templates. That might help with the duplicity and maintenance burden. While still providing a clean separation for the different UIs we need.
As we discussed with Pedro, I tried to use Freemarker macro to share same field rendering code into more page templates, and this works like a charm. So now I think option 3 is the best, having clean page template for each action, but shared code for the field rendering.
Vl.