Temat: współdzielenie kodu akcji (kontrolerów) pomiędzy sf apps

Jakie macie pomysły na współdzielenie kodu akcji (kontrolerów) pomiędzy aplikacjami?

Mamy np. klasę akcji do pobierania plików (download).
Są tam metody do wyświetlania listy plików, wysłania pliku strumieniem itp.
Metody oczywiście są krótkie, bo odwołują się wyłącznie do modelu,
jednak mając frontend i backend i chcąc udostępnić funkcjonalności po obu stronach,
jesteśmy zmuszeni skopiować katalog z modułem download do obu aplikacji
(kod jest identyczny, potrzebuję po prostu mieć możliwość wywołania zarówno frontend.php/download, jak i backend.php/download).
Jest to oczywiście b brzydkie rozwiązanie, bo duplikujemy kod (złamane DRY ;)) i narażamy się na zmiany w dwóch miejscach jednocześnie.

To, co sobie wymyśliłem na szybko, to wydzielenie osobnej klasy w lib i zebranie w niej wspólnych metod akcji.
Metody z kontrolerów pozostają, jednak delegują wywołania do nowoutworzonej klasy. Eliminujemy duplikację kodu funkcjonalnego.
Rozwiązanie to jednak nie do końca mi się podoba:
1) jesteśmy zmuszeni przekazywać ciągle kilka parametrów (zwykle minimum to sfWebRequest i sfUser)
2) łamiemy architekturę, bo tak naprawdę tworzymy kontroler w lib...

Czy ktoś z Was ma na to jakiś sprytniejszy sposób i chciałby się podzielić ? :)

Tak teraz podczas pisania przyszło mi na myśl,
chyba lepszym rozwiązaniem jest zmiana dziedziczenia z własnej metody akcji (zamiast sfActions) niż delegacja?

Temat: współdzielenie kodu akcji (kontrolerów) pomiędzy sf apps

Zawsze możesz stworzyć własny theme do generatora i stworzyć dwa moduły, które będą generowały akcje i widoki na bazie tego theme. W ten sposób, zmieniając coś w generatorze, zmieniasz w jednym i drugim miejscu:)

Drugim sposobem jest ten, o którym napisałeś - stworzyć własną klasę akcji, np sfDownloadActions i po niej dziedziczyć akcje akurat w tych dwóch modułach:)

Temat: współdzielenie kodu akcji (kontrolerów) pomiędzy sf apps

A nie łatwiej wyodrębnić to do pluginu zamiast wymyślać koło na nowo?

Temat: współdzielenie kodu akcji (kontrolerów) pomiędzy sf apps

Też racja, jakoś o tym nie pomyślałem:D

Temat: współdzielenie kodu akcji (kontrolerów) pomiędzy sf apps

Rozwiazalem sprawe wlasna klasa akcji. Zwyciezyl pragmatyzm. Calosc trwala jakies 30 sek i smiga. Mam tez od razu miejsce do nadpisania/dodawania metod.
Zarowno plugin, jak i nadpisanie generatora w tak krotkim czasie nie byloby mozliwe. ;)
(tak czy owak, z tym generatorem to bardzo dobry motyw, ostatnio pisalem np. generator modulow internalizowanych, polecam eksperymenty :))

Tez pomyslalem o pluginie, ale w tym przypadku chyba sie nie nadaje.
Po pierwsze, moj download w modelu laczy sie z tabelami uzywanymi w konkretnym projekcie, a ich nie moge wrzucic do pluginu.
Poza tym, gdyby przyszlo do nadpisania kodu (co przychodzi zawsze nadspodziewanie szybko) i tak skonczylbym w libie.. ;)
Pluginy imho sa najlepsze dla hermetycznych funkcjonalnosci i jako wrappery na klasy zewnetrzne.

Dzięki za pomysły. :)

Temat: współdzielenie kodu akcji (kontrolerów) pomiędzy sf apps

Tak sobie teraz pomyślałem, że jeżeli będzie Ci to potrzebne również w innych projektach i zawsze będzie występowała różnica w modelu, to imho chyba najlepszy sposób (patrząc przyszłościowo) jest zrobienie tego theme do generatora - w yamlu będziesz sobie mógł poustawiać wszystko, co jest bezpośrednio związane z modelem - od pól tabel, które mają być brane pod uwagę, po zapytanie generujące wyniki.
Może i to jest wymyślanie koła na nowo, ale ja ostatnio jakoś dużo siedzę w generatorach i już na wszystko, co musi być użyte więcej niż raz patrzę przez pryzmat generatorów:D wiem, wiem, zboczenie takie :D