单元格小部件中的 GWT SelectionModel - 通过键 setSelected？
有没有办法用GWT的选择模型按键选择项目？ setSelected 似乎只获取一个可以从中派生 Key 的对象，但使用该函数意味着我必须构造一种假对象。如果我的 KeyProvider 发生变化，我的代码的那部分可能会在我不知情的情况下崩溃，所以我想以某种方式直接构造一个密钥。
Is there any way to select items by key with GWT's selection model? setSelected only seems to take an object from which it can derive a Key, but using that function means I have to construct a sort of fake object. If my KeyProvider ever changes, that part of my code could break without my knowledge, so I'd like to just construct a key directly somehow.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
“我有一个显示实体列表的单元格表。当用户创建新实体时，我想刷新列表（其中将包含新实体）并自动选择新实体。”
我的应用程序中也有这种行为。我操纵 ListDataProvider。我找到感兴趣的一个或多个项目，将它们移动到列表顶部，调用选择模型将它们设置为选定状态，然后刷新附加的数据显示。当我想为用户预先选择默认选项（通常基于生成选项列表的项目）并将它们移动到列表顶部时，我对选项列表表使用相同的方法。我花了很多时间查看选择模型 api，但没有任何键值。我怀疑 GWT 设计者认为没有必要，因为您可以访问 ListDataProvider。在那里找到感兴趣的项目，然后对这些特定对象调用选择模型 select 方法。我可以理解他们的观点——复制 ListDataProvider 和 SelectionModel 中的功能会模糊这两个类之间的区别，并且可能会限制 SelectionModel 构造在不使用键的其他（未来）数据结构中的可重用性。
"I have a celltable that shows a list of entities. When the user creates a new entity, I want to refresh the list (which will have the new entity) and automatically select the new entity."
I have this behaviour in my app as well. I manipulate the ListDataProvider. I find the item or items of interest, move them to the top of the list, call the selection model to set them to selected, and refresh the attached data displays. I use the same approach for picklist tables I use when I want to pre-select the default choices for the user (usually based on the item that is spawning the picklist) and move them to the top of the list. I spent a lot of time looking through the selection model api and there is nothing for keys. I suspect that the GWT designers figured it wasn't necessary, since you have access to the ListDataProvider. Find the items of interest there and then call the selection model select method on those specific objects. I can see their point -- replicating the functionality in ListDataProvider and SelectionModel would blur the distinction between the two classes, and perhaps limit the reusability of the SelectionModel construction in other (future) data structures that don't use keys.