Cześć, mam mały problem z wybraniem jakiegoś sensownego podejścia do tworzenia prezentera. Ogólnie problem mam taki, że na widokach mam za dużo logikii, chciałem ją przenieśc do Prezentera i tu spotkałem się z X sposobami, na które ten pattern jest rozpisywany na przeróżnych blogach. Dość często można znaleźć podejści, w którym Prezentery są implementowane z wykorzastaniem Drapera, jednak nie podoba mi się takie podejście (ściśle związane z jednym modelem). ( Wydaje mi się to problematyczne, jeżeli z widoku chaiłbym przenieść jakieś warunki związane z więcej niż 1 modelem). Wpadłem na taki artykuł: https://www.happybearsoftware.com/rails-presenters-for-readable-modular-and-testable-code
Na podstawie tego podejścia, chciałem rozpisać Prezenter per page, nie per model. i w nim mieć metody zgodnie z zasadą “Tell don’t ask” takie jak np.
def show_awesome_message?
if model1.present? && model2.sold? && model3.sth
I18n.t("awesome_message1")
elsif model2.present?
I18n.t("awesome_message2")
end
end
ale i też np parsowanie danych przez nokogirii
def parsed_informations
Nokogiri::HTML::DocumentFragment.parse(model1.informations).to_html
end
i w takim podejściu w kontrolerze przekazywałbym modele i prezentery, które bym wykorzystywał na stronie.
Tu też znalazłem podejście, w którym przypisanie modeli zawiera się w prezenterze: https://kpumuk.info/ruby-on-rails/simplifying-your-ruby-on-rails-code/
Ale nie wiem czy prezenter powinien być za to odpowiedzialny i czy w przypadku, gdy korzystałbym na widoku z wielu modelii nie lepiej użyc Fasady i tam dodać te przypisania.
I pytanie główne jest takie, czy nie mieszam w tym momencie design patternów i jakie powinno być właściwe podejście do tego tematu
To akurat legacy code, ale ogólnie myślałem podoba mi się podejście z trailblazera
Zgadzam sie, ale z drugiej strony w aplikacji sa już dekoratory oparte o drapera
Nie nie jest to CMS, jakby treści zależały od usera, to chyba dodałbym jakiegoś visitora
Problem mam taki, że jest widok, na którym mam zbyt dużo logikii i zalezności pomiędzy różnymi modelami. Chciałem przenieść tą logikę w inne miejsce ,żeby “nie zalegała” na widokach, są to widoki railsowe w app/views i np. na widoku miałem takie warunki podobne do:
if model1.present? && model2.sold? && model3.sth || model4.visited?
I18n.t("awesome_message1")
elsif model2.present?
I18n.t("awesome_message2")
elsif
I18n.t("awesome_message3")
end
end
i np. warunkowe wyświetlanie treści,zależne od ram czasowych omiędzy dniem dzisiejszym, a np datą utworzenia, modyfikacji itp i typu uzytkownika - to akurat przeniosłem do Policy Objectu. Te warunki nie pasują mi do helperów ani już tym bardziej do decoratora, dlatego pomyślałem, żeby utworzyć prezenter i tu własnie, nie chce tworzyć prezentera do konkretnego modelu, tylko do konkretnego widoku, ze względu na zależność od więcej niż jednego modelu i tego,że na jednej stronie np.awesome_message może różnić się od warunków na jej wyświetlanie na innym widoku ( tylko uproszczony przykład na szybko ). Z drugiej strony nie chcę sie przez refactor zapędzić i stworzyć jakąś hydrę
Aktualne podejście daje mi swobodę użycia, większa część logikii znikneła z widoków
Tu jest problem właśnie, bo tego jeszcze nie wiem, a nie chce, żeby zabolało w przyszłości
Nie zamierzam refaktoryzować wszystkich widoków i wydaje mi się, że dodanie prezentera nie zaburzy spójności pomiędzy tym co już jest w aplikacji i jest to według mnie szybsze do ogarnięcia niz cells. Cells byłyby według mnie fajnym rozwiązaniem gdyby były użyte w całym projekcie, a nie w 2-3 widokach i mam wrazenie, że stworzenie prezentera jest szybsze i w sumie nawet bardziej mi się podoba ten pattern niż cellsy
Takie podejście odrzuciłem, ze względu na to, że uzywam na widokach więcej niż jednego modelu i niechciałem dekorować wszystkich modelii, których uzywam na widoku. dodałem prezenter, który bardziej skupia się na konkretnym widoku bez żadnych gemów, przekazuje do niego obiekt, które chcę uzyć na widoku, do atrybutów modelii odnoszę się poprzez “delegate to” i dodaję w nim metody odpowiedzialnę za logike. W aplikacji też mam dekoratory i tam używam drapera, nie chciałem trzymać części prezentacyjnej w decoratorze, też zastanawiałem sie czy nie uzyć do tego drapera, ale nie podoba mi się to że w takim podejściu delegowane są wszystkie atrybuty modelu
czyli każdy 
ile swobody Ci daje?
jak mocno wiąże ręce? <- mix patternów
klient pozwoli 
Nie przejmujesz się problemami o których jeszcze nie wiesz 
, zobaczymy w praktyce jak to wyjdzie
.