GWT CellTable中的键盘导航 [英] Keyboard navigation in GWT CellTable

查看:119
本文介绍了GWT CellTable中的键盘导航的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我们正在尝试使用 CellTable 创建可编辑网格。使用
的情况对于习惯了
10键输入电子表格的会计人员而言是相当高的数据输入量。我们正试图尽可能地复制电子表格 -
风格的键盘导航。


  1. 有什么办法可以避免必须按Enter才能进入编辑模式
    用于 TextInputCell ?我已经尝试覆盖
    TextInputCell.onBrowserEvent(),当焦点$ b $调用 onEnterKeyDown() b有没有办法使用 Tab Shift / kbd> - Tab
    列之间导航,而不是左箭头和右箭头? CellTable似乎是
    硬编码使用左右箭头并且难以扩展。


解决方案

经过相当多的工作尝试,我们确定CellTable是没有足够的可扩展性去做我们所需要的。我们最终扩展了GWT的Grid类,从CellTable中获取设计线索,使其能够满足我们的需求。

在我们的用例中,80%的页面浏览量显示的行数少于10行,我们永远不会超过600行10列(小于0.5%有超过500行)。我们使用了延迟加载模式,而不是完整的轻量级模式。当网格最初被填充时,仅用于显示的小部件用于显示来自基础值对象的数据。 FocusHandler附加到每个仅显示的小部件。当用户点击或标签到显示窗口小部件时,FocusHander用可编辑的小部件替换该行的显示小部件。



仅限显示小部件轻量级的小部件,如TextBox和CheckBox,所以渲染时间是可以接受的。在不到2秒内渲染100行×5列。 SuggestBoxes,DateBoxes和其他Composites仅限于用作可编辑小部件。



优点


  1. 灵活使用任何
    标准小部件

  2. 可扩展性 - 我们不受

    中实现的实现选择的限制CellTable

  3. 易于开发 - 以
    为原型,少于3天的开发时间

  4. 执行足够好以适应我们的
    需求

  5. 标签按照您的期望即可使用

缺点




  • 不像CellTable那样可扩展。这
    实现不会呈现
    数千行

  • 我们必须自行维护


We are attempting to create an editable grid using CellTable. The use case is fairly high volume data entry for accountants who are used to 10-key entry into spreadsheets. We are trying to replicate spreadsheet- style keyboard navigation as closely as possible.

  1. Is there any way to avoid having to hit Enter to get into edit mode for a TextInputCell? I have tried overriding TextInputCell.onBrowserEvent() to call onEnterKeyDown() when a focus event is received, but that didn't work.

  2. Is there any way to use Tab and Shift-Tab to navigate between columns instead of LEFT-ARROW and RIGHT-ARROW? CellTable seems to be hardcoded to use left and right arrows and difficult to extend.

解决方案

After quite a bit of work trying, we determined that CellTable was not extensible enough to do what we needed. We ended up extending GWT's Grid class, taking design cues from CellTable to make it perform well enough for our needs.

In our use case, 80% of page views will display less than 10 rows and we will never have more than 600 rows by 10 columns (< 0.5% of cases have more than 500 rows). Instead of a full-fledged flyweight pattern, we used a lazy loading pattern. When the Grid is initially populated, display-only widgets are used to show the data from the underlying value objects. A FocusHandler is attached to each display-only widget. When a user clicks or tabs into a display widget, the FocusHander swaps out the display-only widgets for that row with the editable widgets.

Display-only widgets are restricted to lightweight widgets such as TextBox and CheckBox, so rendering time is acceptable. 100 rows x 5 columns render in less than 2 seconds. SuggestBoxes, DateBoxes, and other Composites are limited to only being used as editable widgets.

Advantages

  1. Flexibility to use any of the standard widgets
  2. Extensibility - we're not limited by the implementation choices made in CellTable
  3. Ease of development - prototyped in less than 3 days of development
  4. Performs well enough to fit our needs
  5. Tabs work out of the box as you would expect

Disadvantages

  • Not as scalable as CellTable. This implementation is not going to render thousands of rows
  • We have to maintain it ourselves

这篇关于GWT CellTable中的键盘导航的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆