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!