----- 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)?
--
Bill Burke
JBoss, a division of Red Hat