something is removing my whitespace

Sorry for lack of a code example but I think in this case I cna just
explain the issue and a lightbulb might go off with someone as to what
is happening.

I needed to allow my users to construct a nicely formatted piece of text
that I'd render as HTML without having them to learn HTML. Didn't need a
fancy GUI so I'm using redcloth/textile, the user enters h2. foo and
gets a heading2. Works great bar one major problemo / glitch!

When the form is submitted (formtastic) the description field is set
fine, text type. In order for the piece to start with a heading 2, the
user would have to type.

<blank_line>
h2. foo
<blank_line>

It works if I keep trying but often the first blank line is getting
stripped out (result being that it renders as "h2. foo" rather than a
proper HTML heading2 tag.

What's doing this? How to fix?

Any ideas - something is killing the CR or newline characters ?

Try rebuilding the form without formtastic or rebuild the form with a fresh copy of rails. Are you using any javascript on the textarea ?

Luke

No JS on the text areas, maybe it's something to do with the DB type?
Could it be formtastic doing this ?

hmm. thanks will rebuid the form without formtastic and test if it comes
to that - any other ideas, something in the update action of the
controller striping stuff out? It's a standard scaffolded controller
action - grrr.

No JS on the text areas, maybe it's something to do with the DB type?
Could it be formtastic doing this ?

mysql will trim trailing whitespace from varchar columns, although it
sounds like you are talking about leading whitespace.

Fred

mysql will trim trailing whitespace from varchar columns, although it
sounds like you are talking about leading whitespace.

Interesting, thanks, hmmm, well it is mysql, yes and yes it's leading
whitespace but the column type here (in my migration) is either "text"
or "string", can't remember but I think I went for "text" as this is
potentially a longer piece of writing.

It does smack of the DB doing something "behind the scenes" actually -
any tips to stop it doing any trimming of whitespace - I could test
that?

Actually it could be new line of carriage returns that are being
trimmed.

The more I think about this the more Fred's suggestion makes sense - I
suspect that mysql is somehow monkeying with the text on save, trimming
it at the top or removing CR characters or the like.

Is this normal? How can you control this behaviour, seems wierd that it
does this by default if this is indeed what's happening.

bingo bob wrote:

The more I think about this the more Fred's suggestion makes sense - I
suspect that mysql is somehow monkeying with the text on save, trimming
it at the top or removing CR characters or the like.

Is this normal? How can you control this behaviour, seems wierd that it
does this by default if this is indeed what's happening.

If you're trying to see blank lines and extra spaces on your web page,
and the output is not between <pre> tags, the behavior of HTML will
collapse extra white space. Ex.:

A Line Like This

will render as:

A Line Like This

and this:

hello

world

will render as:

hello world

But he's running this through RedCloth, and whitespace is significant there, and renders into HTML. He's seeing

Walter Davis wrote:

But he's running this through RedCloth, and whitespace is significant
there, and renders into HTML. He's seeing

...

Walter

Ahhh.. My bad :slight_smile: Missed the RedCloth reference. Resume party :wink:

Just to confirm, Walter's interpretation of what I'm seeing is
absolutely right. The lack of the newline at the start is significant as
it means the first heading doesn't get rendered as HTML it just gets put
out as "h2. foo", which is, well, rubbish - my investigations continue.
Something funky is occuring here.

Anyone have any further insight on this one - it's still not solved for
me, should I look perhaps at altering my database configuration or
perhaps it's something in the migration that sets up these attributes?
No clue but something means I cannot save a text type attribute to the
db that begins with a newline character - daft!

Anyone have any further insight on this one - it's still not solved for
me, should I look perhaps at altering my database configuration or
perhaps it's something in the migration that sets up these attributes?
No clue but something means I cannot save a text type attribute to the
db that begins with a newline character - daft!

I don't remember the history of this that well, but you need to break the process up into discrete steps.

- Connect to your database directly (not via rails/ruby!) and using plain SQL insert data with whitespace. Check it with SQL and see if the white space is still there. If it is, then your database is okay. If it isn't, your database is doing something. Figure out why.

- Setup a simple web form that simply spits the output back to the page and logs it to the development log. Do not touch the database at all. If that works, then Rails (sans AR) is working right. If it doesn't, for kicks, try a different browser. Maybe you have some funky plugin that is stripping white text for you.

- Now, use rails console to run the *same* query you ran earlier via Model.connection.execute('sql here') and again to get it out. Does that work? If not, then the problem is in your ruby<->db adapter most likely. If it does work...

- Insert data into your model using normal AR methods. If this doesn't work, then you've got something in that model that is doing it.

Basically... break it all apart and see what works and what doesn't... you've got way too many steps b/n "web form" and "database" to know where the problem is without doing this...

-philip

Thanks Philip - sounds to me that you have some experience in isolating
and eradicating gremlins of this kind. I'll try this approach and report
back.

In the meantime if it's helpful to anyone I'm wroking around the problem
with my beta users by simply asking them to use <h2>foo</h2>, which
works just fine naturally, textile (redcloth gem) just ignores it and
obviously it is correctly rendered as a heading 2, kind of defeats the
object though!