act_act_api + mongoid psuje test

Potrzebna pomoc
1

Kiedy dodaje act_as_api do mojego modelu ponizszy test wyrzuca nastepujacy blad

2) ProjectsController show project return json Failure/Error: get "#{url}.json" NoMethodError: undefined method `key?' for nil:NilClass
Test

[code=ruby] context “show project” do
let(:url) {"/api/v1/projects/#{@project.id}"}

before do
  @project = create(:project)
end

it "return json" do
  get "#{url}.json"

  json = last_response.body

  json.should be_json_eql(@project.to_json)
  json.should have_json_path("title")
  json.should have_json_size(3)
end

end[/code]
Kontroler

[code=ruby]class Api::V1::ProjectsController < ApplicationController
respond_to :json

skip_before_filter :verify_authenticity_token

before_filter :find_project, :only => [:show]

GET /projects/1.json

def show
respond_with(@project, :api_template => :public)
end

private

def find_project
  @project = Project.find(params[:id])
rescue Mongoid::Errors::DocumentNotFound
  error = {:error => "The project you were looking could not be found"}
  respond_with(error, :status => 404)
end

end[/code]
Model

[code=ruby]class Project
include Mongoid::Document

field :title, :type => String
field :description, :type => String

attr_accessible :title, :description

act_as_api

api_accessible :public do |template|
template.add :title
template.add :description
end

end[/code]
zgodnie z tym opisem https://github.com/fabrik42/acts_as_api/wiki/acts_as_api-and-Mongoid
dodalem to do config/initializers/act_as_api.rb

2

wywal to acts_as_api w cholere :stuck_out_tongue:

drogus ostatnio zrobił prezentację o JSON API na WRUG-u. Wcześniej też próbowałem (chwilowo porzuciliśmy tworzenie API więc przestałem go używać zanim na dobre zacząłem) używać acts_as_api, ale Piotrek swoją prezentacją mnie przekonał :smiley:

3

To forum schodzi na psy.
"

  • w jednym miejscu nie działa mi współpraca z gemem X, co muszę poprawić?
  • wywal gema X w cholerę
    "

W którymś drafcie nowego regulaminu tego typu “dobre rady” były explicite zabronione, aż chyba zaraz sprawdzę czy weszły do wersji finalnej.

Enyłej: lewy313, pokaż pełnego backtrace’a, Gemfile i initializer w którym domiksowujesz ActsAsApi::Adapters::Mongoid.
Spróbuj też include ActsAsApi::Adapters::Mongoid zrobić w samym modelu, zaraz przed linijką “acts_as_api”.

4

Ej, bez przesady, przecież mówiłem na końcu, że każdemu jego porno, więc trzeba się zastanowić co mi nie pasuje. I mówiłem, że te gemy są całkiem fajne, ale ja mam z nimi trochę problemów koncepcyjnych :slight_smile: (DSL, implicit, w modelu, trudniejsze do testowania jednostkowego)

Tzn. ogólnie tak jak Tomash napisał, nie bądźmy radykalni, w ten sposób w co drugim temacie można by pisać, żeby przepisać swoją aplikację na “tró” gemy, które akurat komuś pasują.

5

@lewy313 acts_as_api jest fajne jak ma się jeden template per model. Inaczej trzeba pisać jakieś magiczne helpery które będziesz wywoływał razem z respond_with, które będą Ci wybierały konkretny template. Jakaś masakra. Jeżeli dopiero zaczynasz pisać to API to radzę się zastanowić nad innym rozwiązaniem zanim zabrniesz za daleko :smiley:

@drogus To przecież podesłałem link do Twojej prezentacji, żeby kolega obejrzał i sam zdecydował. Nie powiedziałem “wywal bo tak i koniec, zamknij się i nie dyskutuj” :wink:

@Tomash ale rady w stylu “wywal tą książkę” czy “wywal windowsa zainstaluj linuksa” są ok? :expressionless:

6

ok, źle zrozumiałem :slight_smile:

7

Tak. acts_as_api jest jednym ze sposobów (czy lepszym czy gorszym) na zrobienie API w aplikacji.
Zmuszanie Railsów do pracy pod Windows albo nauka ze złej książki to nie jest żaden sposób na development.

Nieładnie tak kłamać.
“Wywal w cholerę” to zupełnie coś innego niż “obejrzyj tę prezentację i zastanów się czy potrzebujesz tego gema”.

A co do meritum: @lewy313, a zrobienie w kontrolerze explicite respond_to do |format| format.json, bez skrótowego “respond_to :json” też nie pomaga?

8

[quote=Tomash]Tak. acts_as_api jest jednym ze sposobów (czy lepszym czy gorszym) na zrobienie API w aplikacji.
Zmuszanie Railsów do pracy pod Windows albo nauka ze złej książki to nie jest żaden sposób na development.[/quote]
O nie, to też jest [gorszy] sposób na development. To że przy okazji wyrzucisz komputer przez okno to inna sprawa. Jak można dawać takie rady to można i radzić niekorzystanie z [gorszego moim zdaniem] sposobu tworzenia API.

Nieładnie tak kłamać.
“Wywal w cholerę” to zupełnie coś innego niż “obejrzyj tę prezentację i zastanów się czy potrzebujesz tego gema”.[/quote]
Uczepiłeś się tego pierwszego zdania jakby twórcy acts_as_api Ci płacili za zabijanie każdej negatywnej dyskusji na temat gem-a :smiley:
Chyba lewy313 nie poczuł się (chociaż olał temat więc nie wiadomo :D) jakbym go do czegokolwiek zmuszał.

Disclaimer: Nie, drogus mi nie płaci!

9

Dziekuje za link prezentacja bardzo mi sie podobala

Moglem wyjasnic to w pierwszym poscie. Dla celow czysto edukacyjnych robie porownanie (poprzez realna aplikacje) gemow do pisania api z frameworkami javascript do pisania frontendu. To o czym opowiadal Drogus na prezentacji tez napewno zalicze :wink:

[quote=Tomash]pokaż pełnego backtrace’a, Gemfile i initializer w którym domiksowujesz ActsAsApi::Adapters::Mongoid.
Spróbuj też include ActsAsApi::Adapters::Mongoid zrobić w samym modelu, zaraz przed linijką “acts_as_api”.[/quote]
Przed zalozeniem tego tematu probowalem z tym modulem, w obecnej wersji kodu wogole wywalilem initializer na rzecz tego modulu niestety dalej nie dziala

gemfile, backtrace, spec_helper

respond_to do |format| format.json { render_for_api :public, :json => @project } end
Przy tym kodzie ten sam blad

Nie olalem tylko pracuje :wink:

Co do mini flame ktory sie wytworzyl. Tak naprawde uwazam ze istnieje bardzo duzo dobrych podejsc do tworzenia API. Tak samo jak z jezykami programowania. Jezeli wezmiemy pod uwage top20 to nie ma zlych jezykow jest tylko zly kod i zle zastosowanie. Porownanie ktore teraz robie jest wlasnie po to abym na przyszlosc wiedzial kiedy dobrze jest uzyc podejscia A a kiedy B

10

Ja tylko dodam, że być może najlepiej dla większości osób będzie użyć serializerów, o których wspomniałem na końcu prezentacji: https://github.com/josevalim/active_model_serializers

Jest to bardzo podobne do pojęcia “presenterów”, o którym mówiłem, a zaletę ma taką, że jest dodatkowo ma kilka pomagajek dla railsów.

Z fajnych gemów w temacie jest jeszcze: https://github.com/apotonick/roar. To co jest ciekawe w tym podejściu, to to, że stworzone klasy stosujemy przy parsowaniu i generowaniu kodu, więc jest to w pewien sposób wygodniejsze.

11

Naprawde mogles to rozwinac w prezentacji bo asocjacje to pierwsza problematyczna rzecz w api :slight_smile:

12

Tak, wiem. Niestety serializery wyszły bardzo niedawno, nie zdążyłem im się bliżej przyjrzeć wcześniej, a tym bardziej wykorzystać w praktyce. Jakbym teraz robił tą prezentację to prawdopodobnie bym po prostu opisał serializery :slight_smile: Ale cieszę się, że przynajmniej pokazałem jak to można zrobić w bardzo prosty sposób samemu.

No i te asocjacje też nie są takie problematyczne znowu :wink:

[quote]class Api::Post < Api::Presenter
def as_json(*)
{
:comments => comments
}
end

def comments
Api::Collection.new(super, Api::Comment).as_json
end
end[/quote]
Co prawda w serializerach możesz to zrobić:

has_many :comments, :serializer => Api::Comment

Ale 3 linijki explicit kodu vs jedna trochę bardziej ukrytego, to też nie tak źle :slight_smile:

13

Wszystko ladnie pieknie ale nie maja jeszcze wsparcia dla mongoida out of the box :wink:

14

Sprawdzałeś co nie działa? teoretycznie to active model, więc nie powinno być problemu. W razie czego nie powinno to być trudne do naprawienia, a jose na pewno chętnie przyjmie pull requesty :>

15

Rzucilem okiem okazalo sie ze gem autoloaduje swoj modul tylko do ActiveRecord + mongoid#all dziala inaczej niz activerecord#all stad problemy. Zobacze co da sie zrobic w trakcie swiat