Witam
Ciekawi mnie jakie Wy macie rozwiązania na modele w aplikacjach z modułami.
Kiedy ustawimy sobie moduły, autoloader automatycznie nam dopisuje ścieżkę do modeli "zbiorczych", które są w katalogu głównym aplikacji, a teraz co z modelami, które mają być dedykowane dla danego modułu?
Czyli jak wywołać model, który będzie np. w katalogu:

Tam autoloader sam już nie wejdzie, trzeba sobie radzić. Niektórzy robią to dodając include_paths do każdego modułu, inni piszą plugin, który dodaje include_path oddzielnie dla każdego modułu, np:

[PHP] pobierz, plaintext 
     public function dispatchLoopStartup(Zend_Controller_Request_Abstract $req)
    {
            $moduleName = $req->getModuleName();
            set_include_path(get_include_path() .
            PATH_SEPARATOR . APPLICATION_PATH .  '/modules/' . $moduleName . '/models');
    }
[PHP] pobierz, plaintext 

Macie na to jakieś ciekawe rozwiązania?

1. Pierwsza rada, to zanim zaczniesz kombinować to przeczytaj dokładnie manual.
http://framework.zend.com/manual/en/zend.a...sources.modules
http://framework.zend.com/manual/en/learni....resources.html
http://framework.zend.com/manual/en/projec...filesystem.html
http://framework.zend.com/manual/en/zend.c...er.modular.html
http://framework.zend.com/manual/en/zend.a...-operation.html

2. A teraz rozwiązanie:
W pliku konfiguracyjnym aplikacji "application/configs/application.ini" dodaj wpis:

Taki wpis spowoduje wywołanie klas Bootstrap dla poszczególnych modułów (jeśli takie klasy istnieją).

Następnie w każdym katalogu modułu stwórz plik Bootstrap.php, w który zdefiniuj klasę o nazwię Nazwamodułu_Bootstrap
Np. dla modułu default:

[PHP] pobierz, plaintext 
<?php
class Default_Bootstrap extends Zend_Application_Module_Bootstrap {
 
}
[PHP] pobierz, plaintext 

Dla modułu admin:

[PHP] pobierz, plaintext 
<?php
class Admin_Bootstrap extends Zend_Application_Module_Bootstrap {
 
}
[PHP] pobierz, plaintext 

Ta klasa niejawnie (bo tego nie widać), zarejestruje przestrzenie nazw dla modułów w których znajduje się Bootstrap.php. Domyślna przestrzeń nazw to.
Model dla katalogu models, Form dla katalogu forms, Plugin dla katalogu plugins, Service dla katalogu services.


Przykład (moduł default)
application/modules/default/controllers
application/modules/default/models
application/modules/default/forms
application/modules/default/plugins
application/modules/default/services

model definiujesz jako klasę Default_Model_Table w pliku application/modules/default/models/Table.php

reszta analogicznie


Proste nie? Wystarczy poczytać

A tak przy okazji. Zacząłem tworzyć samouczek dla chętnych poznania Zend Frameworka.
Projekt zamieściłem na http://code.google.com/p/zf-samouczek/ do pobrania przez svn.
Generalnie jest to działająca aplikacji na Zend Framework'u, z obfitymi komentarzami i odsyłaczami do manuala dla opornych

Nie chodzi mi o bootstrap dla kazdego modulu, bo akurat bootstrap potrzebny mi jest tylko jeden
Domyslne przestrzenie nazw to nie:

tylko:

W przypadku jednego bootstrapa

Przeczytałem wszystkie te manuale zanim napisałem tu posta
Nigdzie nie ma tego problemu opisanego. Kiedy mam model w katalogu z modułem, nie idzie go załadować bez dodatkowych zabiegów (wcześniej wspomniany plugin).

Podsumuje:
Mam jednego bootstrapa, bo więcej mi nie potrzeba
Struktura katalogów, dla przykładowego modułu przedstawia się tak:
application/module/default/
application/module/default/controllers
application/module/default/models
application/module/default/views
application/models - zbiorcze modele
application/Bootstrap.php

I teraz tak, zbiorcze modele w katalogu application/models autoloader wczytuje bez problemu, ale tych w module, już nie: application/module/default/models...
i interesują mnie rozwiązania na ten problem


chodzi Ci o to, ze kazdy bootstrap te przestrzenie doda? Wiec tez to jakies rozwiazanie, ale po co mi x Bootstrap`ow, kiedy sa zbedne? Mam wszedzie kopiowac ? Dziedziczyc? To rozwiazanie w niektorych przypadkach moze byc dobre, ale ja chce jeden

Mówiąc domyślna przestrzeń, miałem na myśli podstawową konwencję nazewnictwa oraz listę zasobów jakie zostaną zarejestrowane. Bo korzystając z Autoloader'a mogę zarejestrować swoje własne i/lub zmodyfikować istniejące przestrzenie.

Domyślna przestrzeń aplikacji pozostanie czyli dla modeli: Application_Model_Tabela, Application_Form_Formularz itd.
A każdy z tych bootstrapów zarejestruje swoją przestrzeń nie kolidującą z przestrzenią dla Aplikacji (o której mówisz).
Główny bootstrap w katalogu application zostaje jak był. Definiujesz tylko dodatkowe bootstrapy dla modułów. Zaletą
takiego rozwiązania jest dobry podział logiki aplikacji. Załóżmy że masz moduł users, który odpowiada za autoryzacje, prawa dostępu, zarządzanie użytkownikami.
Napewno w swojej aplikacji używasz praw dostępu i rejestrujesz jakiś plugin wykorzystujący Zend_Acl i domyślam się że umieściłeś dodatkowy folder w katalogu library. Logicznie rzecz biorąc ten plugin powinien się znajdować w module users, i z tamtąd go powinieneś zarejestrować używając właśnie bootstrapa modułu users. Bo gdy usuniesz ten moduł (wyłączysz), to automatycznie wyłączysz sprawdzanie praw dostępów - bo po usunięciu tego modułu nie będzie co sprawdzać - użytkowników przecież nie będzie.

Mam nadzieje że rozumiesz idee

jesli chodzi o kontrole dostepu to mam swoj plugin i zalaczam go zawsze, a on juz wie czy i jak dzialac no i jako ze to plugin, jest w folderze app/plugins
z tego wzgledu wystarczy mi jeden bootstrap
Faktycznie mozna sobie dobrze logicznie aplikacje podzielic, ale jesli mam konfiguracje w bootstrapie, ktora ma byc na calej aplikacji, bez sensu jest to kopiowac do kazdego bootstrapa w module prawda?!
A problem stanie sie jeszcze wiekszy, kiedy bede tworzyl (co mi sie zdarza) takie pod moduly, czyli:
app/modules/katalog/submodul... itd
to przy takich np 20 modulach, bezsensu jest robic 20 pustych, lub nie daj boze skopiowanych bootstrapow

i zeby nie bylo, nie twierdze ze nie skorzystam z takiego rozwiazania, bardzo mi sie podoba, tylko trzeba wiedziec wszystko dlatego dalej mnie interesuje rozwiazanie dla jednego bootstrapa

Nie musisz kopiować zawartości innych bootstrapów, są to dodatkowe bootstrapy z możliwością rejestracji specyficznych zasobów dla danego modułu. Dodatkowo możesz z głównego bootstrapa, dostać się do instancji obiektów tych klas. Zarejestrowany element plugin etc. jest widziany w całej aplikacji tak jakbyś rejestrował go w tym głównym bootstrapie. No i przede wszystkim z automatu rejestrują Ci przestrzeń nazw i możesz mieć oddzielne modele w poszczególnych modułach, te modele mogą też dziedziczyć po modelach wspólnych dla aplikacji (tzn. z application/models). Zarejestrowane przestrzenie widoczne są w całej aplikacji czyli we wszystkich modułach. Czyli będąc w kontrolerze modułu np. admin możesz wywołać model z modułu np. users. Nie wiem czemu nie przekonuje Cię to rozwiązanie, przecież 20 pustych plików Bootstrap.php to nic złego, a czasami może je wykorzystasz do rejestracji jakiegoś zasobu na potrzeby danego modułu.


No dobra ale wracając do problemu, to przede wszystkim zrób to dobrze. Plugin to także złe miejsce do tego, bo przecież plugin uruchamiany jest po rozruchu aplikacji (po wykonaniu procesów bootstrapa) Nie dodawaj tego do include_path bo to nie twoja działka, takie sprawy zostaw Frameworkow'i. W Zend Framework jest od takich spraw Zend_Loader a w twoim przypadku jest specjalna klasa do tego Zend_Application_Module_Autoloader.

A więc rozwiązaniem twojego problemu będzie taki o to główny Bootstrap.

[PHP] pobierz, plaintext 
<?php
 
class Bootstrap extends Zend_Application_Bootstrap_Bootstrap 
{
    /**
     * Inicjowanie przestrzeni nazw dla wszystkich modułów
     * 
     * @return void
     */
    protected function _initModulesNamespace()
    {        
 
        $modulesDir = APPLICATION_PATH . DIRECTORY_SEPARATOR . 'modules';
 
        if(file_exists($modulesDir) && is_dir($modulesDir)) {
            // Zawartosc katalogu
            $modules = scandir($modulesDir);
 
            // Usuwamy dwa pierwsze elementy, ponieważ to katalog nadrzędny i bierzący
            $modules = array_slice($modules,2);
            foreach($modules as $file) {
                // Sprawdzamy czy plik jest katalogiem i czy nie zaczyna się od "." np: .svn
                if(is_dir($modulesDir . DIRECTORY_SEPARATOR . $file) && substr($file, 0, 1) != '.') {
                    // Rejestrujemy przestrzenie
                    $autoloader = new Zend_Application_Module_Autoloader(array(
                        'namespace' => ucfirst(strtolower($file)),
                        'basePath' => $modulesDir. DIRECTORY_SEPARATOR . $file,
                        // Rejestrujemy przestrzeń dla modeli
                        'model' => array ('path' => 'models/', 'namespace' => 'Model'),
 
                        // ... nie wiem może zechcesz zarejestrować też Formularze
                        'form' => array ('path' => 'forms/', 'namespace' => 'Form')
                        // .. itd...
                    ));       
                }
            }
 
        }
    }
}
[PHP] pobierz, plaintext 

pisałem z palca więc może coś trzeba poprawić. Ale generalnie powinno latać

W tym kodzie który napisałeś, wczytuję wszystkie moduły, ale po co? Można to zrobić w ten sposób co Ty, ale wykorzystując plugin i dodając namespace tylko dla jednego modułu, wtedy faktycznie obędzie się bez includepath.

Jeśli chodzi o bootstrapy dodatkowe, no to już mi się bardziej podoba, skoro bootstrap główny jest zawsze używany. Chociaż dalej mam zastrzeżenia co do pustych bootstrapów, w końcu to zawsze dodatkowy plik, a pusty.


To mnie ciekawi, jak wszystkie przestrzenie są rejestrowane? Czyli odpalają się jednocześnie wszystkie bootstrapy? A nawet jak nie, to tworzą się namespace`y dla każdego modułu? Dziwna sprawa i chyba mało optymalna ;/
Nie chcę mieć dostępu do modelu w module admin, z modułu np user, bo to bez sensu. Od tego mam modele zbiorcze, a te w modułach mają być tylko i wyłącznie dla danego modułu

Tylko że teraz zaczyna się seria bezsensownych pytań z mojej strony, więc najpierw postawie aplikację z bootstrapem na każdy moduł i zapoznam się dokładnie z działaniem, wtedy tu wrócę póki co dzięki za pomoc

No dobra, aplikacja uruchomiona z przykładowymi dwoma modułami i jest kiepsko... faktycznie dwa bootstrapy są za każdym razem wczytywane, za każdym razem są tworzone dodatkowe namespace`y, coś z tym trzeba by zrobić, bo to przesada, żebym za każdym razem miał 20 bootstrapów, dla każdego po tam chyba 6namespaceów, robi się kombajn Mi się to za bardzo nie podoba, zobaczymy jeszcze testy różnych rozwiązań przy 20 modułach

---------------------------------------
Trzeba by zrobić testy porządne, na razie mierząc jedynie czas wykonywania skryptu, rozwiązanie z wieloma bootstrapami przy 20 modułach, wydłuża ładowanie strony o jedną dziesiątą w porównaniu z dodaniem namespace`ów dla jednego, aktualnie potrzebnego modułu z wykorzystaniem pluginu, więc może i różnica niewielka, ale kiedy zależy na optymalizacji... Po co ładować tyle plików? Tworzyć tyle namespace`ów?? Tworząc namespace domyślam się że autoloader dodaje to sam do includepath, wtedy każdy załączony plik jest szukany we wszystkich namespejsach ;/ czyli w miarę rozbudowy aplikacji, ta 1/10 czasu wcale już nie będzie taka mała, a jeśli się mylę, to będę wdzięczny za sprowadzenie na ziemię

... szczerze to sam Zend Framework jest mało optymalny, nie wiem czy przeglądałeś kod, ale jest duża nadmiarowość kodu. Coś za coś, funkcjonaloność i wygoda programowania kosztem wydajności ... i umówmy się, myślisz że to że odpala nam wszystkie bootstrapy to znacząco wpłynie na szybkość aplikacji? Biorąc pod uwagę pozostałe procesy jakie zachodzą w framework'u zapewniam Cię że ta różnica nie jest znacząca. Zresztą sam się możesz przekonać. Zrób testy za pomocą Apache Benchmark bez bootstrapa w modułach i z, porównaj wyniki i będziesz miał odpowiedź.

Co do odpalania wszystkich bootstrapów, to tak w momencie startu aplikacji wywołuje ona wszystkie boostrapy w modułach, wtedy jeśli w pliku application.ini dyrektywa resources.modules[] = będzie pusta. Alternatywnie możesz podać tylko wybrane moduły. To zrozumiałe, że odpalane są wszystkie bootstrapy (o ile nie ograniczyliśmy tego w pliku ini), bo skoro np. chcemy zarejestrować plugin do sprawdzenia uprawnień użytkowników, który znajduje się w module users to gdyby bootstrap nie wywołał wszystkich bootstrapów modułów to nasz plugin by się nie zarejestrował, gdyby był wywołany inny moduł niż users.
Możesz oczywiście powiedzieć, po jakiego grzyba chce plugin do sprawdzania uprawnień rejestrować w boostrapie danego modułu zamiast w głównym bootstrapie. A no po to że tak podzieliłem moją aplikację a moduły są po to żeby kod od siebie izolować w maksymalnym stopniu. To daje mi większość elastyczność i po wyłączeniu takiego modułu nie boje się, że aplikacja przestanie mi działać. Bo np role zdefiniowałem sobie jako stałe w klasie modelu w module users.
Gdybym wyłączył ten moduł z aplikacji a plugin do sprawdzenia uprawnień byłby rejestrowany w głównym bootstrapie to dostałbym błędy bo plugin próbowałby wywołać stałe z klasy modelu w module users, który przecież wyłączyłem (stałych używam do definiowania ról użytkowników).

Przestrzenie są widoczne w całej aplikacji, z prostej przyczyny - framework nie sprawdza skąd są wywołane bo to nie takie proste o ile wogóle możliwe :-) a przecież jak w kodzie php zrobisz include klasy, nieważne gdzie to przecież klasy są widoczne globalnie i możesz je inicjować wszędzie - tak wynika z budowy języka php. Więc framework nie może tego ograniczyć. To że możesz wywołać klasę z innego modułu, nie znaczy że musisz to robić

Potestuj, które rozwiązanie Ci bardziej odpowiada, które jest szybsze, jak bardzo spowolni Ci aplikacje etc.. etc..

No tak podchodząc do tematu, to można faktycznie zrobić wielki czołg, zamiast sprawnej aplikacji, a z użyciem zenda jednak trzeba zwracać uwagę na takie różnice, nawet drobne, przez to co sam napisałeś. Sam zend już potrafi zwolnić, a jak jeszcze będziemy mu w tym pomagać, to na zendzie będzie można stawiać tylko blogi.
W przypadku większych aplikacji przydaje się też optymalizacja samego zenda, ale samemu trzeba wydusić jak najwięcej ze swojego kodu, zanim się zabierze za inne zabiegi.

Rozwiązanie bardzo mi się podoba, tylko trzeba coś zrobić, aby wczytywany był tylko bootstrap z aktualnie używanego modułu. Przynajmniej mi się wydaje, że to będzie lepsze rozwiązanie, bo szybsze, a czy faktycznie potrzebne Ci te wszystkie bootstrapy załadowane? I mówiąc bootstrapy, mam na myśli też includepath`y, które zend dołącza

To prawda trzeba dbać o optymalizację i wydajność kodu, ale równie ważny jest porządek w aplikacji i uniknięcie własnych tworów. Pamiętaj, że Zend Framework jest ciągle rozwijany, i programiści głowią się nad wydajnością, ale jeżeli będziesz stosował się do dokumentacji i korzystał z zenda w należyty sposób (korzystając z narzędzi jakie oferuje - bez tworzenia samoróbek np. do rejestracji modułów) to unikniesz problemów przy aktualizacji.

Co do wydajności aplikacji, to oprócz tego że starasz się programować jak najwydajniej to pomyśl też troche ja business man. Projekt to koszty, na początku projektu nie wiadomo czy coś wypali czy nie więc lepiej koszty obniżać. Na początku aplikacja nie będzie na pewno nie wiadomo jak obciążona poziom 5 request/s jest zadowalający a w ZendFrameworku taki poziom bez problemu osiągniesz. Dlatego nie ma co tracić czasu na sprawy, które nie są w tym momencie aż tak istotne. Jeśli projekt wypali i przynosi określone korzyści to wtedy inwestujesz czas w doskonalenie projektu. Ważne jest by umieć dostosować się do danej sytuacji.

No dobra, ale to jeszcze nie koniec moich pomysłów

Zend_Loader oferuje możliwość zdefiniowania własnego handler'a do ładowania klas. Działa to tak, że jeśli zend nie potrafi znaleźć klasy to w następnej kolejności wywoła zarejestrowany handler.
Napisz własny handler, zadbaj o jego wydajność przy zadowalającym poziomie uzyteczności. Może takie rozwiązanie Cię zadowoli.

Tu masz dokładny przykład jak to się robi, jest to bardzo łatwe więc nie ma sensu bym to tłumaczył.
http://framework.zend.com/manual/en/zend.l...r.load.autoload

Edit Napisany handler nie zastępuje istniejącego, tylko jest uruchamiany jak ZendFramework nie potrafił załadować klasy. Spróbuj np. rozpoznać pierwszy człon nazwy klasy do momentu wystąpienia znaku "_", sprawdź czy folder z takim modułem istnieje i spróbuj załadować klasę modelu. Tu już możesz kombinować według uznania i tego co potrzebujesz.

no też jakiś sposób z handlerem, zobaczę jak to działa
Co do Twojego nastawienia, to mnie trochę zaskakujesz:

Na wstępie... 5 requestów mnie nie interesuje, jeśli mam powyżej np. 20 pisać aplikację od nowa, to wszystkie koszta, które były wsadzone w projekt, lądują do kosza, więc gdzie tu myślenie business mana Szczególnie, że można naprawdę usprawnić projekt, bez wielkiej straty czasu (czyt. pieniędzy), trzeba tylko pomyśleć i nie kłaniać się w strone zenda, za każde rozwiązanie

Sam pracuje nad większą aplikacją już od pewnego czasu i są tam autorskie modyfikacje, takie obejścia, aby wszystko działało dobrze. Aplikacja postawiona już ponad rok temu, a zend cały czas jest uaktualniany i... uwaga: nie ma problemów! Nie przewidzimy nigdy, co może nowego pojawić się w frameworku, ale zend dba o to, aby była jako taka zgodność wsteczna. Ważne jest, aby pisać z głową, a nasze ulepszenia nie pójdą na śmietnik, podobnie jak napisana aplikacja, kiedy tych requestów już będzie więcej. Nie mówie, aby od razu brać się nie wiadomo za co, stawiać bazę na oraclu, szczypać się o każdą milisekundę, ale dziwi mnie, że nie przeraża Cię kilkadziesiąt includepath/namespace`ów i 20 plików wczytywanych całkowicie bez potrzeby ;/

Spoko te namespace'y nie lądują w w include_path, tylko odkładają się w statycznej tablicy i Zend odpowiada za to przeszukiwanie. Fakt, jeśli nie ma potrzeby to nie ma co się w to bawić. Ale ty przecież masz potrzebę. Można szukać kombinować pod warunkiem, że mamy na to czas. Nie twierdzę żeby tego nie robić, programista powinien a nawet musi zadbać o to by zrobić to jak najlepiej potrafi. Prawdziwy programista nie może spokojnie zasnąć jeśli czegoś nie zrobi dobrze i ta myśl nie daje mu spokoju.

Powiem Ci, że dla mnie wydajność to najważniejsza sprawa, przejrzałem dokładnie większość znanych framework'ów tj. Zend, Symfony, Cake, CodeIgniter, Wydajnie najlepszy był Code Igniter - niestety poziom i styl kodowania był poniżej moich oczekiwań, Symfony spodobał mi się za to, że całą aplikację robiłem z command lin'e w parę chwil a Zend mnie urzekł swoimi możliwościami konfiguracji i ilością narzędzi. Śledzę te frameworki na bieżąco i np. Symfony 2, kompletnie zmienił swoje podejście - fajnie przepisali framework'a a do tego dołączyli do biblioteki Zend'a. Swego czasu intersował mnie projekt o nazwie rapide, który był tworzony przez ludzi z tego forum - niestety umarł śmiercią naturalną. Jednak dalej żaden z dostępnych frameworków nie spełniał moich oczekiwań wydajności (poza skalowalnością bo skalowalność była rewelacyjna). Postanowiłem stworzyć własny framework, korzystając z nabytych doświadczeń szczególnie chyląc się ku Zendowi. Tak o to powstał nweb framework. Osiągnąłem wyśmietą wydajność, a funkcjonalność dostosowałem pod swoje wymagania i fanaberie Używam go do własnych projektów, zenda używam zawodowo w komercyjnych projektach - z prostej przyczyny takie wymagania stawia szef. Jak trzeba używam Symfony. Dlaczego ? To proste, stawiając na znane rozwiązanie, łatwo jest dobrać team i zastąpić kogoś kimś innym, a to w biznesie jest bardzo ważne. Aha jeśli chcesz zerknąć na moje wypociny to są dostępne na http://code.google.com/p/nweb-framework/ oczywiście jest to jeszcze nie doszlifowany projekt, ale spełnia stawiane wymagania. W budowie przypomina Zenda ;-)

a to chętnie zerknę w wolnej chwili, dzięki
Zgodzę się ze wszystkim co napisałeś ale dalej zastanawia mnie, jak zrobić, aby mieć te bootstrapy dla każdego modułu, ale wczytywać tylko ten, który jest potrzebny ;/
bo jak już pisałem wcześniej, podoba mi się to rozwiązanie, tylko po łapach zenda, że wszystkie czyta ;]

To umieść plik Booststrap.php tylko w tym jednym module, który potrzebujesz. Przez to że w innych modułach nie będzie Bootstrap'a to nie znaczy, że nie będą działać. Poprostu nie będą mieli tej dodatkowej przestrzeni nazw, poza tym nic nie wpłynie na działanie aplikacji. Działa w ten sposób, że klasa Zend_Application_Resource_Modules przeszukuje twój katalog modules i sprawdza czy plik Bootstrap istnieje. Jeżeli istnieje to wtedy go odpala. Zerknij sobie do źródła jak wygląda kod tej klasy.

Ewentualnie, możesz sam napisać sobie własny Resource wzorując się na Zend_Application_Resource_Modules, zmieniając go tylko do swoich potrzeb.
Na to też nam Zend Framework pozwala. Potem wystarczy tylko dodać nasz Resource do konfiguracji, lub w głównym Bootstrapie:
http://framework.zend.com/manual/en/zend.a...eabstract.names
http://framework.zend.com/manual/en/zend.a...-operation.html

no chyba bez modyfikacji się nie obędzie, sprawdzę jeszcze czy plugin sobie poradzi, jak nie to będę tak kombinował, jeden bootstrap to też jakieś wyjście, ale jednak i tak inne będą poszukiwane. Dzięki za pomoc!