W jaki sposób we frameworkach MVC są wywoływane domyślne widoki? Tzn. nie pytam o zasady MVC, lecz o kwestię techniczą od strony wnętrza frameworka.

Np. w Zendzie tworzymy sobie najbardziej podstawowy kontroler:

[PHP] pobierz, plaintext 
class IndexController extends Zend_Controller_Action
{
	function indexAction()
	{
 
	}
}
[PHP] pobierz, plaintext 

I już na tym etapie Zend wie, że ma wyświetlić zawartość pliku index/index.phtml.
Gdzie jest zawarty kod, który to realizuje? Działa to świetnie bo już w akcji można wyłączyć wyświetlenie zarówno layoutu jak i widoku, a nawet wywołać kilka widoków.

Zapewne do widoku jest przekazywana nazwa akcji jaka jest wywoływana, więc szukaj w widoku.

Uwierz mi, nie chcesz tego wiedzieć

A jeśli koniecznie chcesz, to przeanalizuj metody Zend_Controller_Front::dispatch(), Zend_Controller_Dispatcher_Standard::dispatch() oraz klasy Zend_Controller_Action i Zend_Controller_Action_Helper_ViewRenderer (tak na początek).

Pomocne będą:
http://nethands.de/download/zenddispatch_en.pdf
http://www.slideshare.net/polleywong/zend-...spatch-workflow
http://framework.zend.com/manual/en/zend.c...ler.basics.html

I jesteś tego pewien że to jest dobre rozwiązanie?

Jak chcesz to MVC to wybrałeś zły przykład. ZF to raczej zbiór komponentów niż framework i bardziej chyba będzie to wzorzec eee... MVP? No ale ok, trzymajmy się logiki - "MVC" potocznie czyli podział kodu na części wg ich przeznaczenia A każde rozwiązanie ma jakieś wady i zalety (pomijając oczywiście kompletne fuszerki czy improwizacje).

Poza tym trochę dziwne pytanie... a skąd wie, że ma wywołać kontroler np. index? Gdy odpalasz jakiś swój controller to dziedziczy on zapewne po klasie controller_action gdzie masz jakiś initView czy coś w tym guście, to tam kontroler ustawia widok czerpiąc z własnych ustawień (folder views i rozszerzenie .phtml) oraz z dispatchera, skąd pobierana jest nazwa mpdułu i kontrolera.

Niczego nie jestem pewien. Po prostu chcę sobie stworzyć mały framework zgodny z MVC. Do tej pory w jednej firmie używałem CMS-a opartego o Zenda, i choć sam CMS był z dupy to jednak z samym Zendem pracowało się w miarę OK. Przynajmniej kilka rozwiązań dawało wygodę i pomyślałem, że w swoim frameworku bym je zaimplementował, ale już nie w taki zamieszany (z punktu widzenia wnętrza kodu Zenda) sposób. Nie potrzebuję tylu komponentów ile ma Zend ani metod typu preDispatch(), postDispatch() oraz podobnych, tylko proste sterowanie kontrolerami, widokami i modelami, resztę bajerów jak obsługa bazy danych itd. oprę na własnych klasach - i to wszystko mi wystarczy. Jeśli czegoś zabraknie to wtedy to zaimplementuję.

Dlatego pomyślałem sobie: po co w każdej akcji ręcznie ustalać nazwę widoku, skoro domyślnie może być automatycznie ustawiona taka jak nazwa akcji, z możliwością ręcznej zmiany w razie potrzeby. To zły pomysł?

Skoro Zend Ci odpowiada to po jakie licho robisz swojego "frameworka"? Co z tego, że ma masę rzeczy, których na chwilę obecną nie potrzebujesz? W czym one przeszkadzają? A jak przyjdzie potrzeba użycia jednej z nich, to zamiast skorzystać z istniejących już rozwiązań będziesz je dopisywać do swojego FW?

Swój FW jest lepszy obojętnie jak działa, czy jest wydajniejszy, zawsze będzie lepszy bo został napisany przez Nas samych. Poza tym, nie przesadzajmy z tandetnym tekstem że jak już coś jest, to po co pisać coś swojego/nowego. Chociażby po to żeby się sprawdzić. To że Zend czy inncy FW tworzy 1k osób, nie znaczy że jest on dobry, przeciwnie, jest optymalny.

Poznanie jakiegoś FW zajmuje czasami więcej czasu niż napisanie czegoś samego, ponadto dobrze napisany własny FW posiada nieinwazyjną możliwość podpięcia zewnętrznych klas innego FW i nie ma z tym problemu.

Jest też jedna rzecz... Czasami są zlecenia, w których nie mogą być użyte elementy open source. Wtedy własny FW pasuje idealnie.

@!*! Jesteś jedną z niewielu osób, która nie atakuje tematem "wyważania otwartych drzwi" tak jak Crozin. Przy okazji podałeś wiele argumentów, które powinny być oczywiste dla wielu osób. W pełni zgadzam się z całym Twoim postem.

Ja dodam jeszcze, że:
- gdyby Linus Torvalds nie zaczął pisać jądra Linuksa, to kto wie, na jakim poziomie technicznym stałaby dzisiaj ludzkość?
Pisał ten system, kiedy istniał już inny. Ktoś z Was odważy się powiedzieć "po co wyważać otwarte drzwi" w odniesieniu do jego pracy?
- pisanie własnego frameworka to satysfakcja, nauka i minimalizm - po jaką cholerę tworząc dla kogoś małą stronkę opartą o MVC mam kopiować kilkaset (kilka tysięcy?) plików, które wchodzą w skład Zenda?
- mam używać Zenda (czy innego gotowego FW) i nigdy nie wiedzieć, jak właściwie działa taki FW?
- można stworzyć FW tak, by aplikacja oparta o niego przypominała inne frameworki, dzięki czemu modyfikacja aplikacji nie będzie nastręczać wielu trudności.

Proszę nie pytać mnie, czemu chcę tworzyć własny mini-framework, ani nie mówić mi, że to jest "be", bo to nie jest tematem tej dyskusji.


W skrócie: Tak.

P.S. Dałbym sobie głowę uciąć, że po napisaniu "tworzę sobie FW" następna osoba mnie o to zbeszta... I jak zwykle nie myliłem się ;-)

@!*! i Walian

Może inaczej.. Główny problem, który tyczy się pisania własnego frameworka to komponenty, tzn. ludzie zamiast skorzystać z gotowych klas [narzędzi], które ktoś już napisał i są one powiedzmy dobre (czy tam "prawidłowo" napisane) tworzą swoje własne, które zazwyczaj kończą się niepowodzeniem - przez co każdy je zmienia 50x lub pisze od nowa, bo albo nie spełniają wymogów takich i takich, albo są wadliwe w niektórych sytuacjach.

Sam twórca Symfony napisał artykuł "pisanie własnego frameworka w oparciu o komponenty Symfony". Pytanie - Dlaczego ludzie chcą pisać przykładowo własny ORM, który wydajnością różni się ciut od przykładowego Doctrine'a, a funkcjonalnością nie dobiega mu nawet do połowy? Ponieważ to mały projekt, to wszystko musi być "lżejsze" i "mniejsze"? W takim razie po cholere ładować tam ORM? Takim sposobem nie tworzy się nic sensownego tylko łata się dziury niczym robotnicy w polskich drogach.



Nauka? Piszesz jakąkolwiek rzecz - niech zarzućmy na przykład komunikację w MVC - Piszesz kontroler, model i widok odpalasz - działa, po chwili zastanawiasz się co dodać - analizujesz i dodajesz, działa - ale za chwile próbujesz wykonać jakiś wyjątkowy manewr, ale technikę jaką ustaliłeś wcześniej całkowicie wykracza temu wyjątkowi - co teraz? Przebudowujesz swój kod na taki, żeby pasował pod ten wyjątek, ale zaraz - dochodzi kolejny i znów schody, piszesz teraz obejście problemu dla niego - co się dzieje? Że tak powiem burdel, a dalej to sobie sam dopisz, gdy dochodzą inne sytuacje.



Poznanie jakiejś rzeczy zajmuje więcej czasu od napisania dobrze działającej swojej? Czyli uważasz, że zerknięcie do dokumentacji i popatrzenie kod (+ sprawdzenie tego czy faktycznie działa) jest dłuższe od napisania takiego samego (lub gorszego/lepszego) systemu? Poza tym, twierdzisz że w swoim FW nie ma problemu z zew. klasami - Czyli w Symfony lub Zendzie są? Bardzo dziwna sprawa - Szkoda na to słów.

Pozdrawiam i jeśli tak bardzo już chcecie pisać własne platformy to skorzystajcie chociaż z komponentów, które już ktoś napisał i spełniają one swój obowiązek, bo można powiedzieć że to samo tyczy się PDO, podstawowych funkcji PHP i np Iteratorów (W końcu z tego korzystacie, a chcecie mieć swoje, czyż nie?).

Ale dobre dla kogo? Dla Ciebie? Dla innych bo też z tego korzystają? Niektórzy używają GTK+ przy budowaniu aplikacji dla linux, inni Qt a jeszcze inni napiszą coś używając basha...

Chodzi o to żeby napisać coś co Nam pasuje... To ile błędów popełnimy w trakcie to już inna kwestia, dobrym rozwiązaniem przy budowie FW jest pisanie od razu jakiejś aplikacji w nim, np. CMSa wtedy wyjdą wszystkie błędy dość szybko. Tworzymy narzędzie które pasuje to naszego stylu, to po prostu wygodne.



Dokumentacja Zenda jakby to ująć... jest jedną z gorszych jakie miałem okazje czytać. To tylko moje zdanie i całkowicie się z nim zgadzam po prostu wolałbym przerabiać kod strukturalny aplikacji która ma 170k linijek w jednym pliku skompresowanej ciurkiem w jednej linijce, niż starać się zrozumieć tą dokumentacje. Podoba mi się za to dokumentacja CI, bo jest krótko i na temat, oraz cakePHP, bo jest krótko na temat i bez burdelu.



Nie chce mieć swojego PDO, bo po co? PDO jest wbudowane w PHP i działa idealnie. Po co miałbym korzystać z cudzych komponentów, jak to mój FW pisany pod moje potrzeby? Owszem mogę skorzystać np. z klasy routera tej z ZF ale nie pasuje mi ona, szczególnie że mój FW opiera się o konkretne założenia sterowania aplikacją, więc napisałem routing pod siebie np. zlikwidowałem całkowicie odwoływanie z linku do kontrolera, metody i parametru bo mi to po prostu nie pasuje i uważam to za głupotę. Dlatego zanim przeanalizowałbym i przerobił klasy ZF pod siebie... zajęłoby mi to więcej czasu niż napisanie własnej klasy. Która działa tak jak chce i jest odpowiednia dla mojego FW i sposobu jego działania.

Zanim zdecydowałem się napisać własny FW, zadawałem dużo pytań na różnych forach odnośnie właśnie ZF, cakephp czy CI, jak zbudować w nich coś, co byłoby dokładnie takie jak JA chce. Efektem tego było to iż większość rozwiązań jakie chciałem uzyskać, zwyczajnie pozostawała bez odpowiedzi np. budowa panelu administracyjnego dla wszystkich zarejestrowanych aplikacji, w głównej strukturze katalogu, stworzenie tym samym własnego ekosystemu. Tego po prostu nie da się zrobić "od tak" w tych FW, przynajmniej na ichniejszych forach nikt takiej wiedzy nie posiadał... I tak dla odmiany mój FW na to pozwala "od tak", bez ceregieli, prosto i przyjemnie.




Korzystasz z ZF czy jakiegoś tam FW, obojętnie... A wiesz chociaż JAK działają poszczególne jego elementy, nie pytam o efekt końcowy.

No właśnie używają GTK+ albo Qt - To nie są gotowce?



Jaki sens ma pisanie platformy pod gotowy projekt? Później nie możesz jej nawet przerobić bo większość elementów musisz zmienić.



Zend to akurat przypadek, gdzie jest masa forów i poradników na blogach, czy tam zwykłych dev stronach jak skorzystać z tego i tego (Nie wspominając o forum na którym właśnie piszemy). Co do cakephp i codeignitera nawet nie będę się wypowiadał bo niepotrzebnie rozpoczynać drugą wojnę.



Możesz sobie zadać to samo pytanie do chociażby Dependency Injection w Symfony.



Pisząc FW pod dany projekt, tworzy się pic na wodę - Bo wtedy to można nazwać "biblioteki projektu".



Dlaczego nie zrobisz wtedy adaptera dla tejże klasy i nie ustalisz swoich metod działania? Skoro jesteś aż tak zdolny by pisać własny FW, to chyba tak prostą czynność możesz wykonać w 15 minut?



Co jak co, ale w Zendzie panelem administracyjnym może być zwykły moduł i podobne rozwiązania znalazłbyś wszędzie (Czasami warto zaglądnąć na te zagraniczne fora, niż czekać nieustannie na odpowiedź na tych polskich).



Czy wiem... a po co mi to wiedzieć? W dzisiejszych czasach liczy się czas, który jest bardzo cenny. A jeśli już mam się dowiedzieć jak działa to i to, to po prostu wystarczy że zajrzę w źródła.

EOT jak dla mnie.

Dipter chyba nie za bardzo rozumiesz o czym rozmawiamy.



Tak, takie same gotowce jak PHP, ale to nie znaczy że mają w sobie wszytko czego potrzebuje.



Jakiej znowu platformy? Piszemy o FW który jest uniwersalny i napiszesz w nim wszytko co tylko zdołasz sobie wyobrazić.


Ponieważ musiałbym wiedzieć jak go zrboić, czy go zrobić i czy w ogóle mi się to opłaca wiedzieć. Jakbym był zwolennikiem czyjegoś FW to pewnie bym nawet go współtworzył, ale po co zawracać sobie głowę, dla mnie to jest dokładnie tak samo jak poprawianie kodu po kimś...


Mam dziwne wrażenie że nie wiesz czym jest PDO i uważasz że jest to klasa php.



Zadawałem pytania również na forach zagranicznych. To nie ma znaczenia jaki kraj, wyobraź sobie że w PL też są ludzie co znają się na rzeczy, choć nie koniecznie znają odpowiedź na wszytko, tak jak w przypadku tego panelu.



Mógłbyś. Żeby później na rozmowach kwalifikacyjnych nie przychodzili ludzie co chcą robić inicjacje obiektu.

Co nie oznacza, że trzeba je odstawiać na bok i pisać je od nowa.



Frameworka można w pewny sposób platformą, bo w końcu coś na czymś stoi. Poza tym sam sobie zaprzeczasz - Jak twój framework może być uniwersalny skoro piszesz go pod DANY PROJEKT.



Nie wiesz jak zrobić coś takiego, ale wiesz jak napisać framework? Gratuluję umiejętności (Nie chcę Cię tutaj obrazić, ani na Ciebie naskakiwać).



Nigdzie nie napisałem, że jest to klasa PHP więc nie wprowadzaj tutaj coś czego nie było - Miałem tu na myśli fakt iż to i to to narzędzie (Niezależnie od tego czy jest wbudowane jako rozszerzenie czy jako zbiór klas, bo i z tego i z tego korzystasz w podobny (prawie identyczny) sposó.



Nie sugerowałem się raczej tym, że w tym, a tym kraju są tak i tak znający się ludzie, bo to absurd - Bardziej chodziło mi o fakt że tam rozwój tego frameworka jest znacznie większy i prędzej tam znajdzie się odpowiedź niż tutaj.



Co ma piernik do wiatraka? Na rozmowach kwalifikacyjnych z tego co sam wiem, liczy się znajomość danego frameworka, a nie to czy znasz każdą jego linijkę od środka.

Nie za bardzo chcę mi się już spierać w tym temacie, bo szczerze i tak mało w tym sensu - Ty masz swoją rację, ja mam swoją.

Według mnie, czasami warto napisać własny FW (a przynajmniej można spróbować), ale żeby z tego wyszło coś rzeczywiście fajnego, to dobrze byłoby się zapoznać dogłębnie z kilkoma istniejącymi, sprawdzonymi rozwiązaniami Tzn. poznać je od podszewki, dobrze zrozumieć architekturę kodu oraz możliwości i sposoby używania (pisania za ich pomocą złożonych aplikacji). Plus do tego przydałaby się porządna wiedza na temat programowania w ogólności oraz doświadczenie w projektowaniu i kodowaniu.



Sorry, ale za wiele razy miałem do czynienia z takimi "frameworkami" napisanymi przez ludzi, którym się wydawało, że są dobrymi programistami i że stworzyli super dzieło, a w rzeczywistości te ich "frameworki" to była kupa prymitywnego śmiecia na poziomie rozwoju programowania sprzed co najmniej 10 lat. Co najśmieszniejsze, większość wyjaśniała swoje decyzje o napisaniu własnego FW tym, że chcą mieć "lekki" system, a istniejące FW-ki są "za ciężkie" (co to za argument? za ciężkie do czego?), bądź, że chcą mieć własny FW. No to mieli. W rezultacie wszystkie te rozwiązania, z którymi się zetknąłem, nie miały nawet połowy (co ja piszę - chyba nawet 1/5!) możliwości dobrych, znanych FW, za to mnóstwo najróżniejszych ograniczeń, upierdliwych wad i dziwacznych, pokracznych rozwiązań programistycznych.

No ale to tak wygląda z mojego punktu widzenia (czyli kogoś, kto musiał - krócej lub dłużej - z takim systemem pracować); jeśli dla autora taki FW był OK, bo napisał go podług własnych potrzeb dla siebie samego, to w sumie wszystko OK i nie ma się do czego przyczepiać... Jak ktoś chce, niech pisze, i nikomu nic do tego. W końcu faktycznie technologia rozwija się dzięki tym, którzy tworzą nowe, innowacyjne rozwiązania.



Kopiowanie niepotrzebnych plików jest bez sensu, jeśli w czymkolwiek przeszkadzają, gdy siedzą sobie w katalogach. Ale jest na to rada - np. taki ZF to zbiór najróżniejszych, luźno ze sobą związanych bibliotek - do projektu wystarczy skopiować tylko te potrzebne, używane pliki

A jeśli nie ma znaczenia, czy takie niepotrzebne pliki zostaną skopiowane, czy nie, to i problemu sensu/bezsensu ich kopiowania także nie ma, prawda?



Ależ nic nie stoi na przeszkodzie, by poznać, jak on działa

A jakiś argument w końcu podasz, tak czekam i czekam... Tylko wymyśl coś innego niż "bo ktoś już to zrobił "lepiej" i sprawdziło to tysiące ludzi", błąd, ktoś to zrobił, sprawił że jest to popularne i używa tego tysiące ludzi, a śmiem wątpić że im się w 100% takie rozwiązanie nie podoba, wystarczy poczytać kilka wspomnianych "dev blogów", gdzie nie raz ktoś proponuje własne rozwiązania, choć ciężko je wprowadzić... klasa rozszerza klasę X, ta Y, jeszcze idzie kolejne rozszerzenie do Z... I tym sposobem mamy załadowanych 30 klas w dół, tylko p oto żeby coś zmienić, bo tak na prawdę mogłaby być tą jedną (oczywiście można to zrobić na 1, co kto lubi, tylko czy to wtedy będzie na pewno kompatybilne, różnie bywa). Nie czepiam się objętości plików zenda, czy wagi całego FW, to dzisiaj w zasadzie nie ma znaczenia, chyba że ktoś jest fanatykiem minimalizmu.



A mógłbyś wskazać gdzie napisałem że tworzę go pod DANY PROJEKT?



Jasne że tak, ba nawet może być to w moim przypadku, jak w Twoim, Dipter czy Twórcy Symfony. Każdy ma indywidualne podejście do tego co i jak robi. W całej tej dyskusji został pominięty jeden fakt... Skoro ktoś pisze FW, i nie jest on na licencji open source, to jakby nie patrzeć jest producentem tegoż FW i to w zasadzie wyklucza Kowalskiego programistę który nie zrozumiał X rzeczy w nim, chyba że zatrudniamy pracownika, ale wtedy dajemy mu czas na zapoznanie się ze szczegółami.



Mąkę? Bardzo dużo, bo wystarczy że Ci coś zlecę, użyję jakiegoś określenia to nie będziesz wiedział o co chodzi mimo że "znasz" ZF. Oczywiście zajrzysz w dokumentacje, a jak nie rozumiesz to w google...

Wasza dyskusja za bardzo do niczego nie prowadzi bo właściwie to oboje macie rację tylko prezentujecie inny punkt widzenia. To czy warto pisać FW zależy od wielu czynników. Myślę, że główne kryteria w tym przypadku to wiek i tryb pracy tzn. freelancer vs praca zespołowa w firmie.

Jeżeli ktoś jest młody i dopiero się uczy to myślę, że warto napisać własny FW, bo to zaowocuje w przyszłości. Ale i tak przed pisaniem własnego FW dobrze jest poznać inne dostępne już frameworki i je przeanalizować chociażby po to, żeby podpatrzeć kilka fajnych rozwiązać i zobaczyć co się sprawdza. Ale to też zależy od człowieka, bo dla zdolnej osoby pisanie FW poskutkuje dużą wiedzą i doświadczeniem, a dla mało ogarniętej masą złych nawyków i dziurawym systemem, bo też już dużo wynalazków widziałem.

Natiomiast, jeżeli ktoś już ma trochę lat na karku i chce jak najszybciej podjąć pracę to pisanie własnego FW byłoby stratą czasu i odbiło by się bardzo nie korzystnie na: jakości projektów oraz na czasie realizacji. Na własny FW trzeba mieć dużo czasu i pierwsze jego wersje nie będą się nadawały do użytku.

W przypadku pracy w firmie w większym zespole wybranie gotowego FW ma bardzo dużo zalet;
- Przede wszystkim nie ma problemu, żeby kilka osób tworzyło jednocześnie projekt. Łatwo można się podzielić robotą i dużym atutem jest to, że FW przeważnie narzucają swoją architekturę, więc programiści skupiają się na tworzeniu logiki biznesowej i nie ma konfliktów typu, że każdy ma swoją klasę walidacji czy autoryzacji i jak to teraz połączyć. Łatwiej jest tworzyć jednolity projekt i go kontrolować.
- Nie ma problemu, żeby inny programista dokończył projekt, jeżeli pierwszy poszedł na L4, urlop, itp.
- Łatwo można włączyć kolejnych programistów do projektu, jeżeli realizacja się wydłuża, a termin co raz bliżej.
- Często też skrypt napisany na FW będzie łatwiejszy w rozbudowie i edycji dla programistów, którzy go nie pisali, jeśli znają ten FW.

Odnośnie jeszcze innych komponentów to czasami trzeba samemu coś napisać od podstaw z różnych powodów np. gotowe rozwiązanie nie spełnie założeń projektu, jest trudne w rozbudowie, nie wydajne, słaba dokumentacja lub jej brak, nie odpowiada naszemu stylowi programowania itd. To jest po postu kwestia indywidualna i każdy musi sam zdecydować co będzie dla niego lepsze w danym przypadku.

Tak na marginesie: śmieszni są dla mnie ludzie, którzy mówią "ja zawsze wszystko piszę sam" a potem patrzę na taki projekt i widzę: smarty, jQuery, edytor Wysiwyg, a dispatcher z książki przepisany itd.

Wiatrak się może rozpierniczyć

Pozdro

A właściwie to jest jakiś argument, który Cię zadowoli? Jak na razie zauważyłem, że pisać wszystko swoje i koniec kropka, bo to za ciężkie, to nie wydajne, to nie spełnia swych wymogów, a to zaś jest jeszcze zaprojektowane inaczej jakbyś chciał (Tutaj pytanie - A skąd masz pewność, że akurat twoje rozwiązanie jest dobre?). Co do tego iż jest popularne - Skoro ludzie w tym piszą, jest im wygodnie i ten framework im odpowiada tzn że jest on przereklamowany? Myślę że twoje założenia związane są właśnie z wcześniej wspomnianym CI lub Kohaną, które akuratnie dość dobrze zaprojektowane nie są (szczególnie ten pierwszy), co nie oznacza że nie spełniają swego zadania i za to plus.





Piszesz wszystko od razu pod CMS'a by to co ma się w nim znaleźć działało - A co jeśli przyjdzie napisać Ci coś innego?



No nie do końca, bo równie dobrze gdyby ktoś popatrzył na kod prostego warunku (mimo tego że nie zna składni żadnego języka) nie wiedziałby do czego to jest i co to w ogóle jest. Po co ktoś ma poznawać różne rozwiązania od środka jak nawet nie wie co z nimi zrobić na zewnątrz? - Jeśli ktoś nauczy się używać roweru to wtedy może spokojnie zbadać jak i z czego jest zrobiony i działa, bo niby po co ma robić na odwrót? Co mu to da?



LOL

Z pewnością jest i to wiele, tak samo jak dlaczego klasa X jest lepsza od Y, jeśli tylko dobra będzie argumentacja. Dlaczego uważasz że powinienem się męczyć z FW X który ma takie a nie inne podejście do projektowania które mi nie pasuje...

Bo to właśnie moje rozwiązanie A Ty skąd masz pewność że rozwiązanie w FW jest dobre?


Nie.


Na tym właśnie polega FW, jego budowa jest elastyczna, główny rdzeń pozostaje bez zmian, aplikacja z niego korzysta, i może mieć swoje moduły. Dlatego nie ma znaczenia czy będzie do CMS czy gra w przeglądarce z wykorzystaniem praktycznie tylko JS, bo obie aplikacje będą korzystać z głównego rdzenia FW. Nie napisałem nigdzie że jest to FW tylko pod CMS, a tylko że wygodniej jest pisać FW równolegle tworząc jakąś aplikacje, aby poznać zasady działania każdego komponentu.


To że jak mu odpadnie koło, to żeby wiedział że to nie wina bidonu.

Przykładem pisania czegoś swojego może być chociażby tutejszy formularz wysyłania postu... Zapewne są jakieś gotowe rozwiązania umożliwiające lepsze zarządzanie treścią przy długich wiadomościach... Przykładowo funkcja cytowania, można klikać w "cytat" ale trzeba przewijać stronę i ogólnie wielka niewygoda, ale załóżmy że mam czas, bo niby czemu nie i napiszę wtyczkę pod forum, które będzie cytować danych użytkowników w prostszy sposób, jakieś graficzne bajery tuż obok pola z tekstem np. śledząc akapity... Czy to znaczy że mam się męczyć z tym co jest, bo ktoś inny to napisał i "jest to dobre" ? Nie, siadam, piszę własny komponent i gra gitara.

Gdyby każdy tak myślał "po co tworzyć coś, skoro już to jest" to prawdopodobnie dzisiaj byś nie miał monitorów LCD czy plazmy na ścianie, a o takich wynalazkach jak ASP.NET czy D już nie wspomnę. I oczywiście byłaby jedyna słuszna przeglądarka, bez opery, chrome czy fx.

Ponieważ w każdej aplikacji którą tworzę za każdym razem się sprawdza.



Widzisz, po to Zend, Symfony, Yii, Kohana czy jeszcze inny framework był pisany, byś mógł postawić na nim co tylko chcesz (stąd też spory zasób komponentów - które tak przerażają tych co wolą coś lżejszego co jest bzdurą, bo i tak nie wykorzystuje się wszystkiego dlatego nie ma prawie żadnego wpływu na wydajność.)
Ty twierdzisz, że dobrze pisać coś równolegle, widzisz framework to trochę jak system operacyjny - powinien być w pewien sposób uniwersalny, a pisząc go równolegle z projektem zaczyna być ułomny, bo jest przystosowany tylko i wyłącznie do niego.



Tylko, że koło zazwyczaj samo z siebie nie odpada, dlatego pierw trzeba nauczyć się jeździć skoro wyskakuje taka sytuacja.



Tu nie chodzi o to, że coś jest i już jest dobre, trzeba używać i koniec kropka - Po prostu chyba lepiej jest coś wziąć, przestudiować, sprawdzić czy pasuje i czy spełnia wymogi, a dopiero jeśli jest przeciwnie i ten framework czy jakieś narzędzie jest na NIE, wziąć kolejny i sprawdzać dalej? Jak już tak konkretnie nic nie odpowiada twoim kryteriom i odbiega od twojej ideologii tworzenia aplikacji to wtedy pisz już swoją maszynkę.

Właśnie, w Twojej



Nie zrozumiałeś. Każdy FW ma w sobie rdzeń, bazę podstawowych klas z których korzysta każda aplikacja. Pisząc o tworzeniu FW i równolegle pisząc jakąkolwiek aplikacje, uczysz się np. zasad działania routingu, odczytywania uri, przekazywania parametrów do metody itd. To jest właśnie rdzeń, tak go się udoskonala, bo w każdej aplikacji będzie on działał na tej samej zasadzie jaką obierasz przy projektowaniu FW.


A niby o czym ja Ci piszę od X postów? W końcu załapałeś

Zapytałeś, dostałeś odpowiedź, więc o co chodzi?



Nie tłumacz z czego składa się framework, bo coś napiszesz nie tak i ktoś to jeszcze wyłapie - To dość rozlazły temat z czego składa się rdzeń i inne "podzespoły".
Jak można nauczyć się zasad jakiegokolwiek komponentu jak wspomniany routing, skoro nawet nie wie się w jaką stronę podążać? (Chodzi mi o fakt, że pisząc coś od początku trzeba mieć w ogóle wiedzę co ma się w tym czymś znajdować i co to ma za zadanie robić)



Z twoich postów jasno wynikało jedno - Pisz coś od początku dla nauki, satysfakcji i tylko dlatego bo tak lepiej, nie wspomniałeś nigdzie o tym, by w ogóle coś przed tym zrobić jak chociażby proste zapoznanie z jakimś gotowcem - Żeby nie było że to teraz zmyśliłem (Twój bodajże drugi post w tym temacie)



Pozdrawiam i odłączam się od tematu, bo do niczego to nie dąży

To chyba normalne że jak chcesz pisać własny FW, to taką wiedzę posiadasz. Co prawda później się okazuje ze jest ona podstawowa, ale to się szybko weryfikuje. Nie napiszesz dobrego FW w jeden dzień...



Nie zawsze jest to potrzebne... Zawsze trzeba Cie prowadzić za rączkę? Jeśli tak to chyba już zaczynam rozumieć dlaczego ZF jest taki popularny... Myśleć się Wam nie chce leniuchy!

Dąży, user !*! wyjaśnił ci że włąsny FW zawsze będzie lepszy bo został napisany przez Nas samych. Czemu? Bo znasz na pamięć jego kod źródłowy. I gdy przyjdzie potrzeba jakiś zmian to zrobienie tego zajmie ci 5min. W przypadku zenda czy kohany po zobaczeniu kodu fw pewnie zrezygnujesz z jego modyfikacji szukając innego fw lub jakiś dzikich obejść z wykorzystaniem frameworkowych haków i 5 dodatkowych modeli, zamiast edycji 4linijek kodu w swoim fw.

Zgadzam sie w 100% ze @Spawn i @!*! nie warto dalej walkowac tematu, jedni wola wlasne rozwiazanie inni jakies projekty open source.

Ogolnie FW sprawdzaja sie w pracach grupowych, choc i tak pewnie 1/4 albo 1/3 firm wdraza wlasne rozwiazania...!

Celowo nie zaglądałem do tego wątku, bo wiedziałem, że zrobi się tu tzw. święta wojna. No i jak zwykle miałem rację.

Czy Wy Panowie przeczytaliście dokładnie tytuł wątku? Czy tam jest napisane "Co lepsze - gotowiec czy własny FW?" ?
Trzymajcie się tematu. Po to twórcy for wymyślili dzielenie dyskusji na wątki, żeby nie robić bajzlu. Poza tym tego typu dyskusję widziałem już na wielu innych forach i po prostu nie chce mi się tego czytać, bo argumenty się powtarzają i - jak już ktoś wcześniej napisał - obie strony mają rację.

Tak jest chyba tylko na polskich forach. Na zagranicznych jakbym wyjechał z tekstem "Jak napisać jądro systemu operacyjnego?" to podaliby kilka ciekawych rad i linków. A u nas? "A po co Ci to?" "Zwariowałeś? Nie masz co robić?" Eh...

Co do gotowych rozwiązań - gdybyście widzieli, co programiści zrobili z tamtym CMS-em, który ostatnio wykorzystywałem... Wymienię kilka przykładów:

- Większość obsługiwał JEDEN kontroler (zajmował kilkadziesiąt KB).
- Kontroler Error akcja Error - obsługiwanie zapisywania się do newslettera - WTF?
- Kontroler Index akcja Index - wyświetlenie napisu mówiącego, że strona nie istnieje.
- Każdy kontroler dziedziczył po jednym kontrolerze, który już na starcie wczytywał WSZYSTKIE dane z bazy, tj. całą bazę danych (bo programistom było łatwiej się do tego odwołać).
- Wszystkie zapytania używały gwiazdki do pobierania danych z tabel.
- Nazewnictwo zmiennych typu "pp" "dx" "zp" itd.
- Mieszanie nazw polskich z angielskimi np. "dodajkomentarzAction()".
- Zakomentowane kawałki kodu osiągające rozmiary stron A4.
- Wykorzystywanie modeli w widoku i na odwrót.

I to zapewne robili programiści, którzy nigdy nie próbowali napisać swojego FW i chyba nie do końca wiedzą, po co powstał wzorzec MVC. Gdybyście widzieli jak ten CMS mulił...

Nie twierdzę, że nie powinno się korzystać z gotowców (nie mam zbyt wiele do Zenda), ale jednak takie próby zrobienia czegoś samodzielnie rozwijają abstrakcyjne myślenie, czasami uczą optymalizacji. Ale jak ktoś ciągle będzie wykorzystywał tylko gotowce to potem będą takie problemy, że sam nic nie będzie potrafił zrobić. Mógłbym podać gorsze sytuacje z jakimi się w pracy spotkałem, ale nie chcę, bo po co.

Ostatnie pytanie - kontynuujemy wątek wg tematu czy mam spróbować szczęścia na zagranicznych forach, gdzie ludzie są mniej skłonni do skakania sobie nawzajem do oczu?

Od kiedy to w MVC widok nie może mieć dostępu do modeli? MVC != MVP.
Frameworki MVC udostępniają nawet specjalne klasy do tego.

A to że zawalili sprawę to inna sprawa.

Dyskusja o tym czy pisać czy nie została zakończona. Jeśli ktoś chce dalej to wałkować to proszę założyć osobny temat.

Fakt, temat się trochę rozbujał... Szczerze mówiąc to zadałeś pytanie dość ogólnikowe na przykładzie Zenda (a teraz łapka w górę, kto przeanalizował kod widoków?). Co do linków z przykładami, z tym może być różnie... Zależy co chcesz osiągnąć.

Nie zgodziłbym się z tym co napisał Spawnm że MVC != MVP, bo niby dlaczego? MVC jest tak szerokim pojęciem, że każdy je interpretuje jak mu się podoba, MVP to takie MVC tyle tylko żeby określić od razu co robi widok, a co w przypadku gdy mogą być dwa warianty? Mamy FW korzystający ze wzorca MVC czy MVP? Nie, cały czas jest MVC.

Ustal pierw czy chcesz, aby widok był automatycznie generowany w akcji jaką wywołujesz. Dla mnie to trochę dziwne, bo kto powiedział że ta akcja musi mieć widok, i dlaczego musi być to akurat nawet index. Jeśli tworzysz kontroler, to zapewne dziedziczy on po czymś (główny kontroler FW lub aplikacji) i w tym czymś tworzy się widok na podstawie nazwy akcji jaka została wywołana.

W swoim FW przyjmuję zasadę "używaj czegoś, gdy jest to na prawdę potrzebne", czyli niewiele rzeczy generuje się z automatu. Gdy chce wyświetlić widok, to zwyczajnie to robię przekazując do niego parametry, z nazwą szablonu. Domyślnie, widok jest ustawiony na odbiór, ma tylko odbierać dane z kontrolera i ewentualnie je obrobić w pętli lub z czymś porównać. Taka opcja jest wygodna, bo nie muszę umieszczać w szablonie zbędnego kodu do modeli i samego kodu php, przez co webmaster nie musi narzekać, zresztą napisałem też mini system szablonów, co też się przydaje bo jest jedno spójne API. Zaimplementowałem też opcje która pozwala na używanie w widoku odwołania do modelu, to w zasadzie tylko mała furtka jakby było trzeba zrobić coś na szybko.

Nie kojarzę artykułów które by mnie naprowadziły "jak się robi FW", oczywiście, można spotkać coś podobnego jednak co z tego... To Ty piszesz FW, więc na co Ci wiedzieć jak robi to ktoś inny. Wszystkie komponenty FW, głównego rdzenia są dobrze opisane na wikipedii czy wikibooks i nie wzoruj się tylko na rozwiązaniach w PHP. A jak chcesz się czegoś od Nas dowiedzieć, to sprecyzuj dokładniej o co chodzi i jaką masz swoją wizję. ehh przypomniało mi się jak zaczynałem pisać FW... uri, router, boot, spl...

No to wyobraź sobie teraz, z czym miałbyś do czynienia, gdyby oni napisali do tego CMSa najpierw własny własny framework haha To by dopiero był sajgon I o to mi chodziło... jacy programiści, taki program. Nie chcę już mieć do czynienia z takimi frameworkami ani cmsami...

A wracając do tematu wątku.

Dla mnie najwygodniejszym rozwiązaniem jest, gdy widok jest wywoływany automatycznie dla akcji i nie wymaga to (domyślnie) żadnej konfiguracji (żadnego zbędnego wywoływania metod, ustawiania parametrów itp.). Dlaczego? Bo w więcej niż 90% przypadków widok jest wyświetlany, a proste, jednoznaczne, domyślne mapowanie akcji na widok ogromnie umila życie programisty Oczywiście, zawsze powinna być łatwa możliwość wyłączenia renderowania widoku dla danej akcji albo zmiana użytego szablonu. I tyle.

Coś nie bardzo trafiłeś z tym. Jak aplikacja jest źle napisana to żaden FW nie pomoże, nie bardzo rozumiem dlaczego uważasz że FW musiałby być zły, mało to projektów w których dokleja się tylko kod, bo jakakolwiek rozbudowa jest po prostu nieopłacalna? Świetnym przykładem jest tu wordpress, kolos z kodem że śmiać się chce, jedna wielka struktura, żadnego OOP. Nie można tego ruszyć, bo padnie kompatybilność setek wtyczek, tym samym siła napędowa projektu.
I piszesz że nie chcesz mieć do czynienia, to jak Ty pracujesz? Zostałeś producentem własnego oprogramowania i tworzysz tylko support?

No właśnie z tego samego założenia wychodzę. Używam widoku prawie zawsze. Ale chcę mieć też możliwość zmiany/wyłączenia zarówno layoutu jak i zwykłego pliku widoku.

@!*! - jemu raczej chodziło o to, że skoro zawalili sprawę z aplikacją, to i FW też nie potrafiliby dobrze sklecić.

Co do pierwszego postu napisałem mały mechanizm jak mogłoby to wyglądać. Pisane na szybko, więc mogą wystąpić pomyłki - No ale oczywiście to tylko przykład.

[PHP] pobierz, plaintext 
<?php 
 
class View 
{
 
	private $iterator = null; 
 
	private $name = null; 
 
	private $status = true; 
 
	public function __construct($name) 
	{
		$this->iterator = new ArrayIterator(); 
		$this->name = $name; 
	}
 
	public function getIterator() { /* */ } 
 
	public function getStatus() { /* */ } 
 
	public function setStatus($status) { /* */ } // ustawia status [true/false] dla renderowania 
 
	public function getName() { /* */ } 
 
	public function setName($name) { /* */ } 
 
}
 
class ViewRenderer 
{
 
	private $path = null; 
 
	public function __construct($path) 
	{
		$this->path = $path; 
	} 
 
	/** 
	 * Renderuje widok na podstawie sciezki z konsturktora i 
	 * obiektu - nazwy, danych i status [true = tak, false = nie] 
	 *
	 */
	public function render(View $view) { /* */ }
 
}
 
abstract class Controller 
{
 
	protected $view = null; 
 
	public function __construct(View $view) 
	{
		$this->view = $view; 
	}
 
	public function getView() { /* */ }
 
}
 
class HomeController extends Controller 
{
 
	public function indexAction() 
	{
		$this->getView()->getIterator()->offsetSet('message', 'Hello, World!'); 
	}
 
	public function withoutRenderingAction() 
	{
		$this->getView()->setStatus(false); 
	}
 
	public function otherNameAction() 
	{
		$this->getView()->setName('hello-world'); 
	}
 
}
 
$view = new View('home/index'); // Tworzyrsz obiekt widoku z domyslna nazwa taka jak kontroler/akcja
$viewRenderer = new ViewRenderer('/../app/views/'); // Tworzysz obiekt klasy renderujacej widok 
 
$homeController = new HomeController($view); // Tworzysz kontroler z widokiem w konstruktorze
 
$homeController->indexAction(); 
echo $viewRendrer->render($homeController->getView()); // Zaladuje widok home/index, wyswietli Hello, world!
 
$homeController->withoutRenderingAction(); 
echo $viewRendrer->render($homeController->getView()); // Nic sie nie stanie - biala strona
 
$homeController->otherNameAction(); 
echo $viewRendrer->render($homeController->getView()); // Zaladuje widok hello-world
[PHP] pobierz, plaintext 

Większość spotykanych frameworków ma już metodę renderującą w samym widoku (co też nie jest złe), mnie osobiście przypada taka wersja

Właśnie.

Ostatnio rozmyślam nad czymś takim... Wszytko opiera się o MVC, czyli kontroler grzebie w modelu, ten odsyła dane do kontrolera, a ten zaś przekazuje dane do widoku w ten sposób:

[PHP] pobierz, plaintext 
view:get('nazwa_pliku.html', $param);
[PHP] pobierz, plaintext 

Gdzie zostaje wczytany plik html, a jako parametry może być to tablica ze zmiennymi, jakie występują w widoku, zamieniane przez system szablonów, a jako trzeci parametr true/false w zależności czy chcemy go wyświetlić, czy tylko odebrać i przekazać dalej.

Tak dziala prawie kazdy fw o ile nie kazdy...To bylo pytanie retoryczne, bo nie widze zebys o cos pytal