Win a copy of Cross-Platform Desktop Applications: Using Node, Electron, and NW.js this week in the JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

How was this disabling done?  RSS feed

 
Rich Smyth
Ranch Hand
Posts: 87
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I worked on an a Swing (1.2) GUI where the command buttons switched between 'enabled' and 'disabled' state independent of security issues. In the final stages of development, the buttons were hooked up to a home-grown security framework by inluding the statment:
SecurityManager.protect (myJButton, "delete_employee").
No other changes were made to the existing button logic.
Once the button was 'secured' by the framework, the button was *always* disabled if the user did not have the privilege to execute the funtion. It was as if the button's setEnabled method had been overriden by the equivalent of:
public void setEnabled(boolean newValue) {
super.setEnabled( SecurityManager.canEnable(this) && newValue ); }
e.g. the security system returns false if the user is not authorized to perform the function.
How might this additional enable/disable logic be 'added' to a defined JButton (not a subclass)?

Rich
 
raj madhuram
Ranch Hand
Posts: 71
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Rich,
Possibly like this:

I don't think it is possible to dynamically override a method. Hope that helps. I would be interested to know if you find out more about the implementation.
thanks,
Raj
 
Rich Smyth
Ranch Hand
Posts: 87
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The problem with adding a listener to enforce the button's state is, as you point out, the button's other ChangeListeners: they cannot be removed. Leaving the existing listeners is risky because any one of them could receive the event before the state is reverted.
So I'm not convinced that the security behavior was accomplished with ChangeListener. But I don't yet have a better guess either.
Rich
 
Nathan Pruett
Bartender
Posts: 4121
IntelliJ IDE Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I was working on an example also, but using PropertyChangeListeners instead of ChangeListeners. My solution also suffers the problem that if the button is attempted to be enabled, then it will be enabled for a short time before the listener disables it. However, I think that it may have been done this way... the main focus of the SecurityManager class may have been simply to keep users from clicking on the button. Maybe they just ignored (or forgot about) other listeners in the code caring about the enabled state of the buttons.

Anyway, here's the code... first the SecurityManager :


and now a test class... the security permission to allow you to enable the button is "enabler"...


Enjoy!
 
Rich Smyth
Ranch Hand
Posts: 87
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for the example Nate.
The intent of the security manager was certainly to prevent the user from pressing a button that executed an unauthorized function. To this end the listener approach works fine. Perhaps the designers were prepared to accept the risk that another ChangeListners or PropertyChangeListeners could cause unwanted behavior?
I'd like to think they had a better solution.
Rich
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!