shakycode

Oooh Evil Cognos... lol.

I'm having to deal with data translation and import so the way I did it was to write a simple rake task using the CSV class that imports my data into the appropriate models. I gleamed some of the code from Chris' CSV upload tutorial he posted on GoRails recently. If you need some help or example code, let me know. I love this sort of stuff.

I'm actually working on something similar in iOS with one of my Rails apps and I hand the OAuth token back to the Rails app. There wasn't a need in my case for the token_authenticatable gem.

I'm with Chris on this one. You're going to want to either create a wizard controller that deals with the different stages of the order and checkout process. Due to session/cookie length there's only so much data that you can cram into it and for this type of application you really want to be keeping track of state via a persisted database object.

If you want to look at Wicked and need some help, let me know. Chris schooled me on Wicked a couple of years ago and I've since gone on to do some really complex things with it.

As for abandoned records with a persisted database object, you could always have a rake task that runs every 24 hours and looks for incomplete orders (objects) and delete them or better yet keep them attached to the user in a "order history" and allow him/her to delete the order (simple destroy controller action).

My advice on persisted database objects with Wicked is keep a good eye on your model validations. Things can get screwy really quick when tracking state via a persisted object when you're mixing in a lot of model validations. This is just my experience, so there may be a clean way to handle this that I'm not aware of but it was a pain in the ass for me in the past.

Nice video, glad Gareth got some help. I like the idea of storing the cookie to hide the form. Not foolproof but definitely better than being prompted to sign up again. Awesome!

I'm stumbling over the grouped_options_for_select here. Could you give me a hand in translating this into a regular select? I'm having a dumb blonde moment.

<%= f.grouped_collection_select :location_id, Region.order(:area), :active_locations, :area, :id, :location_name, {include_blank: true}, class: 'select' %>

I also tried a regular select with the .map and passing data attributes to test it out and it won't connect to the jQuery. Nothing fires on change and there's no console output.

Here's what I tried in the form:

<%= f.select :location_id, Location.all.map{ |c| [c.location_name, c.id, data: {address: c.location_address}] %>

And here's what my jQuery looks like:

jQuery ->
$("#run_location_id").on "change", (e) ->
selected = $("#run_location_id option:selected")
$("#location-address").html("""
<h3>#{selected.data("address")}</h3>
""")

Sweet, sounds like I'll be looking into the grouped_options_for_select with f.select then. Hoping it doesn't break all the other coffee I wrote :) All part of the fun. I'll post if I get stuck.

Yeah, the only reason why I'm using the grouped_collection_select is so I can split locations by regions. So all of Dallas locations will show first, than Houston, etc. Looks like I got my hands full with this one today.

Ok, I'll look into this. grouped_collection_select is kicking my ass today.

Chris, how would this work if I'm using a grouped_collection_select? Can I pass data attributes into it? I'm pretty sure by using .map I can pass the data and display the jQuery/Coffee, but my select is a grouped one. Below is sample code:

<%= f.grouped_collection_select :location_id, Region.order(:area), :active_locations, :area, :id, :location_name, {include_blank: true}, class: 'select' %>

I really want to do this in React. Just sayin.

Ah, I see where you're going with this. Makes sense to me. Good catch(s).

Brent,

Definitely post up what you changed so that it may help others.

Also, if you don't need this as a global constant you can also do something similar in a helper. But from the sound of it, you'd want a global constant for this use case.

I was watching CodeSchool's "Feature Focus" the other day. This is where Greg and Carlos look at a popular site/app and pick a piece of functionality to focus on and write it themselves. They then compare it to how the actual site does it and gets great feedback from the developers.

I propose something similar on GoRails. Maybe we can find different sites that have unique functionality, stub out that functionality in a screencast video, and go over best practices for implementation/etc. This would generate a ton of new ideas for content and would really provide value to subscribers and visitors of GoRails.

Thoughts?

Will do. I'm sure we can come up with something great.

Speaking of Shopify and others. I have an idea for new screencasts. One of the things CodeSchool has done is create a section called feature focus. Where they try to mimic a feature of a well known company (basecamp, groupon, etc) and show the audience how to implement it into their own apps and then the company shows how they are doing it (more or less). Doing something similar with GoRails would be pretty awesome. We could pick a site and look at a certain feature we want to implement and then a screencast could be made about it. Sorry to go offtopic, but there are a lot of cool things being done out there that I think GoRails could capitalize on for content ideas.

Jeff, this is actually a clean way to handle it. Thanks for chiming in.

Cool deal, ultimately it's up to you how you handle 404s but if your UI is tight you should never receive a 404 in your app from clicking on something unless it's broken. Someone randomly doing a GET request on a URL that doesn't exist should be met with a 404 to keep in compliance with best practices. Ultimately, you can handle it any way you like but I personally like to stick with standards whenever possible.

Cheers!

React is killing it out there. Granted, it's relatively new but it's really going to be THE js framework to be watching in the next year to three.

Redirecting to root path on a 404 request is not standard practice. And it will impact your SEO in a negative fashion although not to an extreme. 404s need to be 404s.