7:44 a.m.
Hi,
2 or 3 is not good options. Both would take a fair bit of time to add and
would have migration issues.
1 would probably work, we could add a simple directive that can transform a
string into a form that can be used in the name attribute.
However, in this case I think it's better to just use an XPath expression.
As the test would be the thing to add the mapper and set the name in the
first place it should be consistent. Especially if you'd add a id to the
table and just look for the name within that table.
On 2 October 2015 at 19:36, Vaclav Muzikar <vmuzikar(a)redhat.com> wrote:
Hi all,
I'd like to discuss missing @id and @name attributes on UI elements of
Mapper Type Properties (related issue:
https://issues.jboss.org/browse/KEYCLOAK-1885).
This concerns e.g. creating/editing a Client Protocol Mapper. When you
choose the Mapper Type, the following properties (like "Token Claim Name"
in case of "Hardcoded Claim") don't have any @id or @name.
This properties are used on more places all over the Keycloak (the
template is "kc-provider-config.html" in
"keycloak-forms-common-themes"
module).
At QE we'd like to add @id for every of these elements so we don't need to
use relative XPath locators based on labels, AngularJS
directives/attributes etc. which could be unstable.
The problem is there's no suitable (object) attribute of these properties
to use as HTML @id or @name.
The closest thing to this is the mapperType.property.name but it's using
illegal characters (spaces) for @id in some cases. E.g. "Claim value" uses
the "claim.value" name which is OK but "Claim JSON Type" uses
"Claim JSON
Type" name (yes, the name is same as the label) which can't be used in HTML
as @id because of spaces.
I've got some solutions on my mind.
*1) Replacing the spaces on the client site (using AngularJS controllers)* which
is probably not a nice solution. The Mapper Types (and it's properties) are
used on more than one sites/controllers and I haven't found any global
getter or something like that for Mapper Types which could contain this
replacement code. As far as I know, Mapper Types are fetched using
ServerInfo service. But this service is pretty abstract and simple so I
don't think it's a good idea to do the replacement there.
That means we need to add some getter and rewrite the controllers to use
this getter or copy-paste the replacement code all over the controllers
which is obviously out of the question.
*2) Add a new ID attribute to the REST API* so the ServerInfo service
would distribute this attribute to all controllers and templates.
*3) Change the "name" attributes* so it can be used as @id. Possible
problem could be compatibility and migration of
current Keycloak installations to the newer version.
Can come upon any other solution? Could you implement any of it?
Thank you!
Best regards,
Václav Muzikář
Keycloak QE
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev