----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: "Stian Thorgersen" <stian(a)redhat.com>
Sent: Monday, February 23, 2015 3:43:11 PM
Subject: Re: [keycloak-dev] How to render claim data entry and display?
On 2/23/2015 9:13 AM, Stian Thorgersen wrote:
> ----- Original Message -----
>> From: "Bill Burke" <bburke(a)redhat.com>
>> To: "Stian Thorgersen" <stian(a)redhat.com>
>> Cc: keycloak-dev(a)lists.jboss.org
>> Sent: Monday, February 23, 2015 2:59:13 PM
>> Subject: Re: [keycloak-dev] How to render claim data entry and display?
>> On 2/23/2015 8:21 AM, Stian Thorgersen wrote:
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke(a)redhat.com>
>>>> To: keycloak-dev(a)lists.jboss.org
>>>> Sent: Friday, February 20, 2015 3:15:19 AM
>>>> Subject: [keycloak-dev] How to render claim data entry and display?
>>>> I'm not sure how to render claims within the admin console,
>>>> page, and in the user self service pages. The thing is that
>>>> rendering user metadata can look quite ugly. Address is one example
>>>> where the grouping and ordering of each attribute is important to look
>>>> nice. There are other instances where you need to group types of data
>>>> together (home phone, fax, work phone, mobile). Then there is the
>>>> problem of what claim data do you show on what pages which is harder
>>>> than it seems, for example, registration page might only require a
>>>> mobile number, but admin console and user profile page might want to
>>>> show home, fax, work too. You would end up having to define a data
>>>> model that captured metadata for each page type (registration, user
>>>> profile, and admin console). Finally, if you have generically rendered
>>>> claims, what happens when the user wants to override this rendering and
>>>> put their own formatting, .css types, etc. in?
>>>> This leads me to think that we should just punt to the developer. In
>>>> this case, there would be no data model for claim types and everything
>>>> would be driven simply off of UserModel.attributes. Develoeprs would
>>>> have to extend the admin console and account themes and we would
>>>> a template for referencing UserModel.attribute data within Angular HTML
>>>> (admin console) or Framemaker (account service, registration page).
>>> For registration page and account management I think supporting simple
>>> attributes in the default template would be good enough. Users can then
>>> extend the templates if they need something more. In the future we can
>>> look into creating widgets that can display certain things so users
>>> have to extend the whole template, but just parts of it.
>>> For the admin console it would be best not to require users to extend
>>> We should be able to allow users to view and edit complex attributes (at
>>> least a complex attribute that is a list of simple, rather than complex
>>> complex). Initially we could just display the JSON for the complex
>>> attribute directly, then create an view/editor for it later.
>> I just don't want us spending time implementing and maintaining an HTML
>> editor for something the user will usually be extending a theme for
> Yes, I totally agree, but that wasn't what I proposed though. What I'd
> propose we do is:
> * Admin console - just list claims, sorted by name. For simple types we
> display the value and allow editing with input text. For complex we
> display json and allow editing in textarea. In the future we can add a
> feature that allows view/edit complex attributes directly.
> * Registration and account management - only display simple types. We
> should provide some mechanism for choosing which are displayed and order.
> For complex types or better control on how it's displayed (other than a
> simple list of label, input) users are expected to extend the template. In
> the future we can add a feature that allows extending parts of a template,
> which would make it easier to edit and also maintain in the long run. For
> example instead of overriding the whole registration page a user could
> override just the form part, or even just how a specific claim is
I think users will be extending our themes anyways almost every time
(except the admin console). As, again, anything generically rendered
will look ugly and unprofessional. I started off implementing it the
way you are saying...but then I was like, "This is dumb and will look
I disagree. A lot customization can be done through pure-CSS (have a look at
if you don't believe me) and in the event they need to
modify the HTML they most likely only want to change a small part of it. Requiring users
to override the registration page just to display a dob field for example is not good
JBoss, a division of Red Hat