# Best approach - letting users put their own temp. fields to see diff

**URL:** <https://www.ruby-forum.com/t/best-approach-letting-users-put-their-own-temp-fields-to-see-diff/116566>\
**Category:** Rails\
**Created:** [October 7, 2007, 2:20pm UTC](https://www.ruby-forum.com/t/best-approach-letting-users-put-their-own-temp-fields-to-see-diff/116566 "2007-10-07T14:20:03Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![ramontayag](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/c6cbf5/32.png) [@ramontayag](https://www.ruby-forum.com/u/ramontayag)\
**Post date:** [October 7, 2007, 2:20pm UTC](https://www.ruby-forum.com/t/best-approach-letting-users-put-their-own-temp-fields-to-see-diff/116566/1 "2007-10-07T14:20:03Z")

</div>

Hey everyone!

I need some input on the best approach. I have a model Property that  
has some fields (price, down payment rate), then methods in  
property.rb that compute derived information (down payment amount)  
based on what the users input. Sounds simple enough.

I. PROBLEM  
Here’s where I need help: I want to make a “property calculator” of  
sorts that takes a property, and allows users to input their numbers  
without overwriting the current property to see how the outcome  
(value) of the property/investment changes based on those numbers.

For example… the property saved in the database has a price of  
100,000.00 and down payment rate of 10%. Derived information from  
that: down payment is 10,000.00. In the property calculator, I want to  
input 20% to see how the derived information will change, but I don’t  
want to save this into the property.

II. THE WAY I THOUGHT OF DOING IT  
I know how to do it, but it’s very tedious, and I know that once  
something becomes tedious in Rails and I’m probably approaching things  
wrong.

I was thinking of putting options in each of the methods in the  
Property class. For example,

def down\_payment(options={})  
options.stringify\_keys!  
dpr = options[‘down\_payment\_rate’].to\_f || down\_payment\_rate  
price \* dpr  
end

This sounds nice and simple enough at the start but I have many of  
these derived methods and putting this options thing in all of them  
would be a hassle.

How do you suggest I approach this?

## Thank you

Ramon T.

---

<div class="post-metadata">

**Author:** ![ramontayag](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/c6cbf5/32.png) [@ramontayag](https://www.ruby-forum.com/u/ramontayag)\
**Post date:** [October 8, 2007, 8:09am UTC](https://www.ruby-forum.com/t/best-approach-letting-users-put-their-own-temp-fields-to-see-diff/116566/2 "2007-10-08T08:09:30Z")

</div>

Ramon Miguel M. Tayag wrote:

> without overwriting the current property to see how the outcome  
> something becomes tedious in Rails and I’m probably approaching things
> 
> This sounds nice and simple enough at the start but I have many of  
> these derived methods and putting this options thing in all of them  
> would be a hassle.
> 
> How do you suggest I approach this?
> 
> Thank you

Why would anything be saved back to the database in the first place? Or  
are you doing the math in your app rather than doing it in JavaScript?

–  
Michael W.

---

<div class="post-metadata">

**Author:** ![ramontayag](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/c6cbf5/32.png) [@ramontayag](https://www.ruby-forum.com/u/ramontayag)\
**Post date:** [October 8, 2007, 1:18pm UTC](https://www.ruby-forum.com/t/best-approach-letting-users-put-their-own-temp-fields-to-see-diff/116566/3 "2007-10-08T13:18:55Z")

</div>

The math will be done in the app… 🙂 I don’t mean to save the fields  
into the database if it’s just the calculator I’m accessing.

On 10/8/07, Michael W. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> Why would anything be saved back to the database in the first place? Or  
> are you doing the math in your app rather than doing it in JavaScript?
> 
> –  
> Michael W.

–  
Ramon T.

---

<div class="post-metadata">

**Author:** ![ramontayag](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/c6cbf5/32.png) [@ramontayag](https://www.ruby-forum.com/u/ramontayag)\
**Post date:** [October 8, 2007, 2:52pm UTC](https://www.ruby-forum.com/t/best-approach-letting-users-put-their-own-temp-fields-to-see-diff/116566/4 "2007-10-08T14:52:52Z")

</div>

Just use the original Property to put the initial view together, then  
when changes come in make a new Property from the params but don’t save  
it, just use it to put the requested view together.

def update  
if params[:commit] == ‘Preview Changes’  
@property = Property.new(params[:property])  
render :action =\> ‘edit’  
else  
# update the saved property  
@property = Property.find(params[:id])  
if @property.update\_attributes(params[:property])  
flash[:notice] = ‘Property was successfully updated.’  
redirect\_to :action =\> ‘show’, :id =\> @property  
else  
render :action =\> ‘edit’  
end # if  
end # if  
end # update

…or something like that (maybe your edit action is called “calculator”  
and your update action is called “calculate”). As long as you don’t call  
save or update\_attributes on the property, it will be used in the view  
but won’t get saved to the database. If you don’t want to give them the  
option of saving the changes, make it a separate method that just does  
the first part.