Chris Oliver

Hey Gareth, when you do a soft delete, there should be nothing that happens other than a database field called deleted_at getting set. This won't affect images at all because they should only get removed when destroyed. Are the images actually getting removed?

You could calculate the total and cache it. That would make for editing to be easier. For totalling, that might make it easier where the total defaults to 0 until the clock_out time is added so the sums are always correct.

I don't see any real downsides to that off the top of my head. Do you?

You could do

def set_uuid
  return if persisted? # Don't run if this record has already been saved

    begin
      self.minecraft_uuid = MojangApi.get_profile_from_name(minecraft_uuid).uuid        
     rescue Exception => e
     end
end

You could use something like Pundit to count the number of subscriptions and cause something else to happen or prevent it from working at that point. Check out this episode https://gorails.com/episodes/authorization-with-pundit

Recurring events get complicated quickly! :)

You may need to do a find_or_create for all the recursivedates when you do an edit. It also might be easier to delete all the existing ones before adding the new dates. That will save you some trouble. I'd take a look at how Google Calendar does it and work backwards from there if you like the way it works.

I think they may calculate on the fly the recurring ones so they don't have to insert records for X years into the future and your calendar will always work. They probably separate individual dates and recurring ones and query for both each time the page renders.

That's not a bad solution for now to handle it manually.

In general, you simply want to lookup and validate the UUID only when the username changes. There are a bunch of different ways you could do that, but I forgot that you could use ActiveModel::Dirty to check if the username field had changed. This works because when you set the field the first time it technically "changed" from nil to one the user submitted.

before_validation set_uuid, if: :username_changed?
validates :minecraft_uuid, presence: true

def set_uuid
    begin
      self.minecraft_uuid = MojangApi.get_profile_from_name(minecraft_uuid).uuid        
     rescue Exception => e
     end
end

The best way to handle that is authorization with Pundit. You can load up the project and verify if the current user has access to the project based upon the associations set. They will be able to change the ID in the url, but Pundit will throw an error if they try to access one they aren't a part of. Here's an episode on Authorization With Pundit that I did a while back.

Basecamp follows this approach and doesn't have any troubles. It will always depend on how intense your JS ends up being, but you can also cache the results of these queries in the constructor and reference their results for faster access.

At the end of the day, if you're not doing that much constant manipulation, you're not going to run into any performance problems with this. Obviously when you're doing a lot, you're going to want to know exactly how the browser handles each manipulation.

Agreed, this was my point that was hard to get across in a simple example. It's not hugely beneficial on small projects or teams, but it adds up the larger a project becomes.

As soon as you have a designer or two fiddling with the .todo class in CSS and moving things around, you're likely to see things break really quickly. They won't understand how they broke functionality and it's much harder to track down when things go wrong.

I'd say the main benefit of using data attributes instead of classes is that it's a clear separation of responsibilities. Designers can fiddle with all the classes and IDs they want so long as you remind them not to mess with the data attributes. It's just a little easier recognizable than "js-" prefix.

Yes! There were a few episodes that I did sloppily in the past that don't have it but most all of the recent ones have source code linked in the Resources section underneath the video. Some of them I use the same repository for so you can see the evolution of the code in the various commits like this one: https://github.com/excid3/gorails-episode-56

Sounds like you've got an issue with your internet connection.

http://stackoverflow.com/qu...

That's all correct except I don't think you need to move the schools_controller.rb because it's a top level controller.

Good luck and fingers crossed it all works! :)

Ah, yes. What you really want is a before_validation rather than before_create to look up the UUID and then attach it to the model. Then your validation can check to make sure that the UUID is not nil.

class User
  validates :uuid, presence: true

  before_validation :set_uuid, unless: :uuid? # Skip the validation if the uuid is already set

  def set_uuid
    self.uuid = MojangApi.get_profile_from_name(username).uuid
  rescue Exception => e# You will need the MojangApi exception thrown when not found
    # This can be empty because we just need to make sure it doesn't break
  end
end

So this basically would be what you want to only look up the UUID the first time and if it is already set, you can leave it.

Optionally, the only other thing you might want is a hidden field for the UUID in the form if validations fail so that you can submit it the second time without having to do a second lookup.

Yep! Routes are fine.

You want to put the code in the app/controllers/schools folder so that it can detect it properly as the module. Just create it and store it in there and you'll be fine.

Also you want to have it inherit from ApplicationController because I forgot that part.

Might give this episode on nested routes a rewatch. This is where I touched on how the modules/nesting work for organizing your code into folders.

Gotcha, yeah you would definitely want to separate those then.

So here's how you can set that up (basically nested routes).

resources :schools do
  resources :pins, module: :schools
end

This route basically generates /schools/:school_id/pins (verify that with rake routes).

That means you can query the school from the URL by doing @school = School.find(params[:school_id])

# app/controllers/schools/pins_controller.rb
class Schools::PinsController
  def index
    @school = School.find(params[:school_id])
    @q = Pin.search(params[:q])
    @pins = @q.result(distinct: true).where(school: @school).order("created_at DESC").paginate(:page => params[:page], :per_page => 10 )
    respond_with(@pins)
    authorize @pins
  end
end

I moved the where into the result line because that's where you're doing the other scopes so it fits a bit better. In general, I think that should work and should separate out things nicely between the schools.

You can also authorize @school here to verify they can only ever see pins for their school as an added bonus.

It might make sense to have pins nested under the school depending on what you're trying to accomplish. If you're trying to scope the pins to a school, that's what I would do. Then you can grab the school's ID from the url to filter the search.

The other alternative is to put a hidden field in the form to pass in the school_id_eq parameter in the URL so that pins are filtered by that ID. This makes the pins controller generic, so it can be used for seeing pins from multiple schools.

What's the URL for the Pins index? Is it /schools/:school_id/pins?

It might be. I didn't see anything requiring you to set it. I just updated the code from the GoRails episode and everything is working fine without the token(and it didn't require me to put the token in the URL).

You're doing this with S3 presigned uploads and that seems to be the piece that's requiring the token?

It looks like the main thing is that you need to set @school in the action. Once you have that, you can either merge that into the params[:q] search options or add where(school: @school) into your query.

Can you access the school off the URL or the current user?

Let me know if that works for you. I'll have to update the video soon.

That's always the hard part of making screencasts for gems like this!