Is textilize bad?

Rails
1

Hi,

I’m reading “Beginning Ruby on Rails E-Commerce”.
On page 398, it says:

Caution: Although textilize is a cool quick-and-dirty helper, as a rule
of thumb, it should never be used in a production setting.

What’s wrong with textilize?
What’s a better alternative?

Thanks.

Sam

2

I don’t know, since I don’t have that book. I am guessing its something
to
do with security. I have been using it in production since like ages and
its
pretty helpful rather ‘never used’.

3

Problems with textilize? Thats a new one for me.

4

I’m reading “Beginning Ruby on Rails E-Commerce”.
On page 398, it says:

Caution: Although textilize is a cool quick-and-dirty helper, as a rule
of thumb, it should never be used in a production setting.

What’s wrong with textilize?
What’s a better alternative?

I haven’t used it myself, but textile is redcloth… and I seem to
remember a thread awhile back (not even sure it was this group) about
redcloth vs bluecloth and speed issues… So maybe textile is kind of
slow?

But again, I haven’t used it, so could be completely wrong. Search
google
for textile/redcloth/bluecloth for more…

5

Philip H. wrote:

I haven’t used it myself, but textile is redcloth… and I seem to
remember a thread awhile back (not even sure it was this group) about
redcloth vs bluecloth and speed issues… So maybe textile is kind of
slow?

But again, I haven’t used it, so could be completely wrong. Search google
for textile/redcloth/bluecloth for more…

I believe in this context the authors were saying that it was bad to use
on text on each render. You are going to want to cache your pages
and/or textilize the text as it goes into the db so you do not get a
large speed hit on each page render.

Matthew M.
blog.mattmargolis.net

6

Philip H. wrote:

I haven’t used it myself, but textile is redcloth… and I seem to
remember a thread awhile back (not even sure it was this group) about
redcloth vs bluecloth and speed issues… So maybe textile is kind of
slow?

That rings a bell. One solution to the speed problem is to cache the
textilized text int he database along with the original source. That way
you only do the translation once after an edit, and the textilized
version can be pulled from he DB when needed. This is a tactic I’d use
for any formatting language used on a high-traffic site.

Dougal.

7

Douglas S. wrote:

That rings a bell. One solution to the speed problem is to cache the
textilized text int he database along with the original source. That way
you only do the translation once after an edit, and the textilized
version can be pulled from he DB when needed. This is a tactic I’d use
for any formatting language used on a high-traffic site.

I’d say that fragment caching is probably a simpler performance-focused
fix, rather than creating a more convoluted model.

The big problem with textilize (and any user-generated HTML) is that
you’re leaving your app open for cross-site-scripting attacks if you
don’t sanitize the HTML it produces, both tags and attributes.

My schtick about safe HTML is here:

http://www.kookdujour.com/blog/details/11

And I wrote a pretty flexible helper method to ensure safe user-created
HTML.

-DJCP

8

Matthew M. wrote:

I believe in this context the authors were saying that it was bad to use
on text on each render. You are going to want to cache your pages
and/or textilize the text as it goes into the db so you do not get a
large speed hit on each page render.

Bingo! The quote in the original post was part of a section called
“Rendering Speed”.

//jarkko

–
Jarkko L.

http://www.railsecommerce.com
http://odesign.fi