Swing 的 JList MVC 实现有什么问题吗? [英] Is there something wrong with Swing's MVC implementation for JList?

问题描述

前段时间我问过这个问题.所有解决方案都是变通方法.

Some time ago I asked this question. All solutions are workarounds.

现在不可能了.我觉得这里有问题，但我无法判断是Swing的MVC模型在概念上有问题，还是我的想法在概念上有问题.

Now this can't be. I feel that something is wrong here, but I can't tell if it is Swing's MVC model that is conceptually wrong, or if it is my thinking that is conceptually wrong.

问题又来了.我正在使用 JList 来实现文档页面的缩略图列表.如果用户从列表中选择另一个缩略图，则加载该页面.为此，我将 listselectionlistener 添加到 jlist ，它在选择更改时，它加载该页面.但是用户也可以使用另一个控件更改页面.自然地，我希望通过在此处选择该页面来将其反映在缩略图列表中.所以我setSelectedIndex() 来更新JList.不幸的是，这会产生不需要的效果，即引发 ListSelectionEvent 导致侦听器重新加载页面.

Here is the problem again. I am using a JList to implement a list of thumbnails for the pages of a document. If the user selects another thumbnail from the list, that page is loaded. To do this I added a ListSelectionListener to the JList, which when the selection changes, it loads that page. But the user can also change the page using another control. Naturally, I want this to be reflected in the thumbnail list by having that page selected here. So I setSelectedIndex() to update the JList. Unfortunately this has the unwanted effect of raising a ListSelectionEvent which causes the listener to reload the page.

现在有什么问题吗?我只是从其他地方更改了模型，所以很自然地我希望视图自行更新，但我不希望它触发事件.Swing 没有实现 MVC 对吗?还是我在这里遗漏了一点?

Now what is wrong here? I just changed the model from somewhere else, so naturally I want the view to update itself, but I don't want it to trigger events. Is Swing not implementing MVC right? Or am I missing a point here?

推荐答案

这是我们很多 Swing 程序员必须面对的问题:多个控件修改相同的数据，然后更新反映在每个控件中.在某些时候，某些东西必须对将应用于模型的更新拥有最终否决权:无论是什么东西，都需要能够处理多个(可能是冗余的甚至是矛盾的)更新并决定如何处理它们.这可能发生在模型层，但理想情况下应该是控制器执行此操作 - 毕竟，这部分最有可能是业务逻辑所在的位置.

This is an issue that a lot of us Swing programmers have to face: multiple controls modifying the same data, with the update then reflected in each control. At some point, something has to have the ultimate veto on what updates will be applied to the model: whatever that something is needs to be able to handle multiple (potentially redundant or even contradictory) updates and decide what to do with them. This could happen in the model layer, but ideally it should be the controller that does this - this piece, after all, is most likely where the business logic resides.

在这方面，Swing 的问题是 MVC 的控制器部分通常在视图组件和模型之间有些分割，因此很难集中该逻辑.在某种程度上，Action 接口通过将逻辑放在一个地方并允许它由不同的组件共享来纠正 actionPerformed() 事件的这一点，但这对其他类型的事件没有帮助，或者当有多个不同类别的事件需要协调时.

The problem with Swing, in this regard, is that the controller piece of MVC is often split somewhat between the view component and the model so it can be difficult to have that logic centralised. To some extent the Action interface rectifies this for actionPerformed() events by putting the logic in one place and allowing it to be shared by different components, but this doesn't help for the other types of event, or when there are multiple different classes of event that need to be coordinated.

那么，答案是遵循 Swing 中暗示但未明确说明的模式:仅当状态实际发生变化时才执行请求的更新，否则什么都不做.这方面的一个例子是 JList 本身:如果您尝试将 JList 的选定索引设置为已选择的相同索引什么都不会发生.不会触发任何事件，不会发生更新:更新请求被有效地忽略.这是一件好事.这意味着你可以，例如，在你的 JList 上有一个监听器来响应新选择的项目，然后反过来要求相同的 JList 重新选择相同的item 并且您不会陷入病态的递归循环中.如果应用程序中的所有模型控制器都这样做，那么在整个地方触发多个重复事件就没有问题 - 每个组件只会在需要时更新自身(并随后触发事件)，并且如果它确实更新然后它可以触发它想要的所有更新事件，但只有那些尚未收到消息的组件才会对此做任何事情.

The answer, then, is to follow a pattern that's hinted at in Swing but not made explicit: only perform the requested update if the state will actually change, otherwise do nothing. An example of this is in the JList itself: if you attempt to set the selected index of a JList to the same index that's already selected nothing will happen. No events will be fired, no updates will occur: the update request is effectively ignored. This is a good thing. This means that you can, for example, have a listener on your JList that will respond to a newly selected item, and then in turn ask the same JList to reselect that same item and you won't get stuck in a pathologically recursive loop. If all the model-controllers in an application do this then there's no problem with multiple, repeated events firing off all over the place - each component will only update itself (and subsequently fire off events) if it needs to, and if it does update then it can fire off all the update events it wants, but only those components that haven't already got the message will do anything about it.

这篇关于Swing 的 JList MVC 实现有什么问题吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！