Witam

Nie byłem pewny, czy wstawić temat tutaj, czy do "Przedszkola", chociaż w sumie przedszkolakiem nie jestem, ale skoro już jesteśmy, to mam do Was pytania. Tworzyłem trochę w php (najpierw strukturalnie, a później oop) + bazy danych, parę stron, miałem przerwę małą, teraz do tego postanowiłem wrócić i dalej się uczyć. Najlepiej przez praktykę.

Jako taki cel obrałem sobie zbudowanie strony/cms, którego budowa byłaby w miarę modułowa. Chodzi mi o możliwość dodawania swego rodzaju wtyczek/modułów, ustawiania ich miejsca w szablonie strony itd. Ogólnie pomysł wszystkim dobrze znany. Miałem go to budować bez użycia frameworka, głownie dlatego, że po prostu z żadnym nie miałem do czynienia. Z początku chciałem to ogarnąć później, ale po paru krótkich rozmowach mam wątpliwości. Może lepiej zaznajomić się np. z Zendem i na nim oprzeć taki cms?

Zdaję sobie sprawę, że z fw bd mniej pracy przy pierdołach, czyli szybsza budowa, być może później bd lepiej rozwijać projekt oparty na fw, ale trzeba poświęcić czas i go (fw) też opanować. Jednak z drugiej strony, czy fw nie utrudni zarządzaniem takim systemem z modułami, nie da jakiś ograniczeń i bd musiał rozwiązywać problemy bardzooo na około, albo bd miał problemy z dodawanie nowych modułów/dodatków/pluginów (czy jak to zwać). Wiem, że pytanie takie ogólne, ale cóż. Tak też bywa, a od tego jest forum, żeby dzielić sie doświadczeniem.

Pozdrawiam,
Kuba

Co do tematyki 'pluginów' to jest juz taki temat na forum, wałkowany tam od 2005 roku:
http://forum.php.pl/index.php?showtopic=34190

Jednak co do budowy własnego FW, zrobiłem kiedyś cos podobnego jak ty i co prawda teraz używam mojego zbudowanego własnie wtedy FW w 90% aktualnie prowadzonych projektów, to jednak wielokrotnie przepisywałem część modułów oraz poprawiałem, biorąc przykład właśnie z najpopularniejszych FW, bo mówiąc tak po prawdzie to na prawde Ciężko jest stworzyć rozwiązania lepsze od tych w nich zastosowanych. Możesz zbudować FW w oparciu o inną architekture, pisząc kod w sposób nie obarczony błędem pierwowzoru, jednak wtedy każdy człowiek który miał by dojść do zespołu musi nauczyć się całkowicie nowej 'filozofii' programowania, twojej filozofii. Korzystając z dobrodziejstw globalizacji lepiej w bardziej odpowiadającej nam (przystepnej) formie zbudować go w oparciu o rozwiązania zbliżone do tych z popularnych FW. Swoją drogą z chęcią powiedział bym na których powinienes się wzorować a na których wprost przeciwnie, ale już sobie wyobrażam jaka wojne wywołam na forum, lepiej po prostu poczytaj o tym w przeróżnych artykułach na ten temat. Budowa własnego FW jest (przynajmniej była dla mnie) doskonałym treningiem, pozwala nauczyć się pisać przemyslany kod który w dodatku może nam potem posłuzyć jako narzędzie pracy przy tworzeniu kolejnych projektów.

Dzięki, przede wszystkim dzięki za tego linka. Cały czas w głowie miałem "moduły", a pod tym nic nie znajdowałem ciekawego. Chyba poczytam trochę o AOP i FLOW3.

Lepsze - to pojęcie względne. Rozwiązanie problemu pluginów w Zend jest jak dla mnie zbyt skomplikowane. Robienie rzeczy samemu daje nam poczucie większej stabilności programu, inna sprawą jest, że żaden framework nie zapewni nam rozwiązania naszego problemu w idealny sposób, a jedynie nam pomoże.
Same biblioteki framework'a mogą zupełnie nie pasować do architektury tego co robimy. Jeśli na przykład założe, że pluginami w mojej aplikacji będą elementy na Tablicy (ze wzorca Tablica) wtedy tak zakombinuje architekturą, że będzie zupełnie inna niż to co daje mi ZendPlugin. Masa funkcji z tej biblioteki po prostu nie będzie używana więc lepiej to zrobić od podsatw samemu. Tak sprawę widzę z resztą frameworków. Plugin powinien istnieć w naszych głowach jako nazwa abstrakcyjna, którą stosujemy do szeregu elementów, które chcemy podpinać. Natomiast charakter tych elementów i sposób ich podpinania w całej aplikacji może być różny w różnych komponentach. Komunikacja pluginów z resztą aplikacji czy innymi komponentami pluginowymi również będzie inna. Jeden komponent będzie rozszerzany przez stosowanie PluginówStrategii a inny komponent będzie realizował rolę Pluginu przez użycie Obserwatora. Widać więc, że np. ZendPlugin to tylko namiastka rozwiązująca jakiś problem ogólnego rozszerzania aplikacji. Tak naprawdę powinno się samemu myśleć czym jest plugin dla nas w naszej aplikacji i na bazie tego tworzyć komunikacje opartą o znane wzorce czy gotowe rozwiązania framework'owe (lub nie).