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:

[XML] pobierz, plaintext 
-application
--configs
--lang
--controllers
--models
--views
--modules
----Moduł1
------controllers
------models
------views
[XML] pobierz, plaintext 

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ł.

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.

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.

Możesz dokładniej to wyjaśnić?

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.

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.

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.

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.

Każda podróż zaczyna się od pierwszego kroku

Dzięki za odpowiedź

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ł

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

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ą?

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.

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.

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 ;]