Hi Jim,
The other solution that I can think is :
Define an abstract class (CustomAction) which subclasses AbstractAction and
where user can specify non-static property
viz: ROLLOVER_ICON and others. User Action class(XAction) will now extend
CustomAction
ie public XAction extends CustomAction. It is this instance that the user will
add to the
toolbar or menu which in turn returns the reference of JButton or JMenuItem
depending where
the user is adding it and then the user can customize the returned Component
with the XAction
non-static properties.
Rgds
Puneet
[EMAIL PROTECTED] on 03/25/2003 10:59:50 AM
Please respond to [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc: (bcc: Puneet Gupta/HSS)
Subject: Advanced-swing digest, Vol 1 #501 - 1 msg
Send Advanced-swing mailing list submissions to
[EMAIL PROTECTED]
To subscribe or unsubscribe via the World Wide Web, visit
http://eos.dk/mailman/listinfo/advanced-swing
or, via email, send a message with subject or body 'help' to
[EMAIL PROTECTED]
You can reach the person managing the list at
[EMAIL PROTECTED]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Advanced-swing digest..."
Today's Topics:
1. Limitations of Action (Jim Higson)
--__--__--
Message: 1
From: "Jim Higson" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Subject: Limitations of Action
Date: Tue, 25 Mar 2003 00:00:00 -0000
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
End of Advanced-swing Digest
_______________________________________________
Advanced-swing mailing list
[EMAIL PROTECTED]
http://eos.dk/mailman/listinfo/advanced-swing
