[keycloak-dev] How to render claim data entry and display?

[Stian Thorgersen]

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at 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 at redhat.com>
> >> To: "Stian Thorgersen" <stian at redhat.com>
> >> Cc: keycloak-dev at 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 at redhat.com>
> >>>> To: keycloak-dev at 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.

> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>