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

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.

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.

The math will be done in the app… :slight_smile: 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. [email protected] 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.

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.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs