<div dir="ltr">Hi,<div><br></div><div>2 or 3 is not good options. Both would take a fair bit of time to add and would have migration issues.</div><div><br></div><div>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. </div><div><br></div><div>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.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 2 October 2015 at 19:36, Vaclav Muzikar <span dir="ltr"><<a href="mailto:vmuzikar@redhat.com" target="_blank">vmuzikar@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi all,<div>I'd like to discuss missing @id and @name attributes on UI elements of Mapper Type Properties (related issue: <a href="https://issues.jboss.org/browse/KEYCLOAK-1885" target="_blank">https://issues.jboss.org/browse/KEYCLOAK-1885</a>).</div><div>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.</div><div>This properties are used on more places all over the Keycloak (the template is "kc-provider-config.html" in "keycloak-forms-common-themes" module).</div><div><br></div><div>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.</div><div><br></div><div>The problem is there's no suitable (object) attribute of these properties to use as HTML @id or @name.</div><div>The closest thing to this is the <a href="http://mapperType.property.name" target="_blank">mapperType.property.name</a> 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.</div><div><br></div><div>I've got some solutions on my mind.</div><div><br></div><div><b>1) Replacing the spaces on the client site (using AngularJS controllers)</b> 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.</div><div>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.</div><div><br></div><div><b>2) Add a new ID attribute to the REST API</b> so the ServerInfo service would distribute this attribute to all controllers and templates.</div><div><br></div><div><b>3) Change the "name" attributes</b> so it can be used as @id. Possible problem could be compatibility and migration of current Keycloak installations to the newer version.</div><div><br></div><div>Can come upon any other solution? Could you implement any of it?</div><div><br></div><div>Thank you!</div><div><br></div><div>Best regards,</div><div>Václav Muzikář</div><div>Keycloak QE</div></div>
<br>_______________________________________________<br>
keycloak-dev mailing list<br>
<a href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br></blockquote></div><br></div>