[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 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 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.
> >
> 
> 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
>