Ruby 如何将 Slim 文件转换回 erb

johnnyhg · 2013年08月27日 · 最后由 qx 回复于 2016年05月04日 · 7794 次阅读
本帖已被管理员设置为精华贴

实在看不习惯 slim 的语法了,有没有现成的工具将 slim 转换回 erb 文件

这个。。。我还在认真考虑是否转一下 slim 呢。。

另外能否补充点理由,为啥用不惯 slim 呢?

同样不爽 slim。

Slim 本身带了转回 Erb 的功能

slimrb -e /path/to/template.slim > /path/to/template.erb

但这个转出来的 erb 基本也是不能读的。所以还是手工转吧。

#1 楼 @ericguo

Slim 在缩进超过 3 层之后可读性开始变差了,和 Haml,Sass 一个毛病。如果你要维持可读性的话,那么就需要把 HTML 控制在 3 层缩进以内,这对于开发者来说是个不小的负担,特别是你的样式需要多套几层的wrapperinner之类的 Div 实现的时候。个人觉得有这功夫还不如去重构其他部分的代码。

类似的有没有 HAML 转 erb 的?

层级太多了为什么不拆开来呢,不要死嗑一个文件里嘛

我现在已经离不开 slim,上面大家遇到的所有问题,我刚开始使用的时候也是无法忍受,甚至争吵过。但后来,我发现,这货太节省我的时间了。它可能,不,肯定是对没使用过的人来说,很难维护;但是站在节约程序员时间这个角度来说,它真是太好了。想想看,你直接比其他平台的程序员,节约了至少 10% 的时间,你是不是开始偷着乐了,如果是 JS 模板,推荐 skim,它继承了 slim 的语法。这样前端和后端模板语法就都统一了。

我也不是很喜欢 Slim/Haml 这种缩进方式的。相比较于 Python 和 Coffee 来说,还是‘代码’,通过提炼重构可以控制单个方法的长度,但是页面模板就不是那么好弄了,你不可能每个模板都控制在几行以内,单个模板十几行,二十几那算是好的,这个情况下 Slim/Haml 这种读起来非常痛苦。

何止 10%,至少时间节省了 30% 以上。

Emmet 写 ERB 比 Slim/Haml 快得多。

如果看中渲染速度的话也应该选 Erubis...

#9 楼 @Saito 原来没听说过 Emmet, 和 zen_coding 一样哦

#10 楼 @jonny 就是 zen coding, 换名字了而已..

缩进改成 1 个空格或半个空格吧。

#5 楼 @xjz19901211 #6 楼 @outman

我在 3 个项目中都用过 Slim,项目的开发时间都超过一年。后来觉得这 Slim 真不能忍,像 @kenshin54 说的一个页面模版真的很难控制。举个 ruby-china 的例子,这里的 Top navbar 层级都到 5 层以上了,难道你会把一个就那么几行的 navbar 代码硬拆成几个文件?

我觉得对于页面逻辑这种,变化快变化多的部分,更新维护的次数远远超出你第一次写的次数。你第一次写的时候是爽了,但成本主要在后面维护部分,层级多了可读性极差。

@Saito 提到的快速编写 HTML Template,目前最好的还是 Emmet 这种 Generator 方案,第一次编写快速,后面好维护。

@Saito 为什么 Erubis 到现在都不更新了呢?是因为现在 erb 已经和 Erubis 速度相当了吗?

如何从 haml 换回 erb? 试了几个方案,发现不支持插入的 ruby 语句。 跟前端配合,还是 erb 方便些。

我已从 HAML 换回 ERB 了,还是普通的 ERB 看着比较舒服。

SASS 也换成了 SCSS .

HAML/Slim hater + 1...

其实我看到强制缩进就绕道了…

#13 楼 @_kaichen navbar 不就一个模块么,为啥不是独立一个文件……各种 widget 独立一个文件最多也就缩进个 5 层吧,反正我配合 angularjs 用得挺爽的

原来不止我一个人不喜欢 slim。还是 ERB 好,生成了什么一目了然。我也是用 SCSS 的语法,简单的文件 SASS 看起来清爽,但层级多了以后很乱。

@_kaichen 其实我们公司以及我自己的项目都使用 slim 了,其中公司的项目已经使用 2 年了吧,也算比较大的项目,要比 ruby-china 大,毕竟都是企业应用。我的感受是,这要看团队人员的接受程度,如果大家都觉得 slim 不靠谱,硬性引入,毕竟增加学习成本不说,还会引发不悦的情绪,因为我极力反对在团队项目里面使用各种不同的模板,比如你使用 erb,他使用 haml,还有一些人还使用 slim,这就比较混乱了。至于你说的层级的问题,说实话,我第一次接触 slim 就比较反对它的,觉得它不好(容易)看,还不容易维护,但是后来就慢慢习惯了,被它带来的优势吸引了,比如你不用再折腾各种 tag 了,添加输出也各种方便,在模板里面插入代码逻辑也各种方便,直到最后,我发现多层嵌套也不成问题了(这些 slim 就比 haml 做的彻底,估计这也是我当初不适应的地方,太 TM 彻底了不给你任何过度,你都怀疑是不是叛离了 HTML 的精神。如果是 python 党估计是各种欢乐),然后配合 partial template,感觉,即使多层也没有当初那么难受了。即使 使用 erb,难道多层就容易识别么?那么多的 html tag,还有各种输出控制符:<%= %>,代码控制标签等等。所以,我觉得,这个最终和团队的接受程度关系很大,毕竟习惯使然。

#14 楼 @wppurking 因为 Erubis 的作者转去做 Python 了

我用 jade 久了,真的很难换回 html 了,各种爽,唯一不爽的是,从网上 copy html,要先转一下~

表示也不喜欢 slim,设计出的是静态 html,转来转去的感觉绕路了,比直接用 erb 还浪费时间,除非设计直接出 slim

嵌套多不用怕,编辑器打开缩进提示线就可以了...

HAML/Slim hater +1024

编译出来的 HTML 不可控,发现问题不好调试,本身没有节约多少代码量,没有结束符造成大页面调试难度增加。

#17 楼 @hooopo +1 不愧是我的好基友 PS:强制缩近就是耍流氓!

真的感觉没必要转,如果觉得缩进会造成眼花,装个代码自动折腾的插件就好了。 如果觉得还不给力,请加大你的显示器。

我很想知道怎么转

看来还是用原生 erb 吧 不踏坑了。

缩进不是问题,编译不是问题,问题就是有人不喜欢这种语法而已,就跟我不喜欢 spec 语法一样。

不然看看这个文件 https://github.com/ruby-china/ruby-china/blob/master/spec/javascripts/topics_spec.coffee

是不是缩进层次很深,很难看?

但是我觉得用 coffee 是个正确的选择,因为这些代码写成 javascript 会更长更难看。

@jasl 用 vim 或者 emacs 的同学, 应该对于强制缩进应该不会有什么反感吧。 缩进可以完全当不存在,行云流水。

#32 楼 @zealinux 其实用 ide 的话,缩近的效果比 vim 或者 emacs 做的还好的

但是强制缩近和代码可读性强并不是充要条件 另外也是...不喜欢 slim 的语法,现在还对 simple_form 这些过度包装 view 的东西表示反感了...

我不觉得 silm 有什么节省时间的,反正我想的时间多于直接 code 的时间,一天 500 行代码的程序员就算高产了。 再说 rubymine 的代码提示难道不好用么?

#31 楼 @Rei 缩进不是问题,编译不是问题,问题就是有人不喜欢这种语法而已 + 1024

大家已经偏题了,楼主问的是有没有转换回来的工具。。。

我倒是觉得 html 要是一开始就是这种缩近式的可能比较好吧。 不统一确实有一种“蛋疼”的感觉 >_<。

以前一直很讨厌缩进式的东西,但是代码写多了你会发现你需要花大量的时间去找括号 tag 等,sumline 设置一个 tab 是 2 个 space,妥妥的

HAML hater + 1

对强制缩进表示非常反感,就算是写 coffee 我都是有点抗拒的,正如以前对 python 的态度一样,就是受不了强制缩进。

缩进的问题没这么严重吧,难道写 erb 会不缩进?

我也不喜欢用.....可能是刚用吧 感觉好别扭.........

Slim 感觉就是个大坑,项目做到一半,改回 erb,写了个脚本专门转 slim,有需要的 fork,https://github.com/qx/slimcleaner @johnnyhg

需要 登录 后方可回复, 如果你还没有账号请 注册新账号