ruby-on-rails – Rails仪表板设计:每个div一个控制器动作

前端之家收集整理的这篇文章主要介绍了ruby-on-rails – Rails仪表板设计:每个div一个控制器动作前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我正在执行一个仪表板作为一个相对的Rails新手(更多的基础设施的家伙).仪表板将包含多个页面,每个页面将包含多个图表/表格等.对于模块化,我希望它尽可能简单地添加新的图表或更改数据的视图.

说一页有5个不同的图表.我可以让控制器执行5次单独的数据查找,将所有相关数据保存在实例变量中,并渲染5个部分,每个部分触及数据的子集.但是,似乎有更多的模块化具有一个“索引”控制器操作,其渲染具有一堆div,而对于每个div,还有另一个控制器操作执行数据查找,并具有部分负责管理该数据视图的关联视图在div内.

所以如果我显示网站的仪表板页面有两个图表,网站/索引将使用网站/ graph1和网站/图表2来查找每个数据,然后_graph1.html.erb和_graph2.html.erb将使用控制器数据填写div“graph1”和“graph2”等

这是否是正确的设计,如果是,最简单的方法是什么?我有一个使用remote_function的近似值:action => “graph1”来填充div,但我并不满足于此.我怀疑我错过了Rails将为我做的更容易的事情.

解决方法

版本1:

我在生产中实际使用的简单方法:iframe

大多数情况下,您实际上并不关心页面是否立即显示,并直接从服务器发送,确实更适合加载交错.

如果您只是将一个iframe src’d放到控制器的show操作中,那么你有一个非常简单的解决方案,不需要直接的跨控制器交互.

优点:

>死容易
>使用现有的展示动作等
>甚至可能更快,这取决于平行与顺序请求和内存负载等的节省

缺点:

>您无法总是轻松地将页面与任何内容一起保存
> iframe将突破主机页面javascript命名空间,因此如果需要,可能需要给他们自己的极简版本;他们也不会影响iframe外的周边页面
>可能会更慢,取决于ping时间等
>潜在的n 1效率错误,如果你在页面上有很多这样的模块

版本2:

做同样的事情使用JS调用来替换一个div与部分,àla:

<div id="placeholder">
<%= update_page {|page| page['placeholder'].replace with some partial call here } %>

与上述相同,除了:

优点:

>不将其锁定到iframe中,从而共享JS上下文等
>允许更好地处理故障案例

缺点:

>需要JS和占位符div;有点复杂

版本3:

调用一大堆部分.然而,一旦你在谈论诸如各个模块具有大量设置逻辑的仪表板的事情,这样做会变得复杂.

通过将这些东西变成“混合”等,有各种各样的方法解决这个问题,但是IMO它们有点笨拙.

ETA:通过mixin来实现的方法是创建一个基本上是实现模块控制器设置功能的库文件,包括那些调用em的东西,并调用em.

然而,这有缺点:

>你必须知道什么顶级控制器的操作会导致包含这些模块的页面(你可能不会很容易,如果这些真的是可以显示出来的整洁的东西,例如用户偏好依赖)
>它并不真正作为一个完整的控制器
>它仍然混合了很多逻辑,你的控股东西需要知道它所持有的东西
>你不能轻易地把它分隔成自己的控制器,因为它需要在一个库类型的文件/ mixin

可以从另一个控制器调用一个控制器中的方法.然而,这是屁股的主要痛苦,也是一个主要的污泥.你应该考虑这样做的唯一时间是如果a)他们在自己的权利中都是独立必要的控制者,并且b)它必须完全在后端运行.

我不得不这样做一次 – 主要是因为重构原因更是一个痛苦 – 我保证你不想去那里除非你必须.

概要

最好的方法IMHO是第一个,如果你有足够的复杂的东西,他们需要重要的设置 – 一个简单的iframe显示模块,传递一个参数来告诉它使用超极简主义的布局(只是CSS JS标头),因为它没有显示为自己的页面

这样就可以让事物完全独立,或多或少地像自己完全正常的控制器一样(除了布局设置),保持正常路线等.

如果您不需要重要的设置,那么只需使用partials,并将所需的任何内容作为局部变量传递.如果你遇到像n 1个效率错误这样的事情,这将开始变得脆弱,尽管…

猜你在找的Ruby相关文章