Yes, I understand this workaround, In fact I use a similar one myself. However the point of my mail was less looking for a way to do a particular thing with Action and more seeing if anyone agrees this is a problem in swing, and eventually maybe submit a JSR.
Your solution could get the *effects* I'm looking for, but I assert that the definition of Actions is a lower-level interface function than the construction of it's components. The high-level UI code should be able to add an action to one of it's components without any knowledge of how those actions work or how they are defined. Performing additional setup removes the original abstractButton.setAction( Action a ) elegance
Many parts of my program dispense Actions without knowing how the actions will be used. If an Action were to be used in a GUI builder for example the user should be able to dnd any Action (XAction) into any supporting component without prior knowledge of the Action's superclass (CustomAction).
I use a different work-around, below. It is basically a bit of code encapsulating the responsibility I believe should belong to Action. It doesn't at this moment cover JMmenuBars, but you get the point. The problem is that for a user to get the desired effect from my Actions they need to know about this implementation artifact, and if everyone has their own workaround it gets pretty confusing!
Jim;
package util.swingUtils;
import javax.swing.event.*;
import javax.swing.*;
import util.*;
/**
* <p>Title: Javea</p>
* <p>Description: immune debut</p>
* <p>Copyright:s Copyright immune (c) 2002</p>
* <p>Company: immune</p>
* @author Jim higson
* @version 2.5
*/
public class MyActionProperties
{
public static final String ROLLOVER_ICON = "rollover action";
private MyActionProperties(){};
/** adds an Action to a JComponent, use in place of normal way, damn Actions!
currently supports AbstractButtons and JToolbars **/
public static void add( Action a , JComponent jc ) throws IllegalArgumentException
{
if( jc instanceof AbstractButton )
{ if( jc instanceof JMenu )
{ JMenu jm = (JMenu)jc;
additionalButtonSetup( jm.add( a ) , a );
return;
}
AbstractButton button = (AbstractButton) jc;
button.setAction( a );
additionalButtonSetup( button , a );
return;
}
if( jc instanceof JToolBar )
{ JToolBar jtb = (JToolBar)jc;
additionalButtonSetup( jtb.add( a ) , a );
return;
}
throw new IllegalArgumentException(
"unsupported component: \n " +
ClassNames.getSuperclassReport( jc.getClass() ));
}
private static void additionalButtonSetup( AbstractButton button , Action a )
{
Icon roll = getRollover( a );
if( roll != null )
button.setRolloverIcon( roll );
}
public static Icon getRollover( Action a )
{ return (Icon) a.getValue( ROLLOVER_ICON );
}
}
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]] On Behalf Of [EMAIL PROTECTED]
> Sent: 25 March 2003 12:06
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Limitations of Action - Solution 1
>
>
>
>
>
>
> 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
>
