Formatting data drawn from a DB


#1

Question for all:

Right now i have a Table in a mySQL DB that has a row called
Ingredients. When the data is entered into the DB its enter like so
from a text area:

1 1/2 lbs. beef top sirloin, thinly sliced
1/3 cup white sugar
1/3 cup rice wine vinegar
2 tablespoons frozen OJ concentrate
1 teaspoon salt
1 tablespoon soy sauce
1 cup long grain rice
2 cups water
1/4 cup cornstarch
2 teaspoons orange zest
3 tablespoons grated fresh ginger
1 1/2 tablespoons minced garlic
2 cups oil for frying

but when I draw it out of the DB and display it on the page it shows up
like:

1 1/2 lbs. beef top sirloin, thinly sliced 1/3 cup white sugar 1/3 cup
rice wine vinegar 2 tablespoons frozen OJ concentrate 1 teaspoon salt 1
tablespoon soy sauce 1 cup long grain rice 2 cups water 1/4 cup
cornstarch 2 teaspoons orange zest 3 tablespoons grated fresh ginger 1
1/2 tablespoons minced garlic 2 cups oil for frying

Is there a way to parse the text and from the DB and display it so that
it looks like the top version. It shows the \n or add a
at the end
of ach on? Can anyone help me?


#2

On 4/18/06, Nate G. removed_email_address@domain.invalid wrote:

Is there a way to parse the text and from the DB and display it so that
it looks like the top version. It shows the \n or add a
at the end
of ach on? Can anyone help me?

There are several different ways to do this. One very simple way to
handle it would be to let RedCloth do the work for you.

– James


#3

you may also try this technique. You can use an after_find Model
callback to format data.

protected
def after_find
self.phone = “#{self.phone_before_type_cast[0…2]}-#
{self.phone_before_type_cast[3…6]}” if !self.phone.nil? and
self.phone_before_type_cast.length == 7
self.phone = “(#{self.phone_before_type_cast[0…2]}) #
{self.phone_before_type_cast[3…5]}-#{self.phone_before_type_cast
[6…9]}” if !self.phone.nil? and self.phone_before_type_cast.length
== 10
end

This protected method is called for every row returned (so beware of
the performance hit). Afterwards model.phone is formatted nicely for
the view.

Cheers,
Jodi.


#4

I give, uncle! I submit Jean-Francois.

If you can enlighten, how would you ?

J


#5

Hello Jodi,

[6…9]}" if !self.phone.nil? and self.phone_before_type_cast.length
== 10
end

Sorry for my arrogance, but what an ugly code !

Refactory men, where are thou ?

 -- Jean-François.

#6

Possibly a stupid question, but assuming your existing table is named
Recipes is there any reason why you can’t create a new table named
Ingredients as follows:
id (primary key)
recipe_id (points to the entry in your Recipes table)
ingredient (contains e.g. “2 cups water”)

You’d then enter your ingredients one at a time, maybe using some
groovy Ajax stuff to create “space” on a form for each new ingredient
you add, and save each ingredient as a new record in Ingredients with
a pointer back to your Recipes table.

Your individual ingredients are then separate entities, so displaying
them however you want should be a non-issue

Might be a good fit for your specific requirement

Regards

Dave M.


#7

Nate G. wrote:

Question for all:

Is there a way to parse the text and from the DB and display it so that
it looks like the top version. It shows the \n or add a
at the end
of ach on? Can anyone help me?

The simple_format() command will do what you’re looking for. It’s a
Rails helper that will output the line breaks and so on that were
originally entered in your text field.

Jeff C.man


#8

Jean-François wrote:

Hello Jodi,

[6…9]}" if !self.phone.nil? and self.phone_before_type_cast.length
== 10
end

Sorry for my arrogance, but what an ugly code !

Refactory men, where are thou ?

 -- Jean-François.

The simplest solution I can think of is just to do little substitution
in the display:

<%= instructions.gsub("\n", “
”) %>

If all you need is line breaks, then you can’t beat this route for its
simplicity.


#9

Jodi :

Sorry for my arrogance, but what an ugly code !

If you can enlighten, how would you ?

Some ideas :

1/ Instead of 7 calls of #phone_before_type_cast, why not using
a variable ? tmp = self.phone_before_type_cast

2/ if self.phone is nil, in both cases you don’t do anything, so you
can extract this condition.

unless self.phone.nil?
if …

elsif …

end
end

3/ then your conditions are very similar, they deal with tmp.length,
so you can use a case/when expressions.

case tmp.length
when 7

when 10

end

4/ According to your string manipulations, in fact you want to
insert hyphens in very specific positions. So one way is using
String#insert

So now you have many ways to make a cleaner and neater code !

РJean-Fran̤ois.


#10

Jeff C.man <progressions@…> writes:

Rails helper that will output the line breaks and so on that were
originally entered in your text field.

Jeff C.man

Hey Jeff,
I’ve seen your name on a couple of posts discussing simple_format().
Being
relatively new to Rails I hope you can give me additional guidance.

In Edit mode my carage returns and par breaks in a notes field show up
nice and
pretty just like the above recipe. I’m trying to output the notes in a
grid on
the “list” view page but the text runs together as described in the
original
problem above. Using the simple_format() helper in my “list” view as
such:

<%=h simple_format(status["notes"]) %> Displays the html tags. I don't want to see the tags. I just want the text to display as it does in edit mode.

If I’m being an idiot I’m cool with you pointing that out. Thanks for
the help.


#11

Kevin Chambers wrote:

Using the simple_format() helper in my “list” view as
such:

<%=h simple_format(status["notes"]) %> Displays the html tags. I don't want to see the tags. I just want the text to display as it does in edit mode.

“Displaying” tags rather than rendering them is pretty much what h() is
for. Stick it inside simple_format instead, like <%=simple_format(h
status[“notes”]) %>.


Henrik N


#12

Thanx for alternate thoughts Jean-Francois (no cidelle on my
keyboard, grin).

Although I do inherently normalize, I find the lack of temp vars and
the one liner if’s to be quite readable - others mileage will surly
vary. The case/when would be a nice usage.

Beyond the re-factoring conversation, I do believe that such code
does lie in the model - not in the view (as suggested by a few others
in this thread). This argument is clearer if this db field is
displayed/accessed in more than one location (which may not be the
case for the recipe example). But for myself I strive to limit the
view to code that an html/css/javascript coder can handle.

J


#13

Henrik N <henrik@…> writes:

“Displaying” tags rather than rendering them is pretty much what h() is
for. Stick it inside simple_format instead, like <%=simple_format(h
status[“notes”]) %>.


Henrik N

Thank you! That worked perfectly.
K.