Czy faktycznie każdy rozumny człowiek powinien omijać PHP szerokim łukiem? Największe serwisy internetowe powstały w PHP (Facebook, YT). Internet jest zalany artykułami o beznadziejności PHP. Czy jest tak w rzeczywistości? Jakie są powody by tak twierdzić? Jeff Atwood stara się to wyjaśnić. SPAM

spam?
niektórzy programiści są nietolerancyjni

Jeszcze jakiś czas temu zastanawiałem się nad tym.
Ale odkąd zawodowo przeszedłem na Javę przestało mnie to interesować

W PHP każdy głupi umie napisać dynamiczną stronę która działa. To jest ogromna zaleta tego języka. Ale moim z czasem zamiast przepisać sam język tak żeby był przyjemny i usystematyzowany to mu dorabiano protezy. Mamy potworka, ale co z tego, skoro łatwo w nim napisać cokolwiek. Kilka naprawdę dobrych frameworków sprawia że te większe rzeczy też się pisze bez większych problemów. Dodaj do tego ogromną rzeszę programistów piszących w PHP (z tego co pamiętam, wedle jakiegoś poważnego rankingu jest więcej programistów PHP niż C/C++ (!)).

Ale z drugiej strony taki Ruby (o wiele przyjemniejszy od PHP*) ma Ruby on Rails, też świetny framework, sam z nim nie miałem bliższej znajomości ale jest podobno świetny, więc po co babrać się z PHP?

A jak pomyślę o Pythonie w którym naprawdę po prostu przyjemnie i tak jakoś naturalnie* się pisze, dodamy do tego np. Django (lub inny dobry webowy framework) to ja nie wiem po co sięgać po PHP?

Java... Java jest potężna, Java jest wielka, Java mnie przeraża Ale mogąc pisać w Javie strony to czemu babrać się w PHP?

Ano dlatego że jak chcesz tylko wyświetlić czas serwera na stornie w danym miejscu a resztę mieć statyczną, to w PHP zrobisz to szybciutko i prosto. Od czegoś trzeba zacząć. A w PHP uzyskujesz bardzo dużo bardzo szybko, mimo bardzo małej wiedzy, a do tego prawie wszędzie daną stronę postawisz z powodu popularności PHP. I to sprawia że PHP jest bardzo dalekie od beznadziejności*.
_____
*moim zdaniem oczywiście

Usunąłem link żeby spamu nie było i zapraszam do dyskusji.

A dlaczego od razu omijać ? hmm ja na przykład uważam że w PHP można na prawdę sporo napisać, programiści PHP są ciągle "rozchwytywani" przez różnorakie firmy. Oczywiście istnieją wydajniejsze rozwiązania, przyjemniejsze w pisaniu dużych aplikacji ale to nie oznacza że trzeba omijać PHP. Każdy robi to co lubi ja wybrałem PHP i nie żałuję co do innych rozwiązań to tak:

RUBY - nie wypowiem się
Java - Tylko na studiach, jest skomplikowana ale za razem wydaje mi się że jest to najbardziej obiektowy język. Na razie pisałem tylko aplikacje (no trochę za dużo powiedziane) desktopowe nie miałem styczności z jsp.
.NET - Tutaj to trzeba pochwalić za bardzo dobre darmowe IDE, ale poza tym to też nie widzę jakichś rewelacji.

Już sam temat nasuwa jedno określenie tego wątku "FLOOD" bo tak jak ja będę mówił że PHP jest ok i warto się go nauczyć, tak ktoś inny będzie pisał że nie ma sensu, że to badziew itd. Jedno jest pewne dla 90% programistów jest to pierwszy krok do pisania dynamicznych rozwiązań webowych, no a później to każdy idzie w swoją stronę

Spora nadinterpretacja. Znam bardzo wiele osób, które piszą aplikacje www i PHP na oczy nie widziały i go nie znają.

tak masz rację poprawna forma to : Jedno jest pewne dla 90% programistów z mojego otoczenia, jest to pierwszy krok do pisania dynamicznych rozwiązań webowych, no a później to każdy idzie w swoją stronę

@stosz: http://pl2.php.net/manual/pl/book.java.php albo http://quercus.caucho.com/ i to jest piękno tego języka Istnieje do niego praktycznie wszystko, sporo projektów z innych języków zostało przeportowanych do PHP i ma się dobrze. Czasami czytając komentarze ludzi piszących że PHP jest do ... widać że spodziewają się po tym języku trochę za dużo. Do zastosowań webowych jest idealny, ale niektórzy chcieliby też obrabiać n-gigowe raporty albo tworzyć śliczne GUI. Szpadlem też można wbijać gwoździe tylko po co? Na pewno wadą jest bałagan w nazewnictwie, brak obiektowości w wielu bibliotekach które aż o to się proszę ale z drugiej strony pojawienie się frameworków zaczyna ten język przeczyszczać. Mógłby być też trochę szybszy. A ponieważ jego popularność jest ogromna ciężko wymagać aby z kolejną wersją pozbyć się ot tak wstecznej kompatybilności.

PS. Nie cierpię pythona. Skręca mnie jak patrzę na ten kod, głupawe wcięcia które przy użyciu złego edytora prowadzą do wyjątków a frameworki mają ubogą funkcjonalność. No ale jest szybki i zaczyna być niestety popularny

Zły edytor? Zależy sobie ustawisz, ale trudno zepsuć ustawienia wcięć, tak by rozsypało to kod Uboga funkcjonalność frameworków? Jesteś uprzedzony do tego języka i nie ocenisz tego obiektywnie. Będziesz FUDował, kłamał i łgał tylko po to by się odgryźć na tym języku. Nie ty pierwszy i nie ostatni. Jedni jadą PHP, drudzy Pythona itd., ale czy takie wypowiedzi muszą być na takim forum?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


Każdy język, framework to narzędzie umożliwiające osiągnięcie celu, a to jak dobrze i wydajnie można osiągnąć dany cel wyznacza możliwości i ocenę danego języka, czy frameworka. PHP powstało jako "CGI done right" i nadal się rozwija, choć pojawiła się konkurencja z zupełnie innym podejściem do www. Język stosowany jest np. przez Facebooka, ale większość kodu została przeniesiona do C i innych języków/usług/aplikacji (patrz facebookowy Thrift). PHP dość ciężko rozszerzyć w C/C++ w porównaniu do konkurencji.
Nowe narzędzia jak Python/Django czy Ruby/Rails, Groovy/Grails itd. prezentują inne podejście do stron www - patrząc nie jako zbiór plików-stron, ale patrząc na "serwis" www jako aplikację. Do niektórych rozwiązań lepsze będą te technologie, dla innych PHP.

Polecam bardzo ciekawy artykuł o zmieniającym się podejściu do stron internetowych: http://jacobian.org/writing/snakes-on-the-web/

Więc odpowiedź na to pytanie IMHO jest tylko jedna: tak!

Czemu? Powodów jest wiele.

Dla mnie jednym z podstawowych jest fakt, że PHP koło wielowątkowości to nawet nie przechodził. W przeciwieństwie np. do Javy czy Python, gdzie conajmniej w zastosowaniach webowych programista jest z wielowątkowością bezlitośnie i twardo konfrontowany i jeżeli to zignoruje to zazwyczaj źle się to kończy. Poza tym samo pojęcie kontenera w PHP nie istnieje (conajmniej nie istaniało kiedy sporo jeszcze w PHP pisałem). Oczywiście PHP'owcy powiedzą, że pisanie wielowątkowe jest cholernie trudne i będą mieli rację. Jednak korzyści z niego są tak duże że po prostu nie da się tego pominąć. W Javie i w Pythonie poprzez zastosowanie kontenerów (i "pool"-i) udało się ten proces makabrycznie ułatwić.

Dalej co mnie kiedyś dobiło w PHP - jak się dowiedziałem, że int zależnie od platformy ma różną wielkość to myślałem, że padnę z niedowierzania (czemu - w C też przecież tak jest?, ktoś zapyta). Nie ma to jak dobry język wysokiego poziomu.

No i takie sprawy jak "high order functions" realizowane za pomocą stringów... Nawet C powoli umie robić to lepiej.

Ech, temat-flame...

Czy mi się zdaje, czy wszyscy z grupy Przyjaciele php.pl teraz prowadzą krucjatę jaka to Java nie jest och-ach?

@erix: starałem się jak mogłem odnieść do większej ilości języków i tamsamym być anty-PHP a nie pro-COŚ.

@Riklaunim: Świetny artykuł. Myślę, że może być to jedną z przyczyn dla których PHP jest takie niewygodne. Mi osobiście zdecydowanie bardziej odpowiada pisanie aplikacji a nie "stronek" i pewnie stąd moja niechęć.

A w Javie to samo (no niemal to samo) już Cię nie dobijało?
Każdy język ma swoje grzeszki ;-)

Mógłbyś rozwinąć? Zawsze myślałem, że w Javie int ma zawsze 32 bity.

A mnie się wydawało, że wiele języków ma to ustawiane zgodnie z architekturą -> 32 lub 64 bity. Przynajmniej z tego co kojarzę moje zajęcia z programowania i przestrzeganie wykładowców przed beztroskim korzystaniem z operacji bitowych na różnych architekturach. Jak to jest z Javą - nie sprawdzałem. W każdym razie ta uwaga mi utkwiła w głowie i do tej pory wolę wiedzieć jak duże mam poszczególne typy i wszelkie wariacje sizeof w sytuacjach niepewnych są w użyciu

Jestem w trakcie czytania Bruce'a Eckel'a i w jednym rozdzialow wyraznie zaznaczal, ze w javie odpowiednika sizeof nie ma i virtualna maszyna dba o to, zeby rozmiar byl wszedzie taki sam.

Co do tematu. W moim odczuciu w przypadku PHP ze wzgledu na jego latwa przyswajalnosc jest najwiecej "specjalistow" z miesiecznym stazem w nauce jezyka, stad moze sie taka opinia ksztaltowac, ale w zasadzie kazdy jezyk da sie wykorzystac w profesjonalny sposob... kwestia doswiadczenia.

Nieprecyzyjnie się wyraziłem. Nie o samą długość inta mi chodziło a o problem leżący całkiem niedaleko.
Pisałem kiedyś o tym. W komentarzu nr 5 ktoś zwraca uwagę na zależność problemu od różnej maszyny, co jest prawdą. Sprawdziłem.

A odpowiedź na pytanie postawione w tytule brzmi: nie. PHP nie jest badziewne. Jest za to pełne niekonsekwencji, chaosu i słabych rozwiązań i podjętych decyzji.
PHP w rękach sprawnego programisty jest całkeim niezłym narzędziem. Niestety ogromny odsetek kodu produkowanego w PHP to bardziew pisany przez "początkujących profesjonalistów".

~Bonastick Eckel'a się pozbądź lub zacznij nim palić w piecu. Książka jest słaba lub wręcz bardzo słaba na tle innych publikacji wspierających naukę Javy.

Dlaczego? Nie pierwszy raz o tym piszesz, a jestem ciekaw dlaczego Eckel jest taki słaby, zwłaszcza że ja Javy nie znam za dobrze, a wiem że ty tak.

Na Eckel'a skusilem sie, gdyz przed zakupem ksiazki trafilem na sporo pochlebnych opinii o niej. Miala to byc taka biblia dla javowcow.

Teraz sytuacja u mnie jest taka, ze jest to moje 2, czy 3 podejscie do tej ksiazki (troche miotam sie miedzy java a c++ nie mogac sie zdecydowac, czego sie uczyc) i za kazdym razem wrazenie jest takie, ze ksiazke czyta sie lekko, koles ladnie i ciekawie wszystko wyjasnia, ale czytasz 100 stron, 200 stron i uczucie jest takie, ze w zasadzie to nie za wiele sie po tych 100, 200 stronach dowiedziales.
Myslalem, ze to ze mna jest cos nie tak, skoro ksiazka miala byc taka dobra...

@mike za rzadko bywam na tym forum, zeby znac userow ale z posta sztosz'a wynika ze z java sie znasz dobrze, wiec tez chetnie przeczytam szersza argumentacje.

Taka właśnie jest ta książka. Przegadana, przereklamowana i o niczym.Tysiąc stron i nic konkretnego. Przeczytasz 600 to może czegoś się nauczysz.
Zdaję sobie sprawę, że moje powyższe opinie to niemal puste slogany ale z tej ksiązki naprawdę niełatwo się uczyć. To moja opinia i wielu moich znajomych.

Na końcu tego wątku znajdziesz polecenia lepszych książek Cay'a Horstmann'a. Doskonałego programisty i dydaktyka, który sam nauczał rzesze programistów.

A Eckel to taka chorągiewka. Coś, ktoś pierdnie na rynku IT a Eckel zaczyna pisać książkę i ewangelizować. Kiedyś sikał z radosci o Javie (Thinking in Java), wcześniej o C++ (również Thinking ...) teraz męczy teat Phytona i ksiązki nie może skończyć. Jakiej? Oczywiście Thinkink in ... Python.
Trochę opini u Joel'a (również bardzo znana postsać) między innymi o Eckel'u: Why Bruce Eckel Loves Python. Od jakiegoś czasu nie jest on jednym z moich autorytetów.

To prawda, ale są sytuacje gdy rozmiar jest dobrze znać. Problem ten jest poruszony w tym artykule. Myślę, że dość sensownie opisany.

To prawda niestety. Wiele osób łapie się za php nie mając niemal żadnych podstaw w programowaniu i sądząc, że to "lepszy, bo dynamiczny html" Potem mieszają wszystko ze wszystkim, wstawki są cudaczne, a kod to jeden wielki bajzel. W firmie gdzie pracuję właśnie siadamy do przebudowy starego serwisu na szablonach. To co widzę w plikach to tragedia. W każdym niemal są definiowane identyczne funkcje, które po prostu są dublowane w każdym z nich, do tego sam plik podzielony na funkcje na zasadzie takiej, że są one używane w każdym pliku jeden raz i tworzenie z bloków kodu funkcji jest zwyczajnie bezcelowe. Bo po co skoro w samym pliku jest ona wykonywana dokładnie raz? Tylko problem się robi bo nawalili przez to tylko globali. Oczywiście jeszcze php4 i layout na tabelkach. "Pseudo-standardy" sprzed lat są po prostu straszne.

Na pewno jednak w rękach osób z głową klawiatura, nawet z użyciem prostego języka, potrafi zdziałać więcej niż tego słabego z teoretycznie wydajniejszym. Ostateczny kod to wypadkowa doświadczenia, wiedzy i pomysłów zawsze równająca do najsłabszego. Bez pomysłu nie powstanie algorytm, bez wiedzy brak będzie znajomości rozwiązań języka, bez doświadczenia nie zoptymalizuje się kodu. Brak któregoś, jeśli nie uniemożliwia zupełnie, to bardzo ogranicza sprawne i poprawne napisanie aplikacji.

Narzekać można.
Ja pracuję w dużej korporacji, nie-IT.
Tworzymy stronki, systemy, podsystemy, skrypty.
Chętnie programowałbym w Javie, bo to mój konik, ale standardowy czas na wykonanie projektu to 'one week' wypowiedziane z ust koreańskiego Pana.
Dodatkowo nikt to nie umiałby nawet podejrzeć kodu Javy, nie mówiąc o zrozumieniu.

Podsumowując, PHP się przydaje.

Która wielka korporacja zajmuje się "robieniem stronek"? I dlaczego jest nie-IT, skoro tworzy systemy i podsystemy (informatyczne?) ?
Wybacz moją dociekliwość, ale zaintrygowała mnie ta wypowiedź . Oczywiście nie musisz odpowiadać, jeśli nie chcesz drążyć tego offtopa.

Oczywiście odpowiem.
Ta wielka korporacja zajmuje się produkcją TV na dość sporą skalę (max. dzienna produkcja na jednej zmianie to 35000+).
Jak możesz sobie wyobrazić dział IT to nie tylko helpdesk.
Zapotrzebowanie na małe systemy jest takie, że następne 2 lata mamy plany.
Rozwiałem wątpliwość?

Dokładnie.
Również w firmie w której pracuję obecnie, wybrano PHP z uwagi na szybkość wytwarzanego softu.
Chociaż z drugiej strony, gdybym znał np jave tak samo jak php, to być może moja opinia byłaby inna. Firmy takie (nie-IT), które jedynie wytwarzają soft dla swoich celów, jadą po kosztach i lepiej im zatrudnić programistę PHP niż JEE, któremu by musieli płacić słono więcej.

Rynek PHP niezbyt się ceni, a to za sprawą ilości programistów - łatwy język to więcej ludzi do koryta.

Cieszy mnie też popularność frameworków - w pewnym stopniu filtrują język ze zbędnego syfu, tworzą pewną nakładkę normalności. Do tego pracodawcy coraz to częściej wymagają ich znajomości, z czym początkujący programista może mieć problemy.

Gdybym był bardziej złośliwy, powiedziałbym, że po to właśnie FW powstały, podobnie jak OOP
http://komputery.katalogi.pl/Kontrowersyjn...B%2B-t1492.html

Heh, przez chwilę nawet zacząłem wierzyć że nie żartuje Świetny tekst Niebanalny, inteligentny i do tego zabawny.

Wiadomo Chociaż z drugiej strony...

W JEE można by się obejść bez FW, tam od razu można sklecić w miarę czytelny kod, za sprawą servletów i jsp - rozdzielenie logiki od widoku bez używania FM.

Co do wywiadu, to ciekawe podejście. Osobiście nie wierze w jego prawdziwość. Dziwi mnie też stwierdzenie, że więcej czasu poświęconego jednemu projektowi, to więcej kasy. Może kiedyś tak było, teraz jest wręcz przeciwnie. I jeszcze, że OOP jest bezużyteczne - zdarza mi się poprawiać po kimś kod pisany strukturalnie i jest to paranoja, wszystko sztywne i teraz mamy typową grę w bierki - posypie się, czy się nie posypie.

Zawsze myślałem, że JEE jest swego rodzaju FrameWorkiem?

Tak samo jak w rowerze obejść się bez kół i nadal próbować jechać
JEE to zbiór wielu technologii, z których część to właśnie frameworki. Więc delikatnie mówięc to co napisałeś kupy się nie trzyma.

Czegoś z tym frameworkiem nie rozumiem. Jeśli napiszę sobie "stronkę" w PHP w oparciu o wzorzec MVC, pisząc wszystko od podstaw, to czy mam oddzieloną warstwę danych od warstwy prezentacji bez frameworka czy nie?

Źródło: Wikipedia.

Jeżeli napiszesz to zgodnie ze wzorcem MVC to jak najbardziej - przecież liczy się to JAK to napisesz, a nie W CZYM. Równocześnie możesz wziąć framework i walnąć SQLe w widokach albo printować dane z kontrolera.

Hah, no tak, ale Panowie! Chodzi o psychologiczne podejście - do JEE mamy FW, czyli mamy FW do FW...

Mike, jeśli wziąć JEE jako osobną platformę to nie zgodzę się z przyrównaniem, że JEE bez FW, to rower bez kółek. Tam jest wyraźne rozdzielenie widoku i logiki.

Mi chodziło o obśmianie podstaw Twojej tezy, że jakoby JEE jest frameworkiem.
I nie ma czegoś takiego jak framewrk do tworzenia aplikacji w JEE. Nie myśl w płytki PHPowy sposób.

JEE to zbiór technologii/standardów. Możesz pisać aplikacje wybierając sobie z JEE cokolwiek i łącząc to jak chcesz. Przykładowo bierzesz JSF (część JEE) i dorzucasz Faceletes (to już nie wchodzi w część platformy JEE) i masz aplikację, gdzie sam JSF jest frameworkiem. A spinasz to pewnie za pomocą Springa, żeby mieć wygodny IoC.
Do tego na pewno użyjesz JPA (standard JEE) zaimplementowany za pomocą Hibernate (framework/ORM który do JEE nie należy).

To nie jest PeHaPe, gdzie MVC to koniec świata. Słowo framework to teraz mekka, wszyscy mówią o frameworkach. W Javie częściej występuje pojącie technologii i standardu a nie frameworka.

Plurr napisałe że w JEE można by się obejść bez FW, rozdzielenie logiki od widoku bez używania FM. Więc zapytałem czy jak rozdzielę logikę od widoku bez używanie Frameworka to co... to piszę w JEE, tak? Też chciałem dążyć do tego o czym pisze mike, w Pythonie nie spotkałem się z żadnym frameworkiem poza tymi webowymi. W Rubym też nie. A te dwa języki to na pewno nie tylko web developement, w Pythonie pisanie okienkowych aplikacji to łatwa i przyjemna rzecz. Czemu więc jest tyle frameworków do pisanie aplikacji internetowych, a niewiele nie webowych?

Jeżeli zrobisz (nazwijmy to na razie tak) zbiór klas, które implementują funkcjonalność MVC, następnie, użyjesz tego zbioru klas do tego aby napisać aplikację to zastanów się nad jedną rzeczą. A mianowicie nad tym która część kontroluję drugą. Zbiór klas kontroluję Twój kod czy na odwrót.
Czy jak tylko odpala się aplikacja odpalany jest ten zbiór klas który implementuję MVC i on ustala kolejność wywołań Twojego kodu (wywołuję go) czy na odwrót?

Pytam się, bo pare postów wyżej wkleiłem definicję frameworku z Wikipedii i w tym przykładzie - zaimplementowania w kilku klasach funkcjonalności MVC, wszystkie cztery wspomniane warunki są spełnione. Więc tak, niniejszym napisałeś framework.


W ogóle, brak wielowątkowości to tylko jeden z wielu problemów PHP. Już to powtarzałem kilka razy na tym forum. PHP jest debilnie zaprojektowany od środka. Brakuję w nim tak podstawowych rzeczy jak chociażby normalne tablice. W nim rzadnej struktury nie można poprawnie zaimplementować, więc nie ma co wymagać dalej...

PHP to ofiara swojego własnego wieku dziecięcego. Zbyt późno wprowadzono prawdziwą obiektówkę, zbyt późno decydują się na Unicode, zbyt długo trzymano PHP4 przy życiu, zbyt bojaźliwie twórcy podchodzą do opróżnienia języka z prehistorycznych śmieci. A na dokładkę pierze mózgi programistów w kwestii systemów szablonów, którzy później łażą po blogach i forach i wypisują o tym takie głupoty, że głowa pęka .

OK, po tym jak sobie ulżyłem, trochę bardziej na poważnie: z jednej strony jest to język wręcz idealny, aby napisać coś na szybko, np. jakąś mini-stronkę lub przydatny w codziennej pracy gadżet, z drugiej - przy większych projektach wymagana jest pewna doza samokontroli. Można napisać świetny i stabilny kod, który nawet i na PHP7 będzie poprawnie pracować, a wystarczy chwila nieuwagi, by otrzymać sieczkę, która posypie się za dwa-trzy wydania. Co jest faktem to to, że projekt się rozwija, pomimo sporych zaległości i wszelkich problemów z kompatybilnością z tym związanych. Teraz wszyscy jeżdżą po niewydanym jeszcze PHP6, że jedyne co wniesie, to unicode, a nie zdają sobie sprawy, że wymaga to przepisania i dostosowania implementacji **wszystkich** możliwych funkcji, rozszerzeń i elementów składni języka, które z tego korzystają. Później zaowocuje to kupą wpisów na blogach z motywem przewodnim, jakie to PHP6 mało innowacyjne i niepotrzebne, kolejna grupa programistów się zniechęci, ponownie migracja na "szóstkę" będzie trwała przez to pół dekady, aż w końcu kogoś szlag trafi, stworzy od zera następcę PHP, tyle że porządnie zrobionego na dzień dobry i powstanie nowy biznes.

Wracając do wywiadu -> wątpię, by Stroustrup coś takiego napisał, nawet żartem (aczkolwiek nie wątpię w to, że poczucie humoru gość ma). Żadne oficjalne źródła o nim nie wspominają, a co więcej - IEEE miało z nim normalny wywiad w czerwcu 1998 roku, czyli wypadałoby zaledwie 6 miesięcy po poprzednim. Osobiście C++ olałem, bo miałem dość idiotyzmów tego języka. Jest C, później D, a do tego Java i PHP .

Szczerze mówiąc, nie bardzo rozumiem o co Ci chodzi z tym JEE. Chodziło mi o rozdzielanie widoku od logiki na 'czystej' platformie. PHP tego nie oferuje, piszemy klasy, żeby sobie to dopiero umożliwić.

Mike wyjaśnił pewną rzecz - teraz wiem, że JEE to nie sama w sobie platforma, ale zbiór standardów, więc mój przykład nie był do końca trafiony. Ale fakt, faktem, że gdybyśmy JEE jako spójną platformę traktowali, to po samym zainstalowaniu kontenera mamy już do dyspozycji servlet i jsp (rozdzielenie widoku od logiki). Bez potrzeby pobierania dodatkowych bibliotek JSF etc.

A to teraz ja już wiem o co tobie chodziło, czyli o możliwości tzw. "biblioteki standardowej". Dla mnie framework to zawsze było coś więcej niż kilka klas automatyzujących kilka rzeczy, ale z podanej wyżej definicji wygląda na to że to jednak ten zbiór kilku klas.

[PHP] pobierz, plaintext 
<?php
 
$title = 'Abc ' . date('Y');
$comments = array(...);
$sth = 123;
$sthElse = 321;
 
?><html>
...
<title><?php echo $title ?></title>
...
<ol>
<?php foreach($comments as $comment): ?>
  <li><?php echo $comment ?></li>
<?php endforeach ?>
</body>
</html>
[PHP] pobierz, plaintext 

Nie, wcale się nie da oddzielić widoku od logiki w "czystym" PHPie...

Nie rozumiesz istoty zagadnienia.
Oddzielenie tych dwóch warstw następuje wtedy kiedy możesz jedną wymienić i druga nie zauważy. Nie dasz rady w Twoim przykładzie zamienić widoku na XML'a lub PDF'a nie ruszając tego pliku.
Poprawnie zaimplementowany wzorzec MVC pozwala między innymi na podmianę komponentów widoku bez ingerencji w kontroler.

Hmmm.. nie do końca.
Jeżeli masz zamiar przekazywać dane z kontrolera do widoku i widok może być xml, pdf, html i z założenia może być podmieniany, to nie obejdzie sie bez wprowadzenia dodaktowej warstwy pośredniej "View-Logic". Gdzie każdy view-logic będzie inny dla innego typu widoku.

Imho, przyład Crosin-a jest jak najbardziej poprawnym logicznym oddzieleniem warstw. A jak wiadomo warstwy, pomimo, że istnieją, nie zawsze są fizycznie oddzielone.

@mike: dla maksymalnego uproszczenia zarówno widok jak i cała logika jest umieszczona w jednym pliku - ale pozostaje ona rozdzielona. To jest oczywiście bardzo prymitywny przykład ale chociażby przez proste wydzielenie kodu od linii 8-ej z mojego przykładu do osobnego pliku "załatwia sprawę" - przecież po 8-ej linii (gdzie kończy się logika) może być czy to kod HTML, czy PHP generujący PDFa.

Crozin: Po części masz rację, można i w taki sposób rozdzielić sobie warstwy, ale pewnie sam przyznasz, że aby osiągnąć pełną satysfakcję, trzeba by trochę kodu jeszcze dopisać. I o tym właśnie wspominałem w poprzednim poście - piszemy klasy, żeby sobie to umożliwić. Nie mamy dostępnego gotowego rozwiązania, coś na wzór wbudowanych template'ów czy servletu z jsp.

Wg mnie fajnie byłoby napisać klasę, dziedzicząc po już istniejącej bibliotece z SPL. W klasie wystarczyło by tylko zdefiniować plik widoku i nie musimy się już o nic martwić.

Nasty ma sporo racji w tym, co pisze. Przede wszystkim w poprawnym MVC kontroler powinien służyć wyłącznie do wyboru modelu, widoku i ustawienia im jakichś parametrów, zaś pobranie danych z modelu powinno leżeć w kompetencji widoku, by można było mówić o jakiejkolwiek przezroczystej wymianie któregoś z komponentów. Na dodatek warstwa prezentacji również ma swoją warstwę logiczną, odpowiadającą np. za obliczanie parametrów potrzebnych do wygenerowania stronicowania czy odpowiedniego wyświetlenia nagłówków listy w zależności od tego, po której kolumnie sortujemy. Jeśli będziemy to robić w kontrolerze, również sobie widoku nie zmienimy z HTML na XML, gdyż kontroler wymusza obecność pewnych elementów charakterystycznych właśnie dla HTML.

Żeby było ciekawiej, "oficjalny" framework PHP jest pełen tego typu kwiatków...

plurr -> co Ty chcesz po SPL-u dziedziczyć, co jest związane z MVC? Nie bardzo rozumiem Twoją koncepcję, mógłbyś ją rozwinąć?

Na forum PRO był już poruszany ten temat podziału widok/kontroler - chociaż nie doszliśmy do consensusu.

Oczywiście. Chodzi mi o gotowe biblioteki, których nie trzeba na nowo pisać. Podam przykład servletu, jako że jest to właśnie taki przykład, o którym pisałem wcześniej.

[JAVA] pobierz, plaintext 
import java.io.IOException;
import javax.servlet.*;
 
public class ForwardServlet extends HttpServlet
{
    protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException 
{
        String imie = request.getParameter("imie");
        String nazwiso = request.getParameter("nazwisko"); 
        request.setParameter("welcome", "Witaj " + imie + " " + nazwisko); 
 
        // itd... 
 
        RequestDispatcher rd = getServletContext().getRequestDispatcher("result.jsp");
        rd.forward(request, response);
    }
}
[JAVA] pobierz, plaintext 

Widok result.jsp - wiadomo.

Trochę ciekawych rzeczy zbliżających się do tego, o czym piszesz, można znaleźć w PECL-u, np. http://docs.php.net/http - niestety trochę czasu minie, zanim (i o ile) zostanie to włączone do oficjalnej dystrybucji.

LBO -> ciekawy temat, chociaż dotyczy tylko widoku, tymczasem implementacje modeli również często leżą i kwiczą.