assign values to attributes.

rubyonrails-talk
1

In my model I did self.durc_expiry_date = self.durc_issue_date + 90.days but I think it is not a best practice to update attributes from model. So I remove that code and put def create     @supplier = Supplier.new(params[:supplier])     @supplier.durc_expiry_date = @supplier.durc_issue_date + 90.days .......

in the controller. But doing so I have no values in durc.expiry.date.

2

IMHO, your first attempt, update attributes in model, is the best practice because model is where you keep attention of your data. Anyway, to save your data in the controller:

def create   @supplier = Supplier.new(params[:supplier]) @supplier.durc_expiry_date = @supplier.durc_issue_date + 90.days   @suplier.save .....

Or maybe, if you want rescue errors:

def create   @supplier = Supplier.new(params[:supplier]) @supplier.durc_expiry_date = @supplier.durc_issue_date + 90.days   if @suplier.save     do stuff   else     do other stuff   end .....

Regards,

Giorgio

3

I do that but it seems doesn't work.

4

I think it is not a best practice to update attributes from model.

In MVC architectures business logic typically resides within models, so setting your expiration date business rule within the Supplier model would be the recommended practice.

5

Have you tried adding the last line?

def create   @supplier = Supplier.new(params[:supplier])   @supplier.durc_expiry_date = @supplier.durc_issue_date + 90.days

  @suplier.save <-------------------THIS ONE

.....

6

this is the entire code:

def create     @supplier = Supplier.new(params[:supplier])    @supplier.durc_expiry_date = @supplier.durc_issue_date + 90.days

    respond_to do |format|       if @supplier.save         format.html { redirect_to(@supplier, :notice => t('Supplier was successfully created.')) }         format.xml { render :xml => @supplier, :status => :created, :location => @supplier }       else         format.html { render :action => "new" }         format.xml { render :xml => @supplier.errors, :status => :unprocessable_entity }       end     end   end

7

In my model I did self.durc_expiry_date = self.durc_issue_date + 90.days but I think it is not a best practice to update attributes from model. So I remove that code and put def create @supplier = Supplier.new(params[:supplier]) @supplier.durc_expiry_date = @supplier.durc_issue_date + 90.days .......

in the controller. But doing so I have no values in durc.expiry.date.

Is there an expiry_date column in the database? You can only put it in the controller if that column exists. However, if the expiry date is *always* +90 days then you should not put it in the database, but should provide an instance method in the model, something like

def expiry_date   self.issue_date + 90.days end

Then you can say durc.expiry_date and will always get issue date + 90 days. The method may have to be a little more complex if issue_date can ever be nil.

Colin

8

Is there an expiry_date column in the database?

Yes there is.

in the controller if that column exists. However, if the expiry date is *always* +90 days then you should not put it in the database, but should provide an instance method in the model, something like

def expiry_date self.issue_date + 90.days end

Then you can say durc.expiry_date and will always get issue date + 90 days. The method may have to be a little more complex if issue_date can ever be nil.

I have not thought about this, I have put curc_expiry_date in the database, is it wrong?

9

If expiry date can always be calculated from issue date then it is wrong to put expiry date in the database. It increases the database size and access time but also adds complexity to the code. For example you have to remember to update it whenever the issue date is changed. If you use a method to access it the code is simpler. Note that other code accessing curc.expiry_date will not see any difference between a value stored in the database and the access method I have suggested. This is known as a virtual attribute. You might like to google for database normalization if you want to find more about how to design the database.

Colin

10

Thank you for very useful information. I should put protected the instance method in the model?

11

If you do that then it will not be able to be used in controller or views.

Colin

12

Yes you are right sorry for my ignorance.

in the instance method

def expiry_date   self.issue_date + 90.days end

I can do

def expiry_date   issue_date + 90.days end

without the word self. Is it the same thing?

Specifically I've done in my model:

def default_date     Date.new(1970, 01, 01) end

def durc_expiry_date   unless durc_issue_date.eql?(default_date)     durc_issue_date + 90.days   else     default_date   end end

13

[...] in the instance method

def expiry_date self.issue_date + 90.days end

I can do

def expiry_date issue_date + 90.days end

without the word self. Is it the same thing?

Including the self keyword just ensures that it uses issue_date from the current object. It jensures that the correct variable is used in case there was another variable of the same name in scope. Some like to do this as a matter of principle. I would always use self when *assigning* to an instance variable as otherwise a slight misspelling will silently write to a local variable rather than the instance variable.

Specifically I've done in my model:

def default_date Date.new(1970, 01, 01) end

def durc_expiry_date unless durc_issue_date.eql?(default_date) durc_issue_date + 90.days else default_date end end

I would generally use null in the database as the default date rather than a specific value, but that is possibly a matter of taste.

Colin

14

I've changed the default date to null. Thank you for your tips.