Dyskusja:PHP

Plan prac

Żeby cokolwiek zacząć, przydałby się spis treści. Chętnie widziane są wszelkie propozycje :) Ja osobiście nie widziałbym czegoś jak w [1], bo tego podręcznika po prostu nie da się przebić - jest kompletny, oficjalny i po polsku. Raczej przydałby się podręcznik pokazujący krok po kroku jak stworzyć dobrą (zgodną z XHTML, CSS i PHP przynajmniej 4) i funkcjonalną stronę w PHP. --Derbeth 16:06, 8 maj 2005 (UTC)

Spis treści zrobiony, mogę nadzorować prace nad tym podręcznikiem. Na PHP znam się bardzo dobrze, pisałem o nim niejedno, więc powinno być OK. Poszukam nieco chętnych przez mój blog. PS. Mam nadzieję, że nie będzie jakimś karygodnym wykroczeniem, jeżeli w podręczniku będzie omówiona moja własna biblioteka Open Power Template? Tak się niestety składa, że jest to jedyny tak rozbudowany system szablonów dla PHP 5. Smarty'ego trudno omawiać, bo bez pewnych przeróbek nie działa on w tej wersji. Gdyby jednak coś nie pasowało, to dajcie znać, a usunę. --Zyx 08:30, 30 gru 2005 (UTC)

Nie widzę problemu pod warunkiem, że reszta podręcznika będzie przeważać nad rozdziałem o szablonach ;-) --Derbeth ^talk 09:55, 30 gru 2005 (UTC)

Nie ma sprawy, OPT to nie PHP :). W przyszłości dojdą jeszcze inne systemy szablonów, jak się zbiorą osoby chętne, aby o nich wyczerpująco napisać. --Zyx 11:15, 30 gru 2005 (UTC)

Porównałem sobie nasz spis treści z angielskim i musze powiedzieć, że moim zdaniem ten jest za mał przejrzysty. Chociazby umieszczenie informacji o typach danych w pierwszysm programie zamiast w zmiennych to lekka przesada. Czekam na opinie :) Hajder 16:48, 1 sty 2006 (UTC)

To ten rozdział o danych można bez problemu przenieść do "Zmiennych", za które zaraz się zabiorę. Co do samego menu... Jeśli tworzymy podręcznik mający DOBRZE wprowadzić w świat PHP, musimy zrezygnować z pewnej systematyczności. Inaczej wyjdzie nam zwykła lista referencyjna logiczna i czytelna dla osób znających już PHP, ale trudna do przetrawienia przez początkujących. Wiele elementów zazębia się w sobie i ciężko robić jakiś rozdział wyłącznie o jednym. Przykładem jest korzystanie z funkcji, które powinno się wprowadzić już przy pierwszym lub drugim rozdziale. Porównaj to sobie z nauką języka mówionego. Jej też nie zaczynasz od "My name is", by zaraz potem przejść do wyczerpującego maratonu z gramatyki, łudząc się, że wszystko zostanie zrozumiane i zapamiętane. Nauka poprzez przykłady i lekką przypadkowość jest o wiele skuteczniejsza, bo najpierw mamy praktykę wchodzącą łatwo, potem teorię pozwalającą usystematyzować garść zdobytych informacji, a dopiero na końcu porady, jak wykorzystać teorię do osiągnięcia lepszych wyników w praktyce.

Masz jednak część racji... nie ma w ogóle w spisie treści informacji o np. korzystaniu z sesji i ciastek, funkcjach przetwarzania tekstu czy odczycie z plików. Tylko teraz pytanie: dodać to przed rozdział o bazach danych, czy po nim? --Zyx 16:59, 1 sty 2006 (UTC)

przed... Hajder 22:29, 5 sty 2006 (UTC)

dołączam... co do wątku nie zapomnijcie o przekazywaniu obiektów w sesji bo dużo osobób na newbie o to pyta. Ja mogę zająć się wstępnie SQL oraz wersjami code injection oraz ogólnym spojżeniem na bazy. Tak jak wspomniałem nie wystarcza mi spojrzenie na bazy jako MySQL (bo to jest wszędzie) i nie pokazuje problemów, które wychodzą po czasie, np przy migracji. Kolejna sprawa to wykrozystanie PHP poza webem, w portalach intranetowycho oraz poprostu w konsoli jak choćby PERL. Sielay 20: 12, 8 sty 2006 (UTC)

Tak, właśnie te rozdziały o pracy z PHP na konsoli by się najbardziej przydały. Na razie jest o tym biednie w menu, dlatego opracuj propozycję całego rozdziału o tym. Ad. baz danych -> natywne biblioteki łączenia się z bazami danych to już przeżytek i co najwyżej o nich tylko wspomnimy. Podręcznik ma w zamierzeniu być aktualny, co wiąże się z opisaniem biblioteki PDO dostępnej od PHP 5.1. Jest to jednolity interfejs do komunikacji z bazą i ewentualne różnice sprowadzają się tylko do języka SQL. Tego natomiast nie będziemy tu zbyt szczegółowo opisywać, bo o SQL'u jest (tzn. ma być :)) osobny podręcznik, podobnie jak o innych bazach danych. --Zyx 20:44, 8 sty 2006 (UTC)

No mi chodziło o pewne rozwiniećie jak można zrobić migracyjność samego SQL. Bo jest kilka takich proijektów... no ale zaczniemy od konsol. Sielay 21: 46, 9 sty 2006 (UTC)

Brakuje mi w spisie treści rozdziału o XML (oczywiście w kontekście przetwarzania go przez PHP) oraz wzorców projektowych. --Orajo 23:24, 3 mar 2006 (UTC)

Wzorce projektowe są, XML też może kiedyś dojdzie. Na razie trzeba zrobić to, co jest, a później myśleć, co by tu jeszcze dodać. --Zyx 19:38, 4 mar 2006 (UTC)

O czym dokładniej będzie poświęcony temat w kategori Bazy danych: Bazy danych i co dalej?? ?:)--Aure 08:37, 6 maj 2006 (UTC)

Uświadomieniu czytelnikowi, że to, co wyczytał w tym podręczniku, to absolutne podstawy podstaw, jeśli chodzi o bazy danych i wskazaniu dalszych możliwości "kształcenia się" w tym kierunku. Dodałem coś takiego, gdyż zauważyłem, że wiele osób po przeczytaniu jakiegoś prostego kursu jest święcie przekonanych, że to wszystko i mogą spocząć na laurach, bo umieją zapytanie SELECT a FROM b napisać. Tak być na pewno nie powinno. I pamiętaj o podpisywaniu się! --Zyx 07:55, 6 maj 2006 (UTC)

Wersja PHP

Należałoby się teżzastanowić jakąwersję PHP będziemy opisywać. Czy najnowsze PHP 5 z wyjątkami itp. czy też PHP 4 które jest i przez dość długi czas będzie dominowało na serwerach hostingowych.--Migol 03:07, 7 wrz 2006 (CEST)

Eeee... że co przepraszam? :) Przecież nawet w spisie treści widać, że opisywana jest wersja 5.1, a w jednym z początkowych rozdziałów jest to doprecyzowane: podręcznik będzie stale aktualizowany wraz z ukazywaniem się kolejnych wersji. --Zyx 07:11, 10 wrz 2006 (CEST)

~poczatkujacy (22.03.2008)

mam pytanie, przeszukalem internet, w sprawie "Forbidden

You don't have permission to access /phpinfo.php on this server."

I jest jednym slowem lipa, nie wiem co zle zrobilem, a naprawde duzo kombinowalem, wszystkie pomoce ktore ludzie dawali na forach nie pomagaja. ;/ nadal sie to wyswietla, mysle zeby ktos kto sie zna bardzo dobrze na tym umiescil to w podreczniku. ;(

phpinfo.php zazwyczaj zawiera jedną finkcję o tej samej nazwie. Jest ona jednak szczególna, mianowicie wyświetla wiele kluczowych informacji na temat modułu PHP pracującego na serwerze. Te informacje mogą potencjalnie dostarczyć wiedzy komuś kto chciałby zrobić z niej niewłasciwy uzytek. Stąd czasami administrator blokuje do tego dostęp. Czy słusznie - to inna bajka, bo informacje te można wydobyć też w inny sposób, ale to inna kwestia. Podsumowując - gadaj z adminem.--Orinoco 11:45, 25 wrz 2009 (CEST)

Frameworki

Najbardziej w podręczniku brakuje rozdziału o frameworku. Każdy kto poważnie podchodzi do programowania nie ma zamiaru pisać czegoś co już było napisane, to banalne ale autorzy niniejszego podręcznika o tym zapominają.

Być może używanie frameworków jest kontrowersyjne jeśli mamy zamiar zbudować jakąś aplikację całkowicie od podstaw, wcielić w życie jaką nietypowy pomysł na aplikację, i gotowy framework będzie organiczał elastyczność, jaką daje programowanie od postaw. Jednak pisząc podręcznik dla początkujących nie sposób nie podsunąć im tego rozwiązania jako sposobu na zrealizowanie wysokiej jakości aplikacji w szybki sposób.

Mało tego, trzeba o tym pisać i to o wiele więcej niż o tym, jak wszystko robić od podstaw. To wielka strata czasu i potencjału, jaką daje programowanie w każdym zaawansowanym języku programowania. Wiele z obecnych rozdziałów podręcznika opisuje zagadnienia, które mogą być zrealizowane szybciej, łatwiej i daleko bardziej niezawodnie za pomocą odpowiednio dobranego frameworka.

Polecam zatem opis tego, jak zbudować i skonfigurować kompletną aplikację za pomocą sztandarowego frameworka dla PHP: Zend Framework. I to, co mogłoby odróżniać taki podrozdział tego podręcznika od Przewodnika programisty Zend Framework może być położenie głownego akcentu na nauce budowania kompletnej aplikacji ze wszystkimi składnikami, które mogą jej być potrzebne, a nie opisywaniu każdego ze składników bez uwzględnienia powiązań między nimi i tego, że w końcu tworzą jeden program.

Wcale nie mówię "nie" frameworkom, z tym że na obecnym etapie prac jeszcze nie czas o tym dokładniej myśleć; chociażby rozdział o obiektówce jest do napisania. Teraz mam krótką przerwę w pracach nad podręcznikiem, ale niedługo znów wrócę do niego :). --Zyx 07:52, 30 wrz 2006 (CEST)

Konwencja nazewnictwa

Zmieniłem konwencje na konwencję slashów (zgodnie z ustaleniami w barze). --Piotr ^@ 11:55, 14 paź 2006 (CEST)

Cytat z treści - "To są jedynie podstawy kodów formatujących. Szczegółowy ich opis znajduje się w dokumentacji PHP.". Chodzi rzecz jasna o funkcję printf(). Tyle, że autor/zy odsyłają po szczegóły do dokumentacji PHP, która (wciąż w znacznym stopniu) występuje w j. angielskim. Stąd byłoby chyba wskazane by takie odesłania uzupełniać linkiem do odpowiedniego fragmentu oficjalnej dokumentacji lub przynajmniej podać, jak się dany element w języku angielskim nazywa. Po to oczywiście by zainteresowany wiedział co ma wpisać w szukajce, bo pewnie na "kody formatujące" nie dostanie wiele w odpowiedzi (może dostanie - może ta część jest akurat przetłumaczona, nie sprawdzałem, to tylko przykład). Znajomość angielskiego niekoniecznie musi jeszcze oznaczać znajomość angielskiej terminologii związanej z PHP i programowaniem w ogóle. --Orinoco 11:33, 25 wrz 2009 (CEST)

Spis treści

Nie podoba mi się ostatnia zmiana. Przede wszystkim - wyrzucenie "studiów przypadków" jako osobnych ćwiczeń. Przecież one były przygotowane spacjalnie jako podsumowanie rozdziałów, praktyczne użycie zdobytych informacji. Dalej: "przechowalnia". Co to ma właściwie być? Wcześniej był rozdział "dobra aplikacja" i to moim zdaniem jest pożyteczna inicjatywa - prezentować porady dotyczące dobrych praktyk programistycznych. Dalej: wzorce projektowe jako podrozdział "Tworzenia aplikacji internetowych"? Nie mam natomiast zastrzeżeń do dodawania nowych rozdziałów o frameworkach czy PostgreSQL. Proszę dodać je ponownie, ja nie mam czasu wycinać linijka po linijce między wersjami. --Derbeth ^talk 23:45, 28 maj 2007 (CEST)

Ano, Riklaunim, trochę za bardzo się rozpędziłeś z tymi zmianami. Myślałem, że masz zamiar przedstawić swoje propozycje, jak mi pisałeś pobawię się tym na weekendzie :). Głębokie ingerencje w pierwsze rozdziały są trochę nie na miejscu, ponieważ pisałem je tak, by stanowiły logiczny ciąg, a tu nagle znajdują się one w zupełnie innej kolejności. Niedługo przedstawię własną propozycję spisu treści będącą połączeniem tego, co jest i tego, co chcesz wprowadzić. --Zyx 08:18, 29 maj 2007 (CEST)

OK, co powiedzielibyście na coś takiego: Dyskusja:PHP/Spis_treści? --Zyx 13:56, 29 maj 2007 (CEST)

[względem oryginału] Jak dla mnie: 1. bazy danych - oddzielić treść ogólną od MySQL. PDO jest nie tylko dla MySQL. PHP5 zawiera SQLite i warto by ta baza również została *wyraźnie* opisana. Inne jak postgres czy firebird po artykule (PDO + stare api). "Systemy szablonów" - co to ma do nauki samego języka ? nie jest to element składni. Jak dla mnie to już części aplikacji i powinno to być w części opisującej aplikacje i ich tworzenie. "Dobra aplikacja" - pomieszanie "teorii" jak np. MVC wzorce projektowe z "elementami" PHP5. "Silnik", "Kontrola formularzy" itp. - zamiast tworzyć coś dziwnego lepiej zająć się albo ZendFrameworkiem albo CodeI Igniterem - prostymi, lecz funkcjonalnymi frameworkami MVC. "Filtry" - chodzi o te filtry z PHP 5.2 ? ludzie od bezpieczeństwa solidnie na nie bluzgają, od strony koncepcji i funkcjonalności http://blog.php-security.org/ ;) "Gdzie trzymać konfigurację? " - to jest dość dziwny artykuł, stosuje jakieś wymysły typu "ConfigMagik", temat dobry, treść już nie ;) Ja bym ten dział "Dobra aplikacja" trochę przebudował. Jedno to frameworki, wzorce projektowe itp, drugie to gotowe skrypty - opisać "co to" CMS, Forum, wiki, na jakiej zasadzie działają, wymienić przykładowe, trzecie - różne komponenty aplikacji i frameworków jak wspomniane systemy szablonów, PECL, PEAR i inne biblioteki w PHP. W tym dziale można też dać bardziej kompletne "studia przypadków" pokazujące proste skrypty wiki czy np. forum (struktura tabeli, logika działania itp.) "Standard PHP Library", art 2 i 3 - pokrywa się z iteratorami. "Instalacja" - jedna droga to "gotowiec" jak XAMPP (bardzo dobry), druga dla odważnych - to co jest czyli instalacja samodzielna. W przypadku Linuksa nie dawać opisów ręcznej kompilacji, gdyż 99% ma odpowiednie pakiety - dawać linki do artykułów w sieci "LAMP w dystrybucji X" :) lub samemu opisać. Samodzielna instalacja wszystkiego to w przypadku początkującego szybka droga to jego paniki i załamania ;) "Formularze" - dlaczego tam jest opisane $_SERVER ? :) Ogólnie mam takie zastrzeżenia że ten podręcznik to kilka grupek artykułów, z których trudno się uczyć bo nie tworzą logicznego ciągu. Riklaunim

Kiedyś był taki 700-stronicowy podręcznik Turbo Pascal 5.5 Andrzeja Marciniaka napisany właśnie w myśl idei "ułóżmy wszystko tematycznie, a nie logicznie". Skoro znałem Pascala, było to dla mnie pomocne, ponieważ mogłem łatwo odnaleźć potrzebne mi informacje. Ale kiedy przychodziło się coś z tego nauczyć zupełnie nowego, to powodzenia. Szlag człowieka może trafić, bo wszędzie pełno suchych opisów, teoretyzowania i zastanawiania się, na jaką cholerę mi typ obiektowy, skoro nawet nie wiem, do czego to wykorzystać? Ale jest rozdział zbiorczy Typy, więc tam się to musiało znaleźć. Tyle że nauczyć się z tego podręcznika Pascala od zera to trzeba mieć było kosmiczne samozaparcie. Ten podręcznik właśnie TERAZ jest przeznaczony do czytania go rozdział po rozdziale. Naprawdę, nie mam zielonego pojęcia, skąd wywnioskowałeś, że w obecnym kształcie jest on zbiorem artykułów, kiedy zdecydowaną większość pisałem chronologicznie, odwołując się do tego, co już czytelnik powinien poznać, a w przyszłość wybiegając sporadycznie i zawsze ze stosownym komentarzem. Cały układ, jaki teraz widzisz i na bazie którego chcę podręcznik oprzeć, jest w pełni przemyślany pod względem kolejności serwowania określonych tematów. To nic, że wychodzi to trochę nietematycznie, że szablony są omawiane gdzie indziej, a pozostałe biblioteki napisane w PHP gdzie indziej. Ale o to chodzi, jeśli chcesz by nowicjuszowi po lekturze coś z tego zostało. Nie twierdzę, że jest idealnie, bo w sporej ilości rozdziałów można by głębiej rozwinąć integrację z tym, czego już się programista nauczył (i później prawdopodobnie właśnie tym się będziemy zajmować), o studiach przypadku również masz rację, że powinno być (i będzie) ich więcej (tyle że nie zebranych w jednym miejscu, a porozrzucanych). Natomiast teraz dokładny opis, dlaczego rozdziały są ułożone tak, a nie inaczej:

Najpierw oczywiście omawia się instalację i podstawową składnię języka, przy okazji z rozdziałami dotyczącymi błędów i korzystania z dokumentacji. Aby wszystko utrwalić, piszemy księgę gości, poznając przy tym trochę funkcji. Dalej w Rozmaitościach jest omówienie różnych zagadnień. Skoro jesteśmy na świeżo, zaczynamy od poszerzenia informacji o przetwarzaniu tekstu, a następnie uczymy się podstaw wyrażeń regularnych. Następnie idzie protokół HTTP i sesje, na końcu obsługa plików i internacjonalizacja (w sumie ten tekst mógłby być równie dobrze w innym miejscu), czyli praktycznie rozszerzyliśmy wszystko, co poznaliśmy pisząc księgę gości, z nawiązką. Teraz widzę, że rozdział "Obsługa XML" tutaj nie wejdzie, ponieważ programista jeszcze obiektówki nie zna. Kolejne trzy części mają stworzyć podstawy do rozdziału Dobra aplikacja. Najpierw poznajemy bazy danych. Piszesz: bazy danych - oddzielić treść ogólną od MySQL - i jak zamierzasz to wtedy zrozumiale omówić? Takie rozkładanie wszystkiego na czynniki pierwsze jest dobre dla kogoś, kto już ma o tym pojęcie, a my piszemy ten podręcznik nie dla siebie, lecz dla kogoś, kto formalnie dopiero zaczyna. Nie można go tak rzucić, że najpierw "omówimy ogólnie bazy danych", cokolwiek by to znaczyło, a później będziemy szczegółowo: MySQL, PostgreSQL itd. Na wstępie takie pokazanie, jak co się z czym wiąże, jest niezbędne. MySQL jest najpopularniejszy, więc dlatego poznajemy najpierw na podstawie tej bazy język SQL (tylko niezbędne rzeczy, ponieważ formalnie do SQL'a ma być osobny podręcznik), a później uczymy się z nią komunikować, bo przecież do tego wszystko dąży. Najpierw omówione jest PDO, ponieważ ja doskonale wiem, jak ludzie podchodzą do czegoś, co jest związane z obiektami. Stwierdziliby, że na to przyjdzie czas później i dalej będą pisać $result = mysql_query('...') or die('Błąd w '.mysql_error()); Dlatego celowo jest najpierw PDO (zresztą w treści jest wyjaśnione, dlaczego PDO jest rewolucją w stosunku do tego, co było kiedyś), a później skrótowo stary sposób komunikacji. I dopiero jak sobie czytelnik oswoi z jedną bazą, można pokazać mu więcej, omawiając je mniej lub trochę bardziej szczegółowo, ze szczególnym naciskiem oczywiście na PDO, by nikogo nie korciło bez potrzeby używać starych funkcji :). Później idziemy za ciosem: nauczyliśmy się rzeczy przydatnych przy omawianiu modelu, pora nauczyć się rzeczy przydatnych przy omawianiu widoku, czyli systemów szablonów (nawiasem mówiąc nie wyobrażam sobie omawiania widoków w MVC, kiedy szablony omawiane są 10 rozdziałów dalej). Dokładnie, tu nie chodzi o to, że to są biblioteki napisane w PHP i powinny (lub nie) być omówione razem z innymi, tylko zwyczajnie w moim zamierzeniu informacje z tego rozdziału mają mi być potrzebne dalej. Nawet do frameworków ten rozdział się przyda. Później obiektówka. Dlaczego pełne omówienie jest dopiero w tym miejscu, już tłumaczę. Po prostu omawianie obiektówki na sucho to całkowicie poroniony pomysł i ewentualnie kuracja dla masochistów. Właśnie tak to zostało w książce Marciniaka zrobione, a ja miałem nieszczęście się w ten sposób uczyć OOP. Ideałem byłoby wprowadzanie tego po kawałku, czyli przy bazach danych np. podstawy OOP (tak, jak teraz), przy systemach szablonów dziedziczenie i konstruktory, inne metody magiczne gdzieś później itd. Zamiast tego, skoro już później lecimy to za jednym zamachem, starać się będę umieścić tam dużo przykładów praktycznych, jak np. opis systemu konfiguracji w PHP/Klasy i obiekty czy tematyka baz danych i systemów szablonów. Tak przygotowani możemy dopiero wziąć się za wykorzystanie wiedzy w tworzeniu struktury aplikacji. Rozdział Dobra aplikacja czy Tworzenie aplikacji internetowych nie ma za zadanie objaśniać wyłącznie samej struktury MVC i ewentualnie wzorców projektowych, a zwrócić uwagę na wszystkie aspekty składające się na stronę WWW i rozszerzyć materiał w oparciu o najnowsze wiadomości. Spis treści obecnie nie jest jeszcze najszczęśliwszy i będzie zmieniany, ale ukazuje już mój zamiar. MVC i wzorce projektowe to nie wszystko - naprawdę powodzenia, jeśli ktoś się tylko z tym zabiera za budowę "profesjonalnej aplikacji". Przecież to stworzy tylko absolutny szkielet, który na dobrą sprawę do niczego poza osobistą satysfakcją się w praktyce nie przyda. Strona internetowa to przecież także systemy ACL, rejestrowania zdarzeń, przenośność, sesje, konfiguracja itd. Można nawet napisać na potrzeby tej części jakiś prosty framework i go dokładnie omówić kawałek po kawałku, przy okazji pokazując, jak rozbudowane mechanizmy stoją za wieloma stronami WWW. I tu przydadzą nam się m.in. szablony, które tak bardzo pragniesz wykosić gdzieś w diabły :). Po takim przygotowaniu, gdy sobie poeksperymentuje już z tym przykładowym frameworkiem, można wejść do omawiania gotowych. I dopiero teraz w zasadzie można już sobie pozwolić na odejście od formy stricte podręcznikowej i tematyczne menu. (tja, chyba się trochę rozpisałem :D) --Zyx 12:56, 31 maj 2007 (CEST)

bazy danych - oddzielić treść ogólną od MySQL - i jak zamierzasz to wtedy zrozumiale omówić?

Nie omawiać wszystkiego jakby MySQL było jedyną słuszną bazą danych. Jakoś nie widzę by na http://pl.wikibooks.org/wiki/PHP/Biblioteka_PDO było podane jak połączyć się z innymi bazami danych. Tak samo we wcześniejszych artykułach powinno być jasno zaznaczone że wszystko oparte jest o MySQL i dotyczy MySQL a w innych bazach jest to nieco inaczej. Oraz przy PHP5+ łatwiej o dostęp do SQLite niż MySQL ;)

(nawiasem mówiąc nie wyobrażam sobie omawiania widoków w MVC, kiedy szablony omawiane są 10 rozdziałów dalej)

A po co w MVC od razu smarty ? W CI szablony to pliki *php z kodem X/HTML w którym wplatamy wyświetlanie zmiennych.

Strona internetowa to przecież także systemy ACL, rejestrowania zdarzeń, przenośność, sesje, konfiguracja itd.

To i wiele więcej mam w Django, frameworku MVC. Framework to nie jest same wzorzec.

Można nawet napisać na potrzeby tej części jakiś prosty framework i go dokładnie omówić kawałek po kawałku, przy okazji pokazując, jak rozbudowane mechanizmy stoją za wieloma stronami WWW

Po co? Na forum.php.pl co tydzień pojawia się nowy "framework" bez przyszłości. Osoba poznająca świat PHP nie skorzysta z takiej wiedzy, chyba że uzna się nagle za eksperta i zacznie tworzyć swój super-wypasiony framework.Riklaunim

Jakoś nie widzę by na PHP/Biblioteka_PDO było podane jak połączyć się z innymi bazami danych. - W rozdziale PHP/Wstęp do baz danych jest "Przegląd serwerów DB", gdzie pokrótce są omówione także inne. Dalej jeszcze raz podkreślam: podręcznik to podręcznik, a nie dokumentacja! Po co podawać opisy połączeń z bazami danych, o których czytelnik co najwyżej gdzieś tam słyszał? Kiedy będą one omówione dalej, wtedy się poda. A w samym rozdziale jest zaznaczone, gdzie się bazę danych wybiera: "DSN - specjalny ciąg znaków identyfikujący rodzaj serwera DB (np. mysql), host (...)".

Ad. frameworków - to przecież właśnie piszę, że framework to coś więcej, niż MVC. Ponadto warto przykładowy framework stworzyć, aby pokazać, na jakiej zasadzie to wszystko funkcjonuje. Przecież zagadnienie to na dobrą sprawę nie jest trudne, a ponadto nie wszystkim proponowane gotowce muszą przypaść do gustu. Dalej niech sobie już robią, co chcą z tą wiedzą, moim zdaniem jest ona przydatna. --Zyx 10:07, 2 cze 2007 (CEST)

Edytory PHP

Derbeth, można by zablokować stronę PHP/Inne/Edytory_PHP do edycji przez niezalogowanych? Sporo ludzi traktuje to jako darmową reklamę swoich produktów, a zarejestrowanych jest nieco łatwiej kontrolować. Najlepiej, gdyby najpierw opisy nowych edytorów na stronę dyskusji wrzucić i dopiero ktoś z właściwych redaktorów Wikibooks/Podręcznika by je przenosił na właściwe miejsce. --Zyx 14:03, 29 maj 2007 (CEST)

Zrobione. --Piotr ^@ 15:02, 29 maj 2007 (CEST)

mysql_query zamiast bezpośrednich poleceń

Dlaczego w podręczniku czytelnik jest uczony wykonywać MySQLowe polecenia jedynie bezpośrednio bez informacji nt. tego jak to zastosować w PHP (może jest, tylko nie zauważyłem)? Przydałyby się informacje na ten temat. --Sniper89 01:52, 9 lip 2007 (CEST)

Sniper nie troluj przeciez jest to opisane w dziale PDO i (wazniejsze moim zdaniem) jak to sie robilo kiedys.

Moduł "XT - System szablonów"

Wywaliłem linka:

1. XT - System szablonów

ze Spisu treści, był umieszczony przed wstępem do szablonów, nie pasuje mi ten poziom ukończenia... Edytowany jedynie przez IP-ka, sam moduł zostawiłem taki, jaki był. --// Silmethule^@dyskusja 22:30, 20 maj 2008 (CEST)

Zreorganizowany spis treści

Zreorganizowałem trochę spis treści. Główna zmiana polega na przeniesieniu rozdziału Programowanie obiektowe na wcześniejsze miejsce oraz usunięciu nienapisanych jeszcze dalszych części. Ponadto na końcu każdego rozdziału będą znajdować się ćwiczenia. Najlepiej, aby na razie skupić się na dopracowaniu obecnej zawartości, a później myśleć, co i jak opisywać dalej (frameworki, inne biblioteki itd.) --Zyx 12:36, 4 sty 2010 (CET)

---

Dlaczego nie można pobrać książki w wersji epub?

Spis treści - c.d.

Ponieważ rozdział o programowaniu obiektowym jest w końcu prawie gotowy, poniżej przedstawiam propozycję dalszych zmian w spisie treści. Celem ma być przede wszystkim omówienie języka i praktyk programistycznych. Jeżeli będą omawiane dodatkowe biblioteki, to w stopniu zapoznającym, ponieważ o wielu z nich można napisać całkiem obszerne, oddzielne podręczniki. Z istotnych zmian w początkowych rozdziałach pojawi się jedynie "Studium przypadku: galeria zdjęć" w programowaniu obiektowym, która powinna pokazać, jak wykorzystać zdobytą wiedzę do budowy prostej galerii zdjęć.

Tymczasem po obiektówce zaczynamy od Zaawansowane programowanie, w którym znajdą się:

1. Przestrzenie nazw
2. Domknięcia
3. XDebug
4. Wzorce projektowe

Następnie wchodzą bazy danych mniej więcej w obecnym kształcie z dodanym rozdziałem o ORM Doctrine i przebudowane Systemy szablonów.

1. Czym jest system szablonów?
2. Prosty edukacyjny system szablonów - oparty o język PHP
3. Wybrane systemy szablonów:
   • Savant
   • Open Power Template
   • PHPTAL
4. Ćwiczenia

Zasady techniczne doboru bibliotek do podręcznika (by nie było 500 pozycji, z czego jedynie 4-5 ciekawych) podaję niżej. Wybrałem te trzy systemy, aby pokazać dwa zasadnicze podejścia do systemów szablonów: z językiem PHP oraz z dedykowanym językiem. W tym drugim przypadku uważam, że marnowaniem miejsca jest omawianie systemów, które stać co najwyżej na reimplementowanie PHP, stąd odpadają wszelkie systemy "ify, pętle i bawcie się". Zrezygnowałem także z omawiania Smarty'ego ze względu na długi okres zastoju i ogólny anachronizm, który przekreśla 90% rzeczy, które do tej pory były w podręczniku powiedziane (nawet w wersji 3). Uzasadnienie konkretnych wyborów: Savant - przyzwoity system bazujący na szablonach PHP; Open Power Template - popularny w Polsce, wykorzystanie w projektach komercyjnych, prawdopodobnie najbardziej zaawansowany system szablonów świata; PHPTAL - również popularny w Polsce i również z nowoczesnym językiem szablonów.

Kolejnym elementem będą Frameworki:

1. Czym jest framework?
2. Wzorce złożone: MVC, MVP i pochodne
3. Prosty framework edukacyjny
4. Wybrane frameworki:
   • Yii Framework
   • Symfony Framework
   • Zend Framework
5. Ćwiczenia
6. Studium przypadku

Przy tym rozdziale chcę uniknąć sytuacji, gdy pojawią się tu opisy 129283 frameworków. Powinny być one tak dobrane, by pogodzić popularność z prostotą. Dlatego na pierwszym miejscu dałem Yii, który moim zdaniem powinien być w miarę prosty w zrozumieniu dla początkujących, a na końcu Zend Framework jedynie ze względu na popularność, ponieważ początkującym na pewno bym go odradzał. Symfony ze względu na popularność i wykorzystanie Doctrine, który ma być omówiony wcześniej. Rozdziały powinny być skrótowe i pokazywać tylko sposób budowy najprostszej aplikacji, ponieważ wychodzę z założenia, że do bardziej szczegółowych opisów powinny mieć własny podręcznik.

Następnie proponuję rozdział Bezpieczeństwo:

1. Techniki ataków - połączenie istniejących rozdziałów o SQL Injection, HTML injection, PHP injection itd.
2. Zabezpieczanie sesji - rozdział opisujący, jak zabezpieczyć sesje przed atakiem.
3. Bezpieczne zarządzanie danymi - rozdział opisujący, jak zarządzać danymi przetwarzanymi przez system, aby informacje potencjalnie niebezpieczne nie wyciekały z niego
4. Formularze - techniki zabezpieczania formularzy
5. Obrona przed botami - omówienie mechanizmów captcha i baz danych spamerów
6. Mechanizmy uwierzytelniania - jak bezpiecznie uwierzytelniać użytkowników i przechowywać ich dane
7. Mechanizmy kontroli uprawnień - zasady działania systemu kontroli uprawnień
8. Połączenia szyfrowane - tworzenie skryptów korzystających z połączeń szyfrowanych

Ostatni rozdział to Dobre praktyki:

1. Standardy kodowania - czyli dlaczego styl pisania jest ważny
2. Dokumentowanie kodu
3. Testowanie skryptów - PHPUnit

Zasady doboru omawianych skryptów:

1. Przynajmniej rok aktywnego rozwoju
2. Dostępne wydanie stabilne
3. Obecność kompletnej dokumentacji
4. Wsparcie dla PHP 5.2/PHP 5.3
5. Obecność infrastruktury do zarządzania projektem (System kontroli wersji, Bugtracker, forum dyskusyjne dla użytkowników)

Czekam na uwagi i opinie. --Zyx (dyskusja) 08:29, 7 maj 2010 (CEST)

Warto chyba dodać do rozdziału o programowaniu obiektowym podrozdział dotyczący cech (traits).