Ruby 如何将 Slim 文件转换回 erb

johnnyhg · August 27, 2013 · Last by qx replied at May 04, 2016 · 7779 hits
Topic has been selected as the excellent topic by the admin.

实在看不习惯 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

You need to Sign in before reply, if you don't have an account, please Sign up first.