Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Fixes core tags being escaped by Rails 3+ #32

wants to merge 2 commits into


None yet
3 participants

bernardo commented Dec 8, 2011

The ending of some core tags (ex.: html, form, etc) were not being output with raw, therefore Rails was escaping them. This should fix it, plus it updates the README to explain how to use Dryml in Rails 3.

Note/Pledge to Hobo developers: I am not a Hobo user (my projects need a fair bit of customization and I tend to go with "Rails raw" to start from ground up), but I have been watching you guys work for a long time and willing to be able to use Dryml on its own for a long time. I think Rails views (sum of ERB + helpers + partials) are a crappy mess, you end up with lots of unreadable code that is really hard to reuse and maintain. Dryml is the best and only solution I have seen for this sulkiness so far, and it's been like that for years now: nothing else comes along, and Dryml remains a promise just a few people and the Hobo niche use. Yet people are jumping on the HAML and Formtastic bandwagon, when they are nothing but "gimmicks" that don't solve the architectural problem.

Besides thanking for the nice work, I want to make a pledge: invest in polishing and "marketing" Dryml as the solution it is for Rails views, try to bring users and developers to use it "standalone". You should try talking to Rails core guys. I think it should be bundled in future versions of Rails, just like sass and coffeescript were, being much less needed. You could create a "Rapid Basic" set of Dryml tags to be included in the gem that work in standalone Rails and basically replace (or wrap) Rails helpers.

I am willing to go "early adopter" on standalone Dryml with my production projects, but to be honest it is a great leap in the dark: I am really worried about getting stuck in showstopper bugs or huge performance bottlenecks and being on my own. My firm is a small and underfunded startup and needs to focus on its bottom line, the sane decision would be to stay in "vanilla Rails", but I am so disgusted, after all this years, of having crappy code in my views.


al2o3cr commented Dec 8, 2011

Were you actually able to get DRYML to run without Hobo? I've been working on adding significant testing to DRYML, and found that there were a few spots that still expected Hobo bits to be around.

Also, can you describe a couple examples of the incorrect behavior this patch fixes? I'd like to add them to the suite. Thanks!


bernardo commented Dec 9, 2011

Hi, I run it without Hobo fine (following the instructions I corrected in the README), both with rails 3.0 (hobo 1.3) and rails 3.1 (hobo 1.4, from git). To note, in Rails 3.1 I used bundler's git method (http://gembundler.com/git.html) to use the latest Hobo from master.

I didn't do anything complex and didn't test Dryml for further bugs, I just tested on a new app, added a controller with one action and created a couple of simple tags to see if they would be output. I've never done any Hobo/Dryml work, so I am far from being capable of battle testing Dryml.

The errors I found were that:


Was output by Rails as:


In the Hobo core taglig, the opening of a few tags were output with <%= raw ... %>, but not the closings, which caused Rails to escape them and judge them not "html_safe". All I did was add raw were it was missing in the core.dryml file.

I would suggest adding test cases that searched for proper openning and closing of the tags for as many standard tags as possible. It's a very common mistake/bug and happens even in Rails's helpers quite frequently. You could use a Regexp like:


Another important thing to note is that the README said that layouts would not be used, which I found out to be false (in both Rails 3.0 and 3.1), the contents of the .dryml template were put inside the layout, unless I explicitly disabled layouts or deleted "application.html.erb" from views/layouts.


bryanlarsen commented Dec 12, 2011

Thanks for the patches. I've merged your patches into 1-3-stable -- I don't have a test environment set up for 3.1 yet.

As for missing closing tags, that kind of error is very rare since our input is parsed by an XML parser. It is possible though, because our output isn't parsed by the XML parser. There's only a single place in Rapid where we emit a closing tag using <%=.

al2o3cr added a commit that referenced this pull request Dec 28, 2011


bryanlarsen commented Jul 31, 2012

Merged commit 2e7d08c
Author: Bernardo de Pádua berpasan@gmail.com
Date: Wed Dec 7 22:46:24 2011 -0200

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment