In the current Action architecture it is very difficult to use meaningful property keys other than those statically defined in Action to set up a AbstractButton. For example if I were to add a ROLLOVER_ICON property and wanted to be able to add my Action to a toolbar directly I would have to subclass JButton to use the new property and then JToolbar to use that button. This somewhat runins the conveniance of Action.
Whilst subclassing the components isn't the most difficult thing to do, having a seperate subclass for every Action property I might wish to add is very cumbersume. All those subclasses are bad practice because they do not significently expand the capabilities of the button. Nor will they be used by the JFC, meaning I can only add Actions with bespoke properties to the buttons I create myself. I have two solutions that I think constitute beter practice: 1) Make it the responsibility of the UI to set up a button for a given Action. This way L&F implementors can decide what is allowed on a button, however this would still require some tricky UI subclassing for adding some simple properties to Action. 2) (prefered option) make setup the responsibility of the Action itself via a setup(Jcomponent c) method. The current behavoir would be defined in AbstractAction, ready for subclassing so that an Action may setup the button in any way it likes. Existing setAction( Action a ) should then be changed to defer to a.setup(this). Since the current setAction() behavoir is unsepcified this change is consistant with the jls on binary compatability. Anyone here agree? Hope you found this interesting, Jim _______________________________________________ Advanced-swing mailing list [EMAIL PROTECTED] http://eos.dk/mailman/listinfo/advanced-swing
