Changing style class depending on security access

[hillkorn]

Hi,

as i tried to add a custom IOCDecoratorExtension i found out that im only able to change the Element classnames if i use a timer because i don't know when the template callbacks are done. If i change it before it will be overwritten what is ok becuase the element normally has only the gwt initial one like gwt-anchor. What i would like to add now is an annotation with that i can specify what decorators should be executed before mine is executed that i can ensure my decorator's InitCallbacks are called afterwards.

[mbarkley]

Hi Dennis,

I am wondering if you can elaborate a bit more on what you're use case is regarding the security styles. If the issue is that you'd like have more control over the style applied with the @RestrictedAccess annotation, would it fix your problem if we had the annotation apply a CSS class with a pre-defined name (i.e. "errai-restricted-class") that you could define styles for, instead of element level styles?

[hillkorn]

Hi Max,

yes Im trying to add a "disabled" style class if the user is not allowed to do an action on that button. I used your example for it but with an own implementation because yours doesn't fit into our needs. And i as i tried it yesterday to implement i found out that it would be really difficult to implement.

My exact problem is that if i add or change the style of the Dom Element it will be overwritten by the template. Maybe a templateFinished callback or something could be a nice to have? That it is possible to change something in the Dom when the template stuff is done.

[hillkorn]

I added a new IOCDecoratorExtension similar to the StyleBinding but this is executed after the Templating is finished so nothing could be overwritten by the template because it's fully initialized.

I will create a pull request the next days.

Greets,

Dennis

[mbarkley]

After talking with csa, we would prefer to try and fix the @RestrictedAccess stylebinding so that it could be used to fit your use-case. I can probably look into it tomorrow and push a change to SNAPSHOTS for you to try out. If I understand your use-case correctly, having a CSS class (that you can define styles for) applied to @RestrictedAccess elements when users are not authenticated should fit your use case?

But a couple other temporary solutions that could allow you to style templated Widgets without having to generate code would be:

• Setting the styles in the @PostConstruct method of the @Templated bean.
• Using an AttachEvent on the element to apply styles when the element is attached to the DOM.

Cheers.

[mbarkley]

Hey Dennis,

I've made the change to @RestrictedAccess so that a style is added to an element when the current user is not authorized. Here is the style name.

You should be able to make an element appear disabled by defining the style with "pointer-events: none; color: grey" or something similar. Does this solve your initial problem?

[hillkorn]

That is what i did too. But the problem was that the executor should run after the templating. And now it is random. The problem in you solution that the templating will read the styles from the html template and set it in the element. Because of that it will be overwritten and enabled. I had simple fix with a timer that checks if the templating is done and then adds the class if necessary but that's really drity. Because of this im writing another extension that's nearly the same like the stylebinding but will be executed on the end of the templating. The pull request should be there on monday.

Have a nice weekend

[hillkorn]

It is fixed now!