Changesets can be listed by changeset number.
The Git repository is here.
- Revision:
- 373
- Log:
Initial import of Radiant 0.9.1, which is now packaged as a gem. This is an
import of the tagged 0.9.1 source checked out from GitHub, which isn't quite
the same as the gem distribution - but it doesn't seem to be available in an
archived form and the installed gem already has modifications, so this is
the closest I can get.
- Author:
- rool
- Date:
- Mon Mar 21 13:40:05 +0000 2011
- Size:
- 5507 Bytes
1 | # Frequently Asked Questions |
2 | |
3 | * Table of contents |
4 | {:toc} |
5 | |
6 | ## Haml |
7 | |
8 | ### Why is my markup indented properly in development mode, but not in production? |
9 | {#q-indentation-in-production} |
10 | |
11 | To improve performance, Haml defaults to {file:HAML_REFERENCE.md#ugly-option "ugly" mode} in Rails |
12 | apps running in production. |
13 | |
14 | |
15 | ### How do I put a punctuation mark after an element, like "`I like <strong>cake</strong>!`"? |
16 | {#q-punctuation} |
17 | |
18 | Expressing the structure of a document |
19 | and expressing inline formatting are two very different problems. |
20 | Haml is mostly designed for structure, |
21 | so the best way to deal with formatting is to leave it to other languages |
22 | that are designed for it. |
23 | You could use Textile: |
24 | |
25 | %p |
26 | :textile |
27 | I like *cake*! |
28 | |
29 | or Markdown: |
30 | |
31 | %p |
32 | :markdown |
33 | I like **cake**! |
34 | |
35 | or plain old XHTML: |
36 | |
37 | %p I like <strong>cake</strong>! |
38 | |
39 | If you're inserting something that's generated by a helper, like a link, |
40 | then it's even easier: |
41 | |
42 | %p== I like #{link_to 'chocolate', 'http://franschocolates.com'}! |
43 | |
44 | ### How do I stop Haml from indenting the contents of my `pre` and `textarea` tags? |
45 | {#q-preserve} |
46 | |
47 | Because Haml automatically indents the HTML source code, |
48 | the contents of whitespace-sensitive tags like `pre` and `textarea` |
49 | can get screwed up. |
50 | The solution is to replace the newlines inside these tags |
51 | with HTML newline entities (`
`), |
52 | which Haml does using the {Haml::Helpers#preserve} and {Haml::Helpers#find_and_preserve} helpers. |
53 | |
54 | Normally, Haml will do this for you automatically |
55 | when you're using a tag that needs it |
56 | (this can be customized using the {file:HAML_REFERENCE.md#preserve-option `:preserve`} option. |
57 | For example, |
58 | |
59 | %p |
60 | %textarea= "Foo\nBar" |
61 | |
62 | will be compiled to |
63 | |
64 | <p> |
65 | <textarea>Foo
Bar</textarea> |
66 | </p> |
67 | |
68 | However, if a helper is generating the tag, |
69 | Haml can't detect that and so you'll have to call {Haml::Helpers#find_and_preserve} yourself. |
70 | You can also use `~`, which is the same as `=` |
71 | except that it automatically runs `find_and_preserve` on its input. |
72 | For example: |
73 | |
74 | %p= find_and_preserve "<textarea>Foo\nBar</textarea>" |
75 | |
76 | is the same as |
77 | |
78 | %p~ "<textarea>Foo\nBar</textarea>" |
79 | |
80 | and renders |
81 | |
82 | <p><textarea>Foo
Bar</textarea></p> |
83 | |
84 | ### How do I make my long lines of Ruby code look nicer in my Haml document? |
85 | {#q-multiline} |
86 | |
87 | Put them in a helper or your model. |
88 | |
89 | Haml purposefully makes it annoying to put lots of Ruby code into your templates, |
90 | because lots of code doesn't belong in the view. |
91 | If you take that huge `link_to_remote` call |
92 | and move it to a `update_sidebar_link` helper, |
93 | it'll make your view both easier to read and more semantic. |
94 | |
95 | If you absolutely must put lots of code in your template, |
96 | Haml offers a somewhat awkward multiline-continuation tool. |
97 | Put a `|` (pipe character) at the end of each line you want to be merged into one |
98 | (including the last line!). |
99 | For example: |
100 | |
101 | %p= @this.is(way.too.much). | |
102 | code("and I should"). | |
103 | really_move.it.into( | |
104 | :a => @helper) | |
105 | |
106 | ### `form_for` is printing the form tag twice! |
107 | |
108 | Make sure you're calling it with `-`, not `=`. |
109 | Just like in ERB, you have to do |
110 | |
111 | <% form_for stuff do %> |
112 | ... |
113 | <% end %> |
114 | |
115 | in Haml, you have to do |
116 | |
117 | - form_for stuff do |
118 | ... |
119 | |
120 | ### I have Haml installed. Why is Rails (only looking for `.html.erb` files | rendering Haml files as plain text | rendering Haml files as blank pages)? |
121 | {#q-blank-page} |
122 | |
123 | There are several reasons these things might be happening. |
124 | First of all, make sure `vendor/plugins/haml` really exists |
125 | and has an `init.rb` file in there. |
126 | Then try restarting Mongrel or WEBrick or whatever you might be using. |
127 | |
128 | Finally, if none of these work, |
129 | chances are you've got some localization plugin like Globalize installed. |
130 | Such plugins often don't play nicely with Haml. |
131 | Luckily, there's usually an easy fix. |
132 | For Globalize, just edit `globalize/lib/globalize/rails/action_view.rb` |
133 | and change |
134 | |
135 | @@re_extension = /\.(rjs|rhtml|rxml)$/ |
136 | |
137 | to |
138 | |
139 | @@re_extension = /\.(rjs|rhtml|rxml|erb|builder|haml)$/ |
140 | |
141 | For other plugins, a little searching will probably turn up a way to fix them as well. |
142 | |
143 | ## Sass |
144 | |
145 | ### Can I use a variable from my controller in my Sass file? |
146 | {#q-ruby-code} |
147 | |
148 | No. Sass files aren't views. |
149 | They're compiled once into static CSS files, |
150 | then left along until they're changed and need to be compiled again. |
151 | Not only don't you want to be running a full request cycle |
152 | every time someone requests a stylesheet, |
153 | but it's not a great idea to put much logic in there anyway |
154 | due to how browsers handle them. |
155 | |
156 | If you really need some sort of dynamic CSS, |
157 | you can define your own {Sass::Script::Functions Sass functions} using Ruby |
158 | that can access the database or other configuration. |
159 | *Be aware when doing this that Sass files are by default only compiled once |
160 | and then served statically.* |
161 | |
162 | If you really, really need to compile Sass on each request, |
163 | first make sure you have adequate caching set up. |
164 | Then you can use {Sass::Engine} to render the code, |
165 | using the {file:SASS_REFERENCE.md#custom-option `:custom` option} |
166 | to pass in data that {Sass::Script::Functions::EvaluationContext#options can be accessed} |
167 | from your Sass functions. |
168 | |
169 | ## You still haven't answered my question! |
170 | |
171 | Sorry! Try looking at the Haml or Sass references, |
172 | in the doucmentation for the haml and Sass modules, respectively. |
173 | If you can't find an answer there, |
174 | feel free to ask in `#haml` on irc.freenode.net |
175 | or send an email to the [mailing list](http://groups.google.com/group/haml?hl=en). |