team to not have it in 1.0 ? I
guess dynamic templates can be postponed, but at least missing
validation for account mgmt and update profile is quite a gap IMO.
I've discussed this with Vlasta a week or two ago (and that's one of
main reasons to write this email btv :-) )
Marek
On 06/11/15 15:04, Stian Thorgersen wrote:
I think this is something to look at next year. We don't have the
resources to do it properly now. My vote is to add it to the agenda
for F2F.
On 6 November 2015 at 14:36, Marek Posolda <mposolda(a)redhat.com
<mailto:mposolda@redhat.com>> wrote:
On 05/11/15 17:11, Bill Burke wrote:
>
> On 11/5/2015 5:46 AM, Marek Posolda wrote:
>> I wonder if we should improve handling of custom attributes in
>> freemarker templates and their validation. Let's assume that I
want to
>> add custom attribute "birthday" and I want to add it to all
screens
>> where user can create/edit account. I can see those issues:
>>
>> - Admin will need to edit 3 separate freemarker templates
(registration,
>> account management, update profile page) to have this attribute
>> displayed on all those places.
>>
> we've discussed this before. The problem is formatting in each
of the
> UIs. Often ordering of attributes is important. Grouping of
attributes
> is a must too.
>
> i.e. Address, State, Country, Postal Code
>
> These 4 attribute must be grouped together, and address must
come before
> state, and so on.
>
> You might also have a "Billing Address" group that needs to come
after
> Home Address group.
I am not seeing an issue with ordering? The same order you
configure in
admin console, the same is used in template. It's classic sorted list,
not special tricks needed IMO. The grouping some attributes can be
easily addressed too IMO.
>
> So, we'd have an automatic way for displaying attributes, then the
> developer would think "that looks like shit" and want to format
things
> himself. Stian seems to think that CSS will solve this problem,
but I'm
> not convinced.
CSS can do a hell of a lot more than you think it can ;)
But, I agree it can't always cover everything - that's why I've been
saying we need to be able to define templates, but at a smaller
granularity. Having to define the whole update-profile page just to
add an attribute is not very elegant.
I agree we can't address all possible sort of issues, but IMO it's
good
to have something, which will address 90% of cases? We can provide
types
(like combobox "Gender" with values "male" / "female"
). We can also
handle multivalued attributes. And most importantly we can provide
validations for all 3 screens. People won't need to write their
own Java
validators when they want something simple like ensure "mandatory"
field
present or validate with regex. They will still have possibility to
inject the custom validator if they want it.
At least validation is must IMO as there is no way to add custom
validation for account mgmt or update profile right now.
What we can't easily do is client-side validation and stuff for
display/hide something based on value of other attributes (For example
display attribute "Favourite car sign" just if selected gender is
"male"
). But not sure if this is often requirement.
I am seeing lot of similarity with your kc-provider-config
directive in
admin console. It can't address all "generic" sort of things and
client-side stuff etc. But for most cases, it's sufficient.
>
> Also the look and feel could be quite different between
registration,
> update profile, account management, and the admin profile. IMO, it
> would end up being easier to just edit the freemarker pages directly
> than to have to define each attribute and how it is grouped,
ordered,
> and displayed on each of the pages within an admin console UI.
>
>
There could be 3 checkboxes where can admin select if he wants to add
field on registration, account mgmt and update profile. I am not
sure if
we need anything for admin console as we already have "Attributes" tab
for users, which is almost ok IMO (we don't have nice solution for
multivalued attributes).
Marek
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev