使用注册表管理 Swing 操作
通常,当我创建 Swing(或任何 UI)应用程序时,我会在菜单项和按钮上显示各种操作。我通常创建一个操作注册表并将操作存储在其中,然后当发生某些事情时,我根据应用程序的状态禁用/启用注册表中的操作。 我不会称自己为狂热的 Swing 开发人员,尽管我非常了解它的方法,但这是管理 Actions 的一种非常典型的模式吗?或者有更标准的方法吗?
谢谢,
杰夫
Typically when I'm creating a Swing (or any UI) application, I have various Actions that appear on menu items and buttons. I usually create an action registry and store the actions in there and then when certain things occur, I disable/enable actions in the registry based on the state of the application.
I wouldn't call myself an avid Swing developer, although I know my way around it well enough, but is this a pretty typical pattern for managing Actions? Or is there a more standard way of doing it?
thanks,
Jeff
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
杰夫,你的方法似乎是个好方法。我也做同样的事情。我调用注册表 ActionHandler,它看起来像这样:
现在要禁用 ZoomAction,我使用
Jeff, your approach seems like a good approach. I do the same thing. I call the registry ActionHandler and it looks like this:
Now to disable, say ZoomAction, I use
根据我的经验,处理 Swing GUI 上执行的操作的“最”标准方法是创建
ActionListener
并让它们处理ActionEvent
直接用于它们注册的组件。它是一个简单的设计,并且遵循 Swing 框架中其他类型 GUI 事件的约定(MouseListener
/MouseEvent
、TableModelListener
/TableModelEvent
等)。您描述的
Action
框架是一个功能强大的工具,允许在许多输入方法之间共享操作(即让工具栏按钮和菜单项执行相同的操作,因此共享相同的Object
用于处理两者触发的事件等)。这种抽象非常酷,但 Sun 警告说,它比简单的观察者更重一些。来自Action
JavaDoc:< /a>From my experience, the 'most' standard way of handling actions performed on a Swing GUI is to create
ActionListener
s and have them handleActionEvent
s directly for the components with which they are registered. It is a simple design and it follows convention with other sorts of GUI events in the Swing framework (MouseListener
/MouseEvent
,TableModelListener
/TableModelEvent
, etc).The
Action
framework you describe is a powerful tool to allow for sharing of actions between many input methods (ie, having a toolbar button and menu item perform the same action, and therefore sharing the sameObject
for handling the events triggered by both, etc.). This abstraction is pretty cool, but Sun cautions that it is a bit heavier-weighted than the simple Observers. From theAction
JavaDoc:我通常采用以下方法:
Action
注册到包含Component
的操作映射。String
常量,允许应用程序引导代码从所需的Component
中“拉出”Action
(例如,将其添加到JToolBar
、JMenuBar
等)。Component
中定义私有updateActionStates()
方法,当用户执行某些操作(例如从JTable
中选择 N 行)时调用该方法。此方法根据组件
的当前状态启用/禁用所有定制操作。示例:
顺便说一句,与
ActionListener
相比,我通常更喜欢Action
来公开构成我的Component
一部分的Action
的 API。对于仅存在于Component
中的操作(例如对话框的“清除”按钮),我通常使用ActionListener
。然而,我不同意 akf 认为 ActionListener 是最标准方法的观点 - 这对于较小的 GUI 可能是正确的,但对于更复杂的 Swing 应用程序则不然。I usually take the following approach:
Action
with the containingComponent
's action map.String
constant allowing the application bootstrap code to "pull out" theAction
from theComponent
in required (e.g. to add it to aJToolBar
,JMenuBar
, etc.).updateActionStates()
method within theComponent
, which is called when the user performs some action (e.g. selects N rows from aJTable
). This method enables / disables all bespoke actions based on the current state of theComponent
.Example:
Incidentally, I typically prefer
Action
s toActionListener
s for exposingAction
s that form part of myComponent
's API. For Actions that merely exist within theComponent
(e.g. a dialog's "Clear" button) I typically useActionListener
. However, I disagree with akf aboutActionListener
being the most standard approach - This may be true of smaller GUIs but not more complex Swing applications.我在操作上使用注释,然后反思性地找到它们。
更整洁一些,并且新操作会自动管理。
I'm using annotations on actions, then finding them reflectively.
A bit tidier, and new actions get managed automatically.