Hello,
I''m a bit stuck with where to put some method calls (separation of
responsibility) and although I''m trying to do it just simply now in the
models, I think my problem raises a bigger question about Fat Models. But
that''s another subject for another day.
Right now, I have ....
Event
has_many meetings
## has an a invitation_expiry date field.
def invitation_expired?
DateTime.now.in_time_zone(''UTC'')
>event.invitation_expiry.in_time_zone(''UTC'')
end
Meeting
belongs_to :event
has_many :invitations
def invitation_expired?
event.invitation_expired?
end
Invitation
belongs_to :meeting
My problem is when an invitation is made, I want to check if the invitation
has expired. I have thought of the following ....
1. include a method call in the Invitation model
## Check if the meeting (event''s invitation) has expired (should it be
called event_invitation_expired?
## Should the invitation know anything about the Event class?
def meeting_expired? ## event_invitation_expired?
meeting.invitation_expired? ## meeting.event.invitation_expired?
end
2. include an event_id foreign key in the invitations table so I can have
the same method as in the Meeting model
def invitation_expired?
event.invitation_expired?
end
I''m happy with either one but am open to other ideas or what you would
do.
The BIGGER question is, what exactly should go in the models?!! We talk
about Fat models, but for me, that doesn''t fit nice with OO
programming. To
me, it''s quite clear that the we are not doing OO programming by
stuffing
our models with everything related to that model. There needs to be another
level of abstraction to keep everything clean and have the separation of
concerns.
I''m a self taught OO programmer and I come from a functional
programming
background, so maybe I''m talking out of my hat. But while writing tests
for
my app, to me, there are just too many code smells.
I look forward to your thought
-ants
--
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.
On 7 December 2011 09:43, Ants Pants <antsmailinglist-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Hello, > > I''m a bit stuck with where to put some method calls (separation of > responsibility) and although I''m trying to do it just simply now in the > models, I think my problem raises a bigger question about Fat Models. But > that''s another subject for another day. > > Right now, I have .... > > Event > has_many meetings > ## has an a invitation_expiry date field. > def invitation_expired? > DateTime.now.in_time_zone(''UTC'') >> event.invitation_expiry.in_time_zone(''UTC'')Nothing to do with your problem, just pointing out that there is no need to worry about time zones when comparing times, ruby will allow for the zone when doing the comparison.> end > > Meeting > belongs_to :event > has_many :invitations > > def invitation_expired? > event.invitation_expired? > end > > Invitation > belongs_to :meeting > > My problem is when an invitation is made, I want to check if the invitation > has expired. I have thought of the following ....Where are you creating the invitation? Maybe the calling code should check before deciding to make it. Also have a look at ActiveSupport/#delegate. That allows you to say that a method is actually supplied by an associated class, so in Meeting for example you can delegate invitation_expired? to Event so you do not need to repeat the method. The use of the name invitation_expired? seems very confusing to me here, that name suggests that it is an invitation object that has expired, how can it expire before you create it? 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 7 December 2011 10:58, Colin Law <clanlaw-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote:> On 7 December 2011 09:43, Ants Pants <antsmailinglist-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > Hello, > > > > I''m a bit stuck with where to put some method calls (separation of > > responsibility) and although I''m trying to do it just simply now in the > > models, I think my problem raises a bigger question about Fat Models. But > > that''s another subject for another day. > > > > Right now, I have .... > > > > Event > > has_many meetings > > ## has an a invitation_expiry date field. > > def invitation_expired? > > DateTime.now.in_time_zone(''UTC'') >> > event.invitation_expiry.in_time_zone(''UTC'') > > Nothing to do with your problem, just pointing out that there is no > need to worry about time zones when comparing times, ruby will allow > for the zone when doing the comparison. > > > end > > > > Meeting > > belongs_to :event > > has_many :invitations > > > > def invitation_expired? > > event.invitation_expired? > > end > > > > Invitation > > belongs_to :meeting > > > > My problem is when an invitation is made, I want to check if the > invitation > > has expired. I have thought of the following .... > > Where are you creating the invitation? Maybe the calling code should > check before deciding to make it. > Also have a look at ActiveSupport/#delegate. That allows you to say > that a method is actually supplied by an associated class, so in > Meeting for example you can delegate invitation_expired? to Event so > you do not need to repeat the method. > > The use of the name invitation_expired? seems very confusing to me > here, that name suggests that it is an invitation object that has > expired, how can it expire before you create it? > > 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > For more options, visit this group at > http://groups.google.com/group/rubyonrails-talk?hl=en. > >Colin, Thanks for your reply. The reason for the explicit in_time_zone call is because, in my app, events traverse different time zones. I parse the event''s invitation expiry date to the selected TZ, that is then saved in the DB as UTC. Upon retrieval, the UTC time is converted back to the chosen TZ. To see if an invitation has expired, I compare it to UTC. I looked into AS#delegate. Thanks for that, I''ll give it a try. I have been googling around on this subject and there are more people that think like me but like I said, it''s for another day. I will refactor my code but right now, I just want to feel comfortable with what I''m doing. Doing away with as many bad smells as possible. Here''s one article I''ve just read http://solnic.eu/2011/08/01/making-activerecord-models-thin.html I could rename the method event_invitation_expired? That''s not a problem. I''m rubbish at coming up with names for things. -ants -- 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.