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.
--
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.
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
--
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.
On 7 January 2011 22:45, Vilèlm <vilelm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> 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.daysI do that but it seems doesn''t work. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
>>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. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
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 ..... On Jan 7, 10:55 pm, Mauro <mrsan...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> On 7 January 2011 22:45, Vilèlm <vil...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > 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 > > I do that but it seems doesn''t work.-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On 7 January 2011 23:25, Vilèlm <vilelm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Have you tried adding the last line? > > def create > @supplier = Supplier.new(params[:supplier]) > -KtkLQCka5aDcAXUCpWy3KA@public.gmane.org_expiry_date = @supplier.durc_issue_date + 90.days > > -a6n5p9gnUiRLYScDn9snng@public.gmane.org <-------------------THIS ONEthis 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 -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On 7 January 2011 21:18, Mauro <mrsanna1-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> 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]) > -KtkLQCka5aDcAXUCpWy3KA@public.gmane.org_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> > -- > You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. > To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en. > >-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On 8 January 2011 09:19, Colin Law <clanlaw-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote:> 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? -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On 8 January 2011 10:13, Mauro <mrsanna1-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> On 8 January 2011 09:19, Colin Law <clanlaw-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote: > >> 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?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 -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On 8 January 2011 11:23, Colin Law <clanlaw-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote:> 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.Thank you for very useful information. I should put protected the instance method in the model? -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On 8 January 2011 10:43, Mauro <mrsanna1-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> On 8 January 2011 11:23, Colin Law <clanlaw-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote: > >> 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. > > Thank you for very useful information. > I should put protected the instance method in the model?If you do that then it will not be able to be used in controller or views. Colin -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On 8 January 2011 12:11, Colin Law <clanlaw-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote:> On 8 January 2011 10:43, Mauro <mrsanna1-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: >> On 8 January 2011 11:23, Colin Law <clanlaw-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote: >> >>> 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. >> >> Thank you for very useful information. >> I should put protected the instance method in the model? > > If you do that then it will not be able to be used in controller or views.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 -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On 8 January 2011 11:54, Mauro <mrsanna1-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> [...] > 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 > endI 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 -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On 8 January 2011 13:20, Colin Law <clanlaw-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote:> 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.I''ve changed the default date to null. Thank you for your tips. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.