【问题标题】:Editable, expanding input list control for BootstrapBootstrap 的可编辑、扩展输入列表控件
【发布时间】:2013-10-16 15:06:33
【问题描述】:

我们正在寻找某种类型的控件,最好使用 Bootstrap 实现。我们认为这并不罕见,但我们可能错了。

它本质上是一个列表框,但也是:

  • 它就像一个可编辑的组合框,但没有下拉菜单。
  • 类似于标签输入/药盒,但垂直,具有更传统的风格,并且直接可编辑。
  • 类似于扩展网格,但只有一列。
  • 就像一系列垂直附加的文本输入字段框,在类固醇上。
  • 类似于文本区域,但结构合理且可扩展。

最终目标是能够在不离开键盘的情况下快速有效地输入一堆值(电话号码,...),同时允许用户轻松地编辑或删除现有值。 (表单比较大,是 LOB 应用程序的一部分。)

  1. 这个控件有名字吗?
  2. 有人知道提供这种控件的 Bootstrap 插件吗?
  3. 如果没有,那么我们不确定如何进行,您能否给我们一些建议,以便我们能够以直接的方式实现这一点? (例如,从一系列文本输入字段开始是否是个好主意?)

详情:

  1. 本质上是一个列表,
  2. 一开始看起来很像一个简单的文本输入字段,
  3. 当用户按下 ENTER 时,会在下方添加一个新行并将光标移动到该行(列表动态扩展),
  4. 当用户按下TAB时,光标移动到下一个控件,
  5. (可选)当用户按下UPDOWN箭头键时,光标分别跳转到上一个或下一个元素,
  6. 每一行都可以直接编辑(用户可以点击里面其中任何一个并更改任何字符,甚至在中间,因此无需先删除元素),
  7. (可选)最后只能有一个空行,
  8. (可选)如果用户聚焦另一个控件(例如通过按 TAB)或另一个元素(例如通过使用箭头键或通过单击),如果当前元素为空,则将其移除,
  9. (可选)当光标在最后一个字段时,除了按ENTER外,如果最后一个元素不为空,用户可以按一个按钮添加一个新的空元素,
  10. 只有一列(不需要列标题),
  11. (可选)如果最后一个元素为空,则应在最后一个元素中显示内联标签,
  12. 每个元素旁边都有一个按钮,允许用户删除它们,
  13. (可选)当用户在一个元素的末尾按两次DELETE时,焦点元素被删除(必须按两次,以便用户按住按钮删除一堆如果这不是她的意图,of characters 不会意外删除该元素 - 此要求可以通过其他方式制定),
  14. (可选)用户可以撤消删除操作,
  15. (可选)如果元素数量超过某个限制,则会出现滚动条,并且控件的高度固定在该限制,
  16. (NTH) 如果元素数量超过第二个(通常更高)限制,则列表分页。

【问题讨论】:

    标签: javascript twitter-bootstrap user-interface user-input user-experience


    【解决方案1】:

    由于我不知道任何适合您需求的控件,因此我将尝试建议一些实施选项:


    内容可编辑:

    查看contenteditable 属性 - demo here

    这不符合您的所有要求(第 12 点是这里的主要障碍),但它非常好 OOTB,并且(根据MDN)跨浏览器。

    上面提供的演示可能是您自己解决方案的一个很好的起点。


    每行一个输入:

    另一种方法是为每一行使用一个输入。 我提供了simple demo,它在按下回车时添加了“新行”。

    虽然此实现还需要对键盘事件进行一些装箱操作,但此每行一个元素 模型似乎更好地反映了您的业务需求并且非常灵活。 不过,我会担心更大数据集的性能。

    这也可以与contenteditable 方法混合使用(例如,可编辑的<li> 元素列表),但它似乎没有带来任何好处。它甚至会带来一些问题,因为contenteditable 默认不会限制行数;使用常规input,您可以保证一个元素包含一行。

    【讨论】:

    • 谢谢,我从来没想过用这个,这当然很有创意。我想我们可以按照我们想要的方式设置列表项的样式。我有点担心我们会遇到与换行符分隔的文本区域相同的问题,因为我们很难跟踪哪些元素对应于哪些数据记录。例如;假设用户删除了一个元素并编辑了下一个元素。当我们检索数据时,情况是模棱两可的:用户是删除了第一个并编辑了第二个,还是用户编辑了第一个并删除了第二个?无论如何,我会尽快调查。
    • 我假设使用场景之一是您从非空列表开始?我知道你担心的就是这种情况。我一定错过了。在这种情况下,最好将每一行实现为单独的文本输入,让 jQuery 完成其余的工作......或者使用 contenteditable 实现更复杂的编辑控件 - 这可能根本不可能。
    • 确实,该控件将用于所有 CRUD 操作。我想我们做梦了。我确实研究了contenteditable 的使用,我认为在技术上可以通过侦听 DOM 事件来跟踪输入(例如用于数据绑定),但出于某种原因,我不愿意深入研究。也许只有我一个人,但似乎contenteditable 属性确实是为了帮助实现富文本编辑;将它用于其他任何事情都感觉不太对劲,至少现在是这样。例如,即使使用 li 元素,您也必须担心换行符(shift+return)。
    • 查看我编辑的答案。第二种方法更灵活(并且 shift + return 不会破坏任何东西......)。
    • 是的,这正是我们所考虑的,这是一个很好的起点。谢谢!
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2018-07-06
    • 1970-01-01
    • 1970-01-01
    • 2012-11-26
    • 1970-01-01
    • 2014-01-29
    • 1970-01-01
    相关资源
    最近更新 更多