Skip to main content

5 Open Source Vlog - Filtering Events

Episode 69 · July 1, 2015

Filtering events for our custom calendar

Open Source


Transcripts

What's up guys? This is day eight of the vlog, I'm going to keep it short today because I've already recorded an hour long screen cast pair programming with James from Shakycode.com, he's learning programming, we were talking about scopes and how to write really really well defined scopes and clean scopes for your models. That's sort of relevant to what we want to cover on today's vlog is getting those meetings to show up on the right days of the calendar. Just before I started recording, I set up Bootstrap with the Bootstrap-sass gem as you can see here. I love Bootstrap for the simplicity of just diving in, foundations are awesome too, definitely check it out, but I wanted the table for the calendar to look a little bit more like a table so that we could see the events showing up on the right days of the calendar. A little bit better than the way that it would have looked jumbled together in plain text all tightly packed. These tables are full width in Bootstrap and that's really cool because it allows us to see things better. I have a holiday for July 4th in the meetings database table right now, and I want to write a little bit of code to get that to show up on Saturday. So let's dive in.

All of our code here is exactly the same as before. I've added this table class in there so that Bootstrap would look pretty, we are currently on the four-day agenda calendar, which is cool. And we don't really have much else. We need to dive into the body here so that we can go through, and on this day, we need to take those meetings and filter them out, and then loop through each one in order and render those out for the day, that's really it. How do we go do that? The meetings variable is set already because we're inside the meeting's index action, so we can assume that that's already loaded, it definitely is because down below, the old table from the index scaffold is right here, we have meetings, so we can use that variable, and what we want to do is just select out the items that we're going to keep. That basically means that for every meeting that we look at, the start time needs to match the date portion of that time

That's all we actually have to do to pull out the correct meetings. We need to just check one field, the starting time because it doesn't matter what the ending time is, if that's starting time isn't the right day, we don't want to display it on that day of the calendar. This is great, and this is really all you need to do, and then you can go through each of these, and you can say:

app/views/meetings/intex.html.erb

<% @meetings.select{ |m| m.start_time.to_date == day } %>
<div><%= meeting.name %></div>
<% end %> 

Now we have our holiday showing up on the correct day. This is cool because this is completely customizable, and you could say: Let's make a link to the meeting, and I'll let you fill out the link to it, you can do whatever you want with it, but you could link straight to the meeting, whatever you want to do, and you can customize that. This is one of those important pieces that you need to be able to go through. You probably also want to customize how the day get's printed out inside of that block as well, so this piece probably can be taken care of inside the gem, and we could yield that to say a block. Now an interesting thing you'll notice here is that we have that holiday starts at midnight, and what if we modify this so that it starts at three pm, and what if we go here and say: There's a BBQ, and that starts on July 4th, and that actually starts at 4 am, 'cause why not?

If we go back to our calendar you're actually going to see the holidays it is in the list before the BBQ, and that is wrong, we actually want the BBQ to be first because it starts at 4 in the morning and the holiday is until 3pm, let's actually print this out so we can see these times. We want to make sure that we print these out correctly, so we print out the start times next to each of these, we'll see that these are out of order, and we want to make sure that we go back in here and we sort this by the start time, and you can do a sort_by, and if you do an &:start_time, this is the equivalent of saying sort_by{ |m| m.start_time } That's the equivalent of saying: Let's make this block, and then sort by a method on there, you can replace that by the shorthand which I find really useful, and that's just going to sort all of these by that attribute. Now we can refresh the page and the BBQ is going ot be first, and then the holiday is going going to be second, and that's a crucial piece of this application, and the gem that we're trying to build, without these two things, we're not really helping you much, then it wouldn't be simple. That's the key thing, you would have to think about this if we didn't have this piece in there, so this is something that table builder doens't really do, and I think it's fair to assume that you as a developer should be able to understand how to do this, but if you're going to pull this away and if it's going to be consistent for pretty much every application, well then there's your trick, you might as well handle it for them so that they don't even have to think about it, and that's kind of the key to making really great code, which is why rails is so awesome. We can go up here and look at things like date.beggining_of_week and those calculations are no-brainers, and there's something special about that that ruby does really well, so you can just say: Yeah, that's exactly what I want, and you don't have to even think about how does that calculation work, whereas most languages would force you to do that. Here we're making a lot of progress and we've got these meetings pulled out, and now we're at a point where we can take all of this code that we've written, and start pulling them out into helpers or a class or all kinds of different things. I'm trying to figure out what the balance is between template erb code and ruby code is, and I think it's now going to be obvious which pieces are interchangeable, what can we really produce in the view code, and how do we clean this table up and remove all of these things that we no longer need to worry about, and then create that ideal version of our gem. It would be interesting if we ended up with the same result as before where you should just do it all inside a ruby class calling the view helpers to create table tags and head tags and whatever, it might be, it might not be, but I think that's for another day, I think we're going to tackle that really soon. I'm exhausted, I'm going to leave you there with that, and we'll pick this up tomorrow. Peace v

Transcript written by Miguel

Discussion