Chris Oliver

This is awesome. I haven't extended sprockets myself before and that looks like it turned out rather nicely. I'm impressed! :D

Hey Stephen!

Rails doesn't have anything built-in to support this kind of feature. It doesn't make many decisions on how you should handle the frontend for you which makes sense since it's a backend framework more or less.

As far as what you've got, I'd say it's definitely not bad. There are some improvements you could make by having it become more dynamically created.

For example, you could store a Hash of all the data in Javascript or somewhere in the HTML and load that up into the JS. Once you had the data in an object in JS, you can then dynamically create the select options and everything from there. An example of that would look something like this: http://stackoverflow.com/a/6601129/277994 Yours would need to be a little more complex because you have different groups of data to show, but the concept is similar.

You can imagine having an object in JS that looks like this full of data (you could structure this any way you wanted):

var regions = {
  "us": {
      "name": "United States",
        "states": [
          "ca": {
              "name": "California",
                "cities": {
                  "losangeles": "Los Angeles",
                    "sanfrancisco": "San Francisco"
        }
          }
        ]
    }
}

And if you had all the data like this, you could then grab out portions of it to fill out your fields. Such as you could gather all the name values of the top level regions to populate the region select. Once a region was selected, you could grab the states from it and populate the state/province level from there and so on.

It would require a lot of work to change, so don't feel like you need to clean it up right away. You can always improve this code later once it's working.

Check out https://github.com/rbenv/rb...

This lets you write a .rbenv-vars file in your rails app directory and set environment variables separately outside of your Rails app.

I'm using this for the new Rails hosting service I'm working on and it works wonderfully for separating environment variables out for each app.

Hey Nicolas,

That's great then. If you don't have any forms or anything for now, just cache it all and don't care about it.

You can add Javascript and an endpoint for the CSRF token later on when you add the contact form in the footer which you'll probably want to submit with AJAX anyways. It'd make perfect sense to just add in a csrf endpoint to retrieve the token and submit it in that case.

That's one of the easier solutions for caching since you don't have too much dynamic content and that'll make your life a whole lot simpler. :)

If you notice the INSERT INTO statement does not include an email which means your tests probably aren't generating random email addresses for the AdminUser objects it's trying to create. You should make sure that those are being generated on your own or with something like factory_girl so that you won't have conflicting user objects in your tests. I'm pretty sure that'll solve your problem once you get that fixed up.

Whoops, I had this tab open to reply to at some point...9 days later. :P

Yeah, you'd probably need to pass the partial name in to pass over the presenters that way. I'm sure there's some way you could override some things in the presenter trick Rails into rendering the proper partial name automatically. The draper gem might be able to do that and have some insights on how to pull that off with your own implementation. I know that they have a Relation-esque collection object that might be what you'd need to add to your own implementation from scratch to do that.

Yeah, I can see going both ones. On one hand, the developer effort is easier to just generate and save the recurring events but it makes the user experience a lot tougher (how do remove them all? what if you want to edit all of them? what about just one?). And then on the other hand, it's easier for the user, but tougher on you as a developer to build the ice_cube style recurring events and query for those.

You'll probably be fine either approach you take, just remember it can always be changed and improved later on so it all depends on what business needs are most important. :D

Awesome, good luck and let us know how it goes! Only other thing I'd mention is you might want to change the name of Account to User so it's more standard for anyone working on the code later on. 🤘

Hey Orlando,

Would the Account be what the user logs into in your example?

I think that would make sense. You can then have multiple users for a single school (say several administrators) or even both parents could have separate accounts with your app.

Everyone could login through the same Account sign in form and then be redirected appropriately to the various views for parents or schools depending on their account type. That's probably the easiest experience for your users than having two separate login pages, one for parents only and another for schools only.

Ah yeah, that's a pretty complex one. I think what I would probably do is this:

1. Query for all the individual events
2. Query for all the recurring events within that range. This would match recurring events where the start date is before the end of the query and end dates of null (infinitely recurring) or end date after the beginning of the query.

Then I'd load those recurring events into ice_cube and then run the generator to create all the events for the recurring ones within your query range.

3. Then you can combine those two arrays of events into one and your view will have an accurate set of event objects to use for that query range.

Obviously, it's not as simple as the alternative of making recurring events just insert regular event records into the database. That may be good enough for your solution, or you may want truly infinite recurring events which would require you to build a bit more of a complex query system like above.

Here's the latest episode on advanced counter caching. 🙌 https://gorails.com/episode...

Depends on what you're trying to accomplish (like everything right? lol). What kind of search are you trying to pull off?

Yeah that's correct, if you're doing both you'll want to make sure any forms submitted verify authenticity token and the JWT token is the only one that should skip that. 👍

That's a great question. If you need to build decorators that work in both cases, then yes, you'd want to do one of two things:

1. Separate decorators for JSON and HTML and wrap them accordingly depending on the response type. Downside to this is more decorators.
2. Build generic decorators and leave it up to your views. Downside to this is that part of the benefit of having the link_to's and etc in the decorator is that your view can remove logic entirely. That's probably not possible if you're not able to write logic in the decorator.

That's a fun one. I would imagine you could build a validation for this that would do what you want.

Some pseudo code for you:

class Model
  has_attached_file :attachment

  validates :attachment_against_api

    def attachment_against_api
      response = API.send(attachment)
        errors.add(:attachment, response.message) if response.failure
    end
end

I thought that was the case! It didn't work for me the first time I tried it, but it could have been spring caching things or something. Thanks for sharing that. :D

CSRF tokens are generated for each user, which is why they should not be cached. The CSRF tokens are specific to each user and request so that you can determine whether or not it was the user taking this action or malicious code.

To solve this you have 3 options:

1. Don't cache the form
2. If you're fragment caching, use Javascript to include the CSRF token. See here: https://coderwall.com/p/0sctaa/forms-csrf-authenticity-token-and-fragment-caching-in-rails
3. If you're doing full-page caching, use one of these mthods: https://www.fastly.com/blog/caching-uncacheable-csrf-security

Hey Aime,

I don't believe there was much (or any?) CSS in that episode that I wrote. All the source code for that episode should be here: https://github.com/gorails-screencasts/gorails-episode-78

Atwho.js does include some CSS with the library to style the mention box: https://github.com/ichord/At.js/blob/master/src/jquery.atwho.css

Yep, shouldn't have a problem. You can always check out their GitHub if you run into issues.

Rake isn't deprecated, they just added a way for you to call it with the rails command so it's less confusing when to use rake vs rails commands. It still functions exactly the same, just simpler now. 🙌