Spotykamy się jak zwykle o 19!
Przepraszam, ale tym razem ja odpadam. Jutro, najpóźniej w piątek, muszę złożyć pracę dyplomową, a muszę jeszcze nad nią trochę popracować (oraz odespać manko).
Szkoda. Info dla wszystkich: Wrug must go on!
Dzięki organizatorom za organizacje, a współuczestnikom za współuczestniczenie. I dzięki za wprowadzenie na Djangopiwko które też niczego sobię ;]
Pozdrawiam
Lightning Talk: opis zmian w Rubym 1.9.3 http://vimeo.com/34117081 (najciekawsze są chyba komentarze Shota i Drogusa)
Jest gdzies dostepny kod z prezentacji drogusa ?
A wrzuciles gdzies moze same slajdy? Tez bylyby przydatne
Moglbys sie moze tez podzielic jakimis ciekawymi linkami na temat tworzenia i testowania API?
Jak w najładniejszy sposób dodać linki do zwracanych poprzez API danych.
Na przykład mam komentarz, który należy do jakiegos posta i chce aby ten komentarz zwracał też url do tego posta, do którego przynależy
Właśnie coś takiego ostatnio dodawałem 
Możliwości są dwie.
- Rozszerzasz presentery tak, żeby miały dostęp do helperów i tym samym url helperów, mniej więcej coś takiego jak tutaj:
http://going-beyond-mvc-moscow.heroku.com/#83
Wystarczy wtedy jako drugi argument podać view_context, czyli np. w controllerze:
PostPresenter.new(post, view_context)Żeby było prościej to zbudować w kontrolerze, to możesz zrobić taki helper:
http://going-beyond-mvc-moscow.heroku.com/#89
I używać mniej więcej tak:
http://going-beyond-mvc-moscow.heroku.com/#90
Domyślnie ten helper próbuje zgadnąć jaka powinna być klasa presentera, którego chcesz użyć, ale można podać jako drugi argument klasę jaką chcemy opakować obiekt.
- Dodać do Presentera obsługę url helperów:
[code]class Api::Presenter < SimpleDelegator
include Api::Engine.routes.url_helpers
class << self
delegate :default_url_options, :to => “ActionController::Base”
end
end[/code]
Przy czym wtedy trzeba na sztywno ustawić default_url_options[:host], dla ActionController::Base, bo przy takim ustawieniu nie ma w presenterach dostępu do danych z requestu. Ja chyba wolę pierwsze rozwiązanie, ale szczerze mówiąc długo się nad tym nie zastanawiałem, więc mogłem coś przeoczyć.
Dzięki 
Jednym z plusów używania enginów do pisania API jest łatwość wersjonowania. Tworzę sobie nowy engine dla nowej wersji, podpinam go w innym punkcie montowania i wszystko śmiga.
Zastanawiam się nad faktem, co jeśli ze zmianą wersji API zmienia się też sposób tworzenia obiektów. Na przykład są używane inne walidacje i callbacki przy tworzeniu obiektu. Nie chce tych walidacji i callbacków wrzucać do modelu w aplikacji, po to aby wszystkie zmiany mogły się zawierać w zmianie samego API. Pytanie gdzie, jak i dlaczego miałbym je wrzucić.
Dobre pytanie. Można by zrobić model, który dziedziczy z Twojego głównego modelu, ale jest namespace’owany, np:
[code]class Api::Post < ::Post
własne walidacje
end[/code]
Tylko wtedy nie wiem do końca jak prosto usunąć już istniejące walidacje. Może wtedy warto by Post rozbić też na 2 modele - jakiś nadrzędny, który będzie wspólny i 2 dodatkowe klasy, jedną dla api i jedną dla aplikacji, gdzie będą różnice.
Na razie tyle mi przyszło do głowy, ale jak coś wymyślę, to dam znać
Dzięki za odpowiedz. Moje myśli właśnie zmierzają w podobnym kierunku i potrzebował potwierdzenia ze strony autorytetu
Kiedyś w spree jakoś walczyłem z usuwaniem dziedziczonej z klasy nadrzędnej walidacji i jakoś da się to zrobić.
Jakbyś jeszcze miał jakieś przemyślenia w tym temacie, chętnie się z nimi zapoznam
Jak się teraz jeszcze nad tym zastanowiłem, to pozostaje jeszcze problem bazy danych. Jeżeli coś jest validowane np. w starej wersji API, a w nowej już nie, to w starej wersji będzie trzeba mieć do czynienia z rekordami, które nie mają jakichś wymaganych pól i może wystąpić problem z edycją. Masz jakiś konkretny przykład takiej zmiany?
Sprawa wygląda tak, że do wyszukiwania miejsc używamy google places api. I wymagamy podawanie google place id do ich identyfikacji i na podstawie tego wyszukujemy/tworzymy rekord miejsca u nas w bazie, gdzie przechowywujemy specyficzne dla nas info o miejscu.
Jak już zarobimy miliony, będziemy pewnie chcieli przestać korzystać z google places i to wszystko wziąć na siebie. Wtedy już od akcji związanych z miejscami nie będziemy wymagać google place id tylko własnego i po drodze nie będziemy musieli wyszukiwać/tworzyć rekordu dodatkowych info o miejscu. Czyli będziemy wymagać podania innych atrybutów i obecne callbacki przed validacyjne nie będą potrzebne.