Enrique García Cota's Profile

No, Pierre's code simply saves you from having to define a method called topic, and a different one called user, with mostly the same implementation.

You don't have a topic_attributes method on every class. You have only one shared method in all controllers and views, called permitted_params. The object returned by that method has methods like topic_attributes inside of it.

Keep in mind that in controllers there is already a shared method called params. I think this solution is very much inline with rails' way of doing things (which you might or might not like).

Hi Ryan,

Thanks for this tutorial. I certainly prefer Active Model Serializers to RABL or Jbuilder. I also like the default rails' as_json method.

I have a comment regarding that. You have mentioned in several tutorials, that "we can get some basic json api by overriding the as_json method".

While this is true, it's also not recommended. Overriding as_json has a very well known downside: it doesn't respect the overriden as_json method in included structures. For example:

• Let's say that Article has_many :comments.
• You override as_json in Comment and Article. On the latter, you add a :include => :comments clause.
• When you do render :json => @article in your controller, the article will include the comments, but they will not have the format that you specified in Comment#as_json. Instead, they will come with the "Rails default format".

The reason this happens is because of the way Rails is built internally. In some edge cases, reading the structure provided by as_json would provoke infinite loops.

The recommended way to solve this issue is using an external lib, like the ones you mentioned. But if you don't want to, or can't do it, then your next best thing is to overriding serializable_hash instead of as_json. Both methods work very similarly, serializable_hash just happens before in the call stack. Usually replacing def as_json by def serializable_hash in all models is enough to fix the nested dependencies issue.

I enjoyed this episode very much. I especially liked the idea of using a PermittedParameters class.

I'm not sure I like filtering the view using PermittedParameters. I can't say exactly what I don't like about it. I feel that is a job for cancan, or other authorization gem.

I needed a simple, straightforward way of exporting AR collections to excel, and I ended up doing the to_xls gem.

Awesome episode as always, thanks!

One question, though: Do you need to add an id to the edit link?

I usually filter by the data attribute. I mean, instead of this:

  var link = $('#mercury_iframe').contents().find('#edit_link');

I usually do something like this:

  var links = $('#mercury_iframe').contents().find('a:data(save-url)');

Am I missing some obvious drawback by using this approach?

My first impulse when watching the first part of the episode was "just mock the Time.zone method so that Time.zone.now returns a fixed date"

Wouldn't that have been enough?

This is awesome!

this + inherited_resources + (simple_form || formtastic) = scaffolding--

:)