![]() ![]() |
Post
#1
|
|
|
Grupa: Zarejestrowani Postów: 63 Pomógł: 0 Dołączył: 20.08.2008 Skąd: Gliwice Ostrzeżenie: (0%)
|
Witam
Jestem przez rozpoczęciem większego projektu i nie do końca jeszcze zdecydowałem się na to jak rozplanować strukturę aplikacji. Do tej pory w Zendzie nie używałem modułów jednak uznałem że przyszedł czas na zaprzęgnięcie ich do pracy. Nie pytam tutaj o samo użycie/kod i tego typu rzeczy tylko o czysto teoretyczne porady. Zakładając że projekt wygląda tak:
Jako że ponoć lepiej jest nie robić domyślnego modułu i trzymać go jakby luzem to też tak postanowiłem zrobić. Teraz pytanie czy w tym domyślnym module trzymać samą aplikacje a w czymś co roboczo nazywa się Moduł1 dać rejestracje, pomoc, kontakt, FAQ i tego typu rzeczy które jako tako nie mają powiązania z aplikacją czy może na odwrót a może jest to bez znaczenia? Chyba że metoda z trzymaniem domyślnego modułu luzem nie jest jednak dobrym pomysłem? Zależałoby mi na tym by w przyszłości łatwo można zaimplementować coś w rodzaju "kanału beta". Zostaje też kwestia odnośników, jeszcze nie doszedłem do tego czy da się używać jednego modułu jak user jest zalogowany a innego jak nie bez zmian w adresie, pewnie tak a przynajmniej mam taką nadzieje. Co do samych modułów w ZF, słyszałem głosy że są niezastąpione i genialne oraz inne że są kompletnie niedopracowane i wstawione na siłę. Sam zdania nie mam bo jak pisałem nie maiłem z nimi styczności a w necie mało jest o nich informacji. Z tego co wiem to jest problem z uruchamianiem bootstrapów a właściwie z odpalaniem wszystkich na raz. Jak ma się to do wydajności i bezpieczeństwa bo fakt że ktoś włączy sobie FAQ a do tego celu trzeba odpalić pluginy, nawigację, tłumaczenie, połączenia z bazą i cały szereg innych rzeczy z modułu aplikacji wydaje mi się dziwny. To samo tyczy się plików językowych i layoutów, lepiej mieć to w jednym miejscu pod application czy dla każdego modułu osobne? System nie jest może strasznie rozbudowany ale baza danych mimo wszystko ma trochę tabel i teraz kolejne pytanie. Lepiej zastosować dwie bazy, jedna pod czysto aplikacyjne zastosowania czyli baza userów, projektów itp. a druga pod informacje, faq i inne "publiczne" rzeczy. Wiem że pytanie jest dosyć ogólne i bardzo mało tam konkretów ale tak to bywa jak ma się na kartce jedynie bazę, listę funkcjonalności i zamysł. Ten post edytował agmakonts 22.12.2010, 21:23:48 |
|
|
|
Post
#2
|
|
|
Grupa: Moderatorzy Postów: 2 921 Pomógł: 269 Dołączył: 11.08.2005 Skąd: 127.0.0.1 |
Cytat Jako że ponoć lepiej jest nie robić domyślnego modułu i trzymać go jakby luzem to też tak postanowiłem zrobić. Też tak robię i nie ma w tym nic złego. To, czy tworzy się moduł default zależy tylko i wyłącznie od programisty i nie ma żadnego wpływu na działanie aplikacji.Cytat Teraz pytanie czy w tym domyślnym module trzymać samą aplikacje a w czymś co roboczo nazywa się Moduł1 dać rejestracje, pomoc, kontakt, FAQ i tego typu rzeczy które jako tako nie mają powiązania z aplikacją czy może na odwrót a może jest to bez znaczenia? Chyba że metoda z trzymaniem domyślnego modułu luzem nie jest jednak dobrym pomysłem? Traktuj moduły jak osobne aplikacje, które wyjęte z projektu i uruchomione osobno, będą działać bez konieczności większego w nich grzebania. Innymi słowy, modułem może być blog/forum/sklep/itd. Jako osobny moduł możesz również potraktować system logowania i rejestracji.Cytat Zależałoby mi na tym by w przyszłości łatwo można zaimplementować coś w rodzaju "kanału beta". Możesz dokładniej to wyjaśnić?Cytat Zostaje też kwestia odnośników, jeszcze nie doszedłem do tego czy da się używać jednego modułu jak user jest zalogowany a innego jak nie bez zmian w adresie, pewnie tak a przynajmniej mam taką nadzieje. Teoretycznie się nie da. W praktyce dzięki zastosowaniu "magii" w postaci metod _forward i/lub pluginów, da się to osiągnąć. Na upartego można również wpakować do każdej akcji/metody init (lub stworzyć plugin albo action helper) wpakować ifa, który w zależności od tego, czy jesteś zalogowany, czy nie, podmieni layout i skorzysta z innych klas. Nie wiem jednak czy jest sens się z tym grzebać. Dla kilku akcji można takie coś zrobić, na większą skalę zapanuje bałagan w kodzie.Cytat Co do samych modułów w ZF, słyszałem głosy że są niezastąpione i genialne oraz inne że są kompletnie niedopracowane i wstawione na siłę. Sam zdania nie mam bo jak pisałem nie maiłem z nimi styczności a w necie mało jest o nich informacji. Z tego co wiem to jest problem z uruchamianiem bootstrapów a właściwie z odpalaniem wszystkich na raz. Jak ma się to do wydajności i bezpieczeństwa bo fakt że ktoś włączy sobie FAQ a do tego celu trzeba odpalić pluginy, nawigację, tłumaczenie, połączenia z bazą i cały szereg innych rzeczy z modułu aplikacji wydaje mi się dziwny. Moje doświadczenia z modułami pokazują, że są niedopracowane i wpakowane do frameworka na siłę. Podobnie zresztą wypowiadają się twórcy frameworka. Jakiś czas temu napisałem kilka rad dla ludzi, chcących korzystać z modułów w ZF - Moduły w Zend Framework.Cytat To samo tyczy się plików językowych i layoutów, lepiej mieć to w jednym miejscu pod application czy dla każdego modułu osobne? Najlepiej trzymać wszystko we właściwych modułach - łatwiej będzie przenosić moduły do innych aplikacji. O ile w przypadku layoutów nie stanowi to żadnego problemu, tak pliki językowe mogą już rodzić pewne problemy.Cytat System nie jest może strasznie rozbudowany ale baza danych mimo wszystko ma trochę tabel i teraz kolejne pytanie. Lepiej zastosować dwie bazy, jedna pod czysto aplikacyjne zastosowania czyli baza userów, projektów itp. a druga pod informacje, faq i inne "publiczne" rzeczy. Jedna baza i tylko jedna. Dwie bazy oznaczają, że będzie musiał tworzyć dwa połączenia - marnowanie zasobów. Dwie bazy - nie będziesz miał możliwości łączenia tabel. Jak chcesz odseparować od siebie tabele zastanów się nad Postgresem, który posiada takie coś jak schematy, które można w bardzo fajny sposób powiązać z modułami w aplikacji.Cytat Wiem że pytanie jest dosyć ogólne i bardzo mało tam konkretów ale tak to bywa jak ma się na kartce jedynie bazę, listę funkcjonalności i zamysł. Każda podróż zaczyna się od pierwszego kroku (IMG:style_emoticons/default/smile.gif) |
|
|
|
Post
#3
|
|
|
Grupa: Zarejestrowani Postów: 63 Pomógł: 0 Dołączył: 20.08.2008 Skąd: Gliwice Ostrzeżenie: (0%)
|
Dzięki za odpowiedź (IMG:style_emoticons/default/smile.gif)
Co do "kanału beta" to trochę mnie dobił punkt o adresach w modułach i problemach z przekierowywaniami w zależności od stanu logowania. Chodziło mi o coś w stylu wersji dla wybranych użytkowników z różnymi funkcjonalnościami jeszcze w stadium beta. Wyobrażałem sobie to jako osobny moduł a w nim praktycznie te same pliki co w głównym tylko w nowszych wersjach, połączenie z tą samą bazą itp. Zamysł był taki by w zależności o jakieś magicznej kolumny w bazie typu 'rodzaj_konta' uruchamiać aplikacje w wersji publicznej lub beta. Pomyślałem że będzie to wygodne rozwiązanie zwłaszcza do testowania jako że miałoby działać z żywymi istotami i na dosyć bogatej bazie. No ale chyba jednak zrezygnuję, przynajmniej na razie z tego pomysłu. Co do porad dotyczących modułów to często do Ciebie zaglądam a głównie ten post moje wątpliwości wzbudził (IMG:style_emoticons/default/smile.gif) Jeśli chodzi o bazę to nawet myślałem nad Postgresem, zainstalowałem na localu, nawet zacząłem szukać czegoś w stylu MySql workbench i wtedy dostałem kubeł zimnej wody od człowieka zajmującego się serwerową częścią przedsięwzięcia że "będzie MySql i ch....." więc nie ma tak dobrze (IMG:style_emoticons/default/smile.gif) Dziś czytając testy wydajności Zend_Translate zostałem mocno zaniepokojony. Tłumaczenie za pomocą gettext jest jakieś 7 razy wolniejsze od arraya. Wiadomo że robienie tłumaczenia, które pewnie zajmie kilka tysięcy elementów w kilku językach z czego spora część nie będzie za bardzo mogła lecieć do cache, za pomocą tablic nie będzie wygodne ale czy chwilowo bez hi-endowego serwera oparcie tego o gettext nie będzie lekko samobójcze? Macie jakieś doświadczenia z tłumaczeniem w Zendzie i jego wydajnością? |
|
|
|
Post
#4
|
|
|
Grupa: Moderatorzy Postów: 2 921 Pomógł: 269 Dołączył: 11.08.2005 Skąd: 127.0.0.1 |
Cytat Co do "kanału beta" to trochę mnie dobił punkt o adresach w modułach i problemach z przekierowywaniami w zależności od stanu logowania. Chodziło mi o coś w stylu wersji dla wybranych użytkowników z różnymi funkcjonalnościami jeszcze w stadium beta. Wyobrażałem sobie to jako osobny moduł a w nim praktycznie te same pliki co w głównym tylko w nowszych wersjach, połączenie z tą samą bazą itp. Zamysł był taki by w zależności o jakieś magicznej kolumny w bazie typu 'rodzaj_konta' uruchamiać aplikacje w wersji publicznej lub beta. Pomyślałem że będzie to wygodne rozwiązanie zwłaszcza do testowania jako że miałoby działać z żywymi istotami i na dosyć bogatej bazie. No ale chyba jednak zrezygnuję, przynajmniej na razie z tego pomysłu. Takie coś możesz rozwiązać na poziomie helpera widoku. W zależności od uprawnień (sprawdzanych w helperze), renderujesz inny plik widoku. Wada takiego rozwiązania - im więcej takich helperów, tym większy problem z późniejszym ich zarządzaniem.Cytat Dziś czytając testy wydajności Zend_Translate zostałem mocno zaniepokojony. Tłumaczenie za pomocą gettext jest jakieś 7 razy wolniejsze od arraya. Wiadomo że robienie tłumaczenia, które pewnie zajmie kilka tysięcy elementów w kilku językach z czego spora część nie będzie za bardzo mogła lecieć do cache, za pomocą tablic nie będzie wygodne ale czy chwilowo bez hi-endowego serwera oparcie tego o gettext nie będzie lekko samobójcze? Macie jakieś doświadczenia z tłumaczeniem w Zendzie i jego wydajnością? Czytałem testy wydajnościowe i gettext rzeczywiście słabo w nich wypada, ale jeśli zastosujesz cache, wówczas jest najszybszy. Musiałbyś przeprowadzić własne testy dla odpowiedniej ilości danych. |
|
|
|
Post
#5
|
|
|
Grupa: Zarejestrowani Postów: 63 Pomógł: 0 Dołączył: 20.08.2008 Skąd: Gliwice Ostrzeżenie: (0%)
|
Helpery mnie nie urządzają za bardzo bo raczej chodziło tu o dodatkową funkcjonalność w kontrolerach i modelach ale wpadłem na pomysł z ustawianiem modułów w bootstrapie i sterowanie domyślnym modułem tam ładując wcześniej info na temat usera, zobaczymy co z tego wyjdzie, w najgorszym wypadku będzie beta.domena.pl ;]
|
|
|
|
![]() ![]() |
|
Aktualny czas: 20.12.2025 - 20:13 |