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 4:20:17 PM
Subject: Re: [keycloak-dev] How to render claim data entry and display?
On 2/23/2015 9:54 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 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,
>>>>>> registration
>>>>>> page, and in the user self service pages. The thing is that
>>>>>> generically
>>>>>> 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
>>>>>> provide
>>>>>> 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
>>>>> don't
>>>>> 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
>>>>> IMO.
>>>>> 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
>>>>> of
>>>>> 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
>>>> anyways.
>>>
>>> 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
>>> displayed.
>>>
>>
>> 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
>> like shit".
>
> I disagree. A lot customization can be done through pure-CSS (have a look
> at
http://www.csszengarden.com/ 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 usability IMO.
>
Would be nice if you are right, but I don't agree yet. I don't know
enough about .css. Don't you still have to have some semblance of
structure in your HTML document (field sets and order. And all this per
page)?
Of course I'm right ;)
You do have to have some structure that's correct, but it's more about content
than layout if that makes sense.
We can add this iteratively though. First add support for custom claims and a way to
obtain them from a custom template. Then we can look into a way of not requiring custom
templates, at least for the simpler use cases.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com