пропозиції роботи
Wypowiedzi
-
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. :) -
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? -
Dla inspiracji:
http://www.slideshare.net/shahar/best-practices-inphpa...
W skrócie prezentacja do automatycznych wrzutek wymienia:
rsync, svn, pear/phing albo wlaśnie capistrano.
Ja używam tam gdzie się da svn + skrypty,
bo jest proste, a wygodniejsze niż ftp/rsync.
Reszta sposobów jest bardziej skomplikowana i sądzę, że opłaca się pisać taki deployment tylko, gdy projekt jest bardzo często aktualizowany.
Inne prezentacje:
http://www.slideshare.net/search/slideshow?q=php+deplo... -
Obiekt sfWebRequest nie posiada metody hasFiles(), stąd cały problem ;)
Można to sobie sprawdzić tu:
http://www.symfony-project.org/api/1_4/sfWebRequest
(jeśli nie używasz autouzupełniania, to Twój jedyny ratunek,
ale polecam korzystać z IDE z autouzupełnianiem)
Metoda sfWebRequest::hasFiles() była w wersjach 1.0 i 1.1, potem zniknęła.
Zmiany między 1.2 i 1.4 nie są znaczne (z moich doświadczeń praktycznie każdy plugin czy snippet z neta pod 1.2 chodził mi pod 1.4), ale z wcześniejszymi wersjami bywa różnie.
Jeśli książka omawia wersje przed 1.2, lepiej chyba będzie odłożyć książkę i zrobić sobie nieśmiertelnego Jobeeta :)
http://www.symfony-project.org/jobeet/1_4/Doctrine/en/
to tylko 23 lekcje, a na pewno wyjdziesz lekko poza podstawy, nie nauczysz się złych nawyków i nie będziesz musiał rozkmilać błędów autorów czy przedawnionego kodu...
Z polskich książek o sf niestety nie polecam żadnej. Najlepsza jest Symfony w przykładach, Gajda zrobił kawał dobrej roboty, ale to niestety Propel :( -
Nie, nic nie zmienialem.
Probowalem to na lokalu, hostingu i dedyku oraz pod wszystkimi popularniejszymi przegladarkami (firefox, ie, opera, chrome), wszedzie bylo tak samo, wiec wydaje mi sie, ze problem tkwi gdzies w symfony, a nie na zewnatrz.
Co ciekawe, bardzo trudno znalezc cos na ten temat na necie w ogole.
Udalo mi sie natrafic tylko na jeden watek na forum symfony, gdzie wlasnie radzono dodac Cache-Control do view.yml.
Musze jeszcze sprawdzic, jak sprawa sie ma przy korzystaniu z sfGuard... -
Niestety nie.
Jak zrobisz sobie logowanie w czystym PHP zapisujac i czyszczac pole np. w $_SESSION['access'], to po wylogowaniu i kliknieciu BACK strona przeladowuje sie i odpowiedni warunek moze przekierowac z powrotem na formularz.
W Symfony niestety domyslnie nie przeladowuje tylko laduje z cache'a i warunek sie nie wykonuje.
Potwierdza to zreszta fakt, ze po dodaniu tego nieszczesnego Cache-Control wszystko jest juz ok. -
Jakis czas temu rozpoczalem swoja przygode z Symfony i sytuacja, ktora zdziwila mnie zaraz po wykonaniu prostego modulu logowania.
Mianowicie po wylogowaniu (
$this->clearCredentials();
$this->setAuthenticated(false);
//a nawet wyczyszczeniu calej sesji
$this->getAttributeHolder()->clear();
)
i kliknieciu przycisku wstecz przegladarki, serwowana jest z powrotem chroniona zawartosc z pamieci podrecznej przegladarki. Dopiero kolejne klikniecie wewnatrz strony, ktorej nie powinnismy juz widziec (!), wykonuje redirecta na panel logowania, ktory umieszczony jest w kodzie.
Podejrzewajac problem z cache-control, ustawilem w pliku view.yml
http_metas:
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
co wyeliminowalo problem, ale wstawilo mi w/w znacznik do kodu html
moje dwa pytania:
- czy wiecie moze co symfony kombinuje z tymi headersami (z podobnym problemem bez uzycia sf sie nie spotkalem, w logach debugToolbar nie widac tez zeby byly wysylane jakies dodatkowe headers)?
- jak mozna zapobiec temu w inny sposob (bez modyfikacji view.yml, a bardziej na poziomie kodu, zeby nie stosowac znacznika <meta http-equiv="Cache-Control" .../>) ?
Dołącz do GoldenLine
Oferty pracy
Sprawdź aktualne oferty pracy
Aplikuj w łatwy sposób
Aplikuj jednym kliknięciem
