[PHP] Jak pisać ?

0

Witam
Przymierzam sie do napisania na potrzeby pracy inż. interfejsu WWW do zarządzania serwerem dostępowym Linux.

Mam pewną wiedzę odnośnie sieci komputerowych i Linux'a, bo to główny cel mojej pracy i specjalizacja moich studiów jednak interfejs WWW ma być integralną częścią pracy i również tą jej część mam zamiar stworzyć w sposób maksymalnie zbliżony do ideału.

Pytanie jak pisać ...nowocześnie, wydajnie, bezpiecznie i według standardów ?

Rozumiem, że od strony wyświetlania zawartości stron to powinien to być :
xml 1.0
Xhtml 1.1 (xhtml 1.0 Strict)
CSS 2.0
(DOM)

Powiedzmy, że o to się nie boję bo są standardy W3C i validatory,
jednak do tego na 100% zostanie użyty PHP 5.x i SQLite 3.x
i pytanie :
czy są jakieś ogólnoświatowe konwencje pisania kodu ? komentowania ? walidacji ? testowania ?

Czy w takiej aplikacji powinno się skorzystać z jakichś wspomagaczy jak szablony Smarty ?
Czy w ogóle to już jest na tyle złożona aplikacja, że należało by pisać obiektowo, a nie strukturalnie ? Może praca inż. obliguje do pisania każdej aplikacji w PHP obiektowo ?

Czy to na tyle złożone przedsięwzięcie, że powinienem zainteresować sie CVS lub SVN ?

Nie liczę na wykład, a jedynie na uwagi i wskazówki oraz krytykę popartą argumentami.

Z góry dziękuję i pozdrawiam ;-)

0

Co do języka znaczników to zastanów się nad sensownością użycia XHTML-a. Czy da Ci on jakąś przewagę w stosunku do HTML-a 4.01 (Strict)? Z poprawnym użyciem XHTML-a są problemy; większość przeglądarek traktuje kod napisany w XHTML-u jako HTML z błędami. Więcej o tym pisał porneL. A może chciałbyś się popisać i użyć HTML-a 5? Niektórzy stosują go już w kodzie produkcyjnym. Jest z tym kilka problemów, ale da się je ominąć (głównie chodzi o to, że trzeba trochę wspomóc IE). XHTML został praktycznie zarzucony, HTML leci dalej.

Jeśli chodzi o arkusze stylów, to nie używaj CSS 2.0, tylko CSS 2.1. Jest kilka dość drobnych różnic, ale w technicznej pracy powinno zwracać na takie rzeczy i pisać o właściwej wersji (2.1).

Komentowanie i testowanie kodu to w zasadzie rzecz odnosząca się do każdego języka programowania. W sumie wszędzie robi się to podobnie. Np. komentarz "inkrementacja i" lub "zwiększanie liczby wolnych slotów o 1" zaraz nad linią "num_free_slots++" jest kretyński i zły. Jest takie coś jak standardy oparte na Javadoc (Javadoc dotyczą Javy). To dotyczy nie tyle komentarzy, tylko dokumentacji, czy może tworzenia specyfikacji API. PHP też ma "swój Javadoc" o nazwie... PHPDoc :). Polega to na tym, że przed każdym publicznym polem/metodą/funkcją piszesz specjalny komentarz, a w nim -- postępując wg ściśle określonych reguł -- opisujesz powiedzmy jakie argumenty przyjmuje funkcja, co robi, jakimi rzuca wyjątkami i jakie zwraca wartości.

Jeśli chodzi o testy, to zastanów się nad częstym i gęstym korzystaniem z testów jednostkowych (ang. unit tests). Są do tego specjalne frameworki w tzw. architekturze XUnit. Dla Javy jest JUnit, a PHP ma... PHPUnit. Fajne jest to, że we wszystkich frameworkach XUnit nazwy klas, funkcji itp. są niemal identyczne. Jest niezła (i zwięzła!) książka o testach jednostkowych: http://helion.pl/ksiazki/junit.htm. Co prawda niby jest o JUnicie, ale to praktycznie nie ma znaczenia dzięki podobieństwu wszystkich XUnitów. Zresztą książka skupia się nie tyle na JUnicie, co pisaniu dobrych testów jednostkowych.

Możesz wręcz pokusić się o skorzystanie z tzw. Test-Driven Development, czyli technice zarządzania projektem opartej na testach. Wygląda to tak, że najpierw myślisz nad jakąś nową funkcją i piszesz jej sygnaturę (tj. pustą funkcję), a następnie nie rzucasz się do jej implementacji, tylko piszesz dla niej testy. Zastanawiasz się, jakie warunki powinna spełniać ta nowa funkcja: jakie ma zwracać wartości, jak ma reagować na różne argumenty. Potem sprawdzasz, czy funkcja przechodzi testy -- oczywiście powinna oblać je wszystkie, bo jeszcze nie jest zaimplementowana. Dopiero teraz implementujesz funkcję mając już dobry pomysł na to, jak ma działać i jakie niebezpieczeństwa mogą na nią czyhać. Gdy zakodujesz ją tak, że przechodzi wszystkie testy, to voilla -- skończone! Oczywiście testować możesz nie tylko funkcje, ale wręcz całe obiekty (choć jeden test powinien testować jak najmniejszy fragment interfejsu).

SVN/CVS... cóż, kontrola wersji mogłaby Ci pomóc, ale gdy ja robiłem samodzielne projekty dyplomowe, to ją olewałem. Nie był to duży problem, ale taki SVNik pewnie byłby nawet pomocny. Pracę inżynierską pisałem zespołowo i tam już korzystaliśmy z kontroli wersji.

Czy używać szablonów i obiektowości, to zależy trochę od rozmiaru PHP-owej części projektu. Jeśli będzie całkiem spory, to możesz wręcz skorzystać z jakiegoś lekkiego frameworka. Zend Framework albo taki Code Igniter mogłyby się przydać. Tak czy siak powinieneś oddzielić logikę od samych widoków, ale do tego nie jest konieczne Smarty -- od biedy wystarczy samo PHP.

0

Zaskoczyłeś mnie tak wyczerpującą i jasną odpowiedzią.

Choć co do XHTML hmmm widzę, że nie jestes webasterem z pierwszej łapanki ale jestem po kilku poradnikach internetowych i wykładach na temat technik webowych -tam dowiedziałem sie czegoś zupełnie innego. XHTML -przyszłość (mimo, że zarzucili 2.0 z tego co mi wiadomo), a HTML jest przeżytkiem mimo, że wystartowała wersja 5.0 . To wszystko dlatego by "strony WWW" były jednolite co do formy z wieloma innymi XML'owymi dokumentami....

Jeszcze raz dziękuję

0
Autor_inż napisał(a)

widzę, że nie jestes webasterem z pierwszej łapanki

Nie bardzo rozumiem. Jeśli Cię to interesuję, to mam formalne wykształcenie informatyczne na dobrej uczelni i zawodowo programuję głównie w branży webowej. Jestem raczej gościem "od zadań specjalnych", tj. pracowałem na stanowisku starszego specjalisty (senior webdeveloper), współpracowałem z dobrymi agencjami i wybierano mnie do napisania więcej niż jednej strony firmowej agencji interaktywnych. Siłą rzeczy ze statusem Sieci nie tyle staram się być na bieżąco, co muszę być.

Z tym XHTML-em to wybór należy do Ciebie. Ostrzegam tylko lojalnie, że mogą być z tym pewne problemy. Z jednej strony natury formalnej, z drugiej -- praktycznej, kompatybilnościowej. Ważną duperelą jest to, jakim typem MIME oznaczasz pliki XHTML. Niestety, same publikacje W3C zdają się być ze sobą wewnętrznie sprzeczne. Wg specyfikacji nie ma przymusu (choć jest wyraźne zalecenie), by wysyłać XHTML z typowo "XML-owym" typem MIME. Wg innych ich dokumentów trzeba jednak tak robić. Specyfikacja jest tu jednak niby ważniejsza... gdyby nie to, że twórcy przeglądarek (i to nie tylko staroci) się do niej nie stosują.

Jasne, kompatybilność z dokumentami XML. Boo-hoo. Może i fajna idea (choć niekoniecznie). Wykładowcy od eksploracji danych / eksploracji zasobów Internetu, którzy mówią, że to absolutna przyszłość, zdają się jednak być oderwani od rzeczywistości. Nie sądzę, by ktokolwiek -- nawet z tytułem doktora popartym wielką inteligencją i wspaniałymi wynikami pracy naukowej -- mógł zignorować to, co się dzieje w Sieci i powiedzieć, że to nie ma znaczenia, bo i tak będzie tak, jak on mówi. Znaczy -- powiedzieć to sobie można wszystko. Ale tylko tyle. Nie trzeba tego od razu kupować.

Parsery XML. Twoi wykładowcy na pewno wiedzą -- Ty pewnie też -- jak bardzo są restrykcyjne. Jak bardzo sam XML jest restrykcyjny. 1 rypnięty tag -- i koniec, wylatujesz. Yellow screen of death. Parser MUSI w takim wypadku przerwać parsowanie i wyświetlić błąd. Strona jest niedostępna.

Ty prawdopodobnie utworzysz poprawnie sformowany dokument X(HT)ML. Dobrze dla Ciebie. Ba, może nawet pokonasz wszystkie problemy i zapodasz go z dobrym typem MIME itd. I zrobisz to tak, że stare przeglądarki też to łakną. Pogratuluję Ci, bo nie jest to aż tak łatwe.

Ale jak to się ma do naszej sieciowej, gównianej rzeczywistości? Wiesz jaki procent witryn jest poprawnych, przechodzi walidację? (łagodną walidację HTML, czy nie tak restrykcyjną jak być powinna walidację XHTML) Odpowiem Ci: przytłaczająca większość witryn sieci się NIE waliduje! Większość to grubo ponad 90%. Może 95%, dawno nie sprawdzałem statsów.

Gdyby wszystkie strony były pisane w XHTML-u, to nagle 95% Internetu po prostu przestałoby działać z powodu błędów. Zauważ, że ten cały X(HT)ML w dokumentach stron www ma wielki potencjał dopiero gdy praktycznie cała Sieć będzie w ten sposób pisana. Bo jeśli odsetek dokumentów XHTML będzie wynosił 5%, to każdy parser XHTML będzie w stanie przetworzyć tylko 5% Sieci. Przypomnijmy, że dla parsera XHTML dokumenty niepoprawnie sformowane są całkowicie nieprzydatne -- ich treść jest praktycznie niewidoczna.

Tymczasem większość stron www została stworzona przez nieprofesjonalnych, niewykwalifikowanych (X)HTML-owych ignorantów. To, co widzę w kodzie większości stron woła po prostu o pomstę do nieba. Ludzie, którzy pisali większość stron w ogóle nie mieli pojęcia o tym, co robią!

Niektórzy mówią, że o to właśnie chodzi. Że w Internecie jest wolność. Każdy może tanim kosztem sklecić coś na pałę z tutoriala i wrzucić to w Sieć. Doprawdy, przyznaję rację, że widziałem już strony ze wspaniałą treścią i koszmarnym kodem. Gdyby nagle zabronić wprowadzania do Sieci niepoprawnego kodu, prawdopodobnie szybko stałbym się (podobnie jak inni koderzy, którzy chociaż w miarę wiedzą co robią!) całkiem bogaty :). Ale Sieć sporo by na tym straciła.

A jeśli w Sieci nadal pełno byłoby witryn niedostępnych dla (prawdziwych, zgodnych z XML) parserów XHTML -- niedostępnych czy to z powodu błędów, czy to tego, że były napisane w zwykłym HTML-u -- to jaka jest przewaga XHTML-a? Mieszanie znaczników HTML np. z MathML? Błagam, ile witryn naprawdę zaimplementowało coś takiego? Łatwość parsowania? OK, można łatwiej parsować... 5% Sieci. A w pozostałych przypadkach i tak trzeba parsera HTML.

Jeszcze jedna drobnostka. HTML5 skupia się bardziej na zdefiniowaniu abstrakcyjnego drzewa węzłów. Czyli, w uproszczeniu: masz element o nazwie "html", w nim jeden element "head" i jeden "body". Serializacja tego, czyli zapis w formie ciągu znaków, to osobna sprawa. HTML5 definiuje różne sposoby serializacji. Właściwie to dwie różne składnie, bo oprócz serializacji chodzi również oczywiście o parsowanie.

Jedna z nich to normalna składnia "HTML". Druga z nich to składnia... "XHTML". 'nuff said!

PS. Wybór jest Twój. Ja Ci nawet nie mówię, że masz użyć HTML (choć ja bym użył HTML5, żeby się popisać i żebym nie musiał przeklejać DOCTYPE-a :P). Staram się jednak (czasem) walczyć z tym "irracjonalnym uwielbieniem dla XHTML", z którym walczył porneL. Racjonalne uwielbienie, gdy XHTML rzeczywiście się dla nas sprawdza i gdy stosujemy go poprawnie i porządnie, jest moim zdaniem jak najbardziej OK. Nie widzę nic złego w tym, że ktoś wrzuci do Sieci poprawny dokument X(HT)ML. To nawet fajne. Ale gdy zrobi to źle, to należy mu się kop w tyłek, bo porywając się na XHTML jakby sam się zadeklarował, że błędu na pewno nie popełni!
To się rozpisałem. Po więcej ogólnych informacji mogę Cię jedynie odesłać do innych źródeł (jakichś artykułów, czy coś), bo moje długie i mało składne posty na ten temat nie są aż tak pożyteczne, byśmy obaj tracili na nie czas :).

0
Prawie inż. napisał(a)

Witam
Przymierzam sie do napisania na potrzeby pracy inż. interfejsu WWW do zarządzania serwerem dostępowym Linux.

sa juz takie systemiki, chociazby cpanel

Prawie inż. napisał(a)

Pytanie jak pisać ...nowocześnie, wydajnie, bezpiecznie i według standardów ?

inznieria oprogramowania sie klania

Prawie inż. napisał(a)

Rozumiem, że od strony wyświetlania zawartości stron to powinien to być :
xml 1.0
Xhtml 1.1 (xhtml 1.0 Strict)
CSS 2.0
(DOM)

imho webgui i html/xhtml to najmniejszy z twoich problemow, lepiej sie zastanow w jaki sposob to ma dzialac, jak ma byc zabezpieczone jak uruchamiac systemowy soft wymagajacy suid i pobierac wyjscie, jak parsowac to wyjscie aby bylo w ogole co wyswietlac na stronie

Prawie inż. napisał(a)

Powiedzmy, że o to się nie boję bo są standardy W3C i validatory,
jednak do tego na 100% zostanie użyty PHP 5.x i SQLite 3.x

SQLite nie nadaje sie do duzych aplikacji, zastanow sie najpierw co bedzie wymagalo bazy danych i jak bardzo bedzie to obciazony element systemu

Prawie inż. napisał(a)

czy są jakieś ogólnoświatowe konwencje pisania kodu ? komentowania ? walidacji ? testowania ?

raz jeszcze inzynieria oprogramowania

Prawie inż. napisał(a)

Czy w takiej aplikacji powinno się skorzystać z jakichś wspomagaczy jak szablony Smarty ?

jak napisalem wyzej warstwa widoku to w tej chwili najmniejszy z twoich problemow, imho smarty ssie

Prawie inż. napisał(a)

Czy w ogóle to już jest na tyle złożona aplikacja, że należało by pisać obiektowo, a nie strukturalnie ? Może praca inż. obliguje do pisania każdej aplikacji w PHP obiektowo ?

tak taka aplikacja powinna byc napisana obiektowo z wykorzystaniem wzorcow projektowych

Prawie inż. napisał(a)

Czy to na tyle złożone przedsięwzięcie, że powinienem zainteresować sie CVS lub SVN ?

jak najbardziej

0

Jestem pełen podziwu dla Ciebie bswierczynski, masz posty długości artykułów :-)

Zacznijmy od tego HTML-a i XHTML-a - ja wolę XHTML. Ale z czystej mojej własnej chęci - wolę jak mnie coś pilnuje, jak muszę dbać o kolejność tagów, zamykanie i tym podobne, XML-owe nawyki mam. I bezczelnie piszę w XHTML 1.0, a serwuję z typem text/html, specyfikacja mówi, że się POWINNO wysyłać inaczej. Gdzie "POWINNO" jest w jakimś RFC powiedziane, że można odstąpić, o ile istnieją ważne okoliczności - brak obsługi application/xml+xhtml przez nIEktóre przeglądarki to chyba ważna okoliczność, prawda? Ale to dygresja.

IMO najważniejsze w przypadku pisania warstwy prezentacji (czyli tego, co leci do klienta) jest podzielenie tego. Na treść (HTML, XHTML, XML - bez znaczenia w zasadzie), wygląd (CSS) i zachowanie (JavaScript). Rozdział naprawdę ułatwia zmiany (choć nie zawsze) - warto też by to, co najistotniejsze - treść - dało się spokojnie odczytać, jeśli nie będzie CSS, nie będzie JavaScriptu, przeglądarka będzie na telefonie i tym podobne.

Od strony zaplecza - ja piszę częściowo obiektowo, a do tego uwielbiam podział (znów) na warstwy - widok, model, kontroler. Widok wyświetla, model zwraca dane, których potrzebuję, kontroler patrzy, co użytkownik chce, pobiera co trzeba i zwraca do widoku, który leci do klienta. Są tony frameworków MVC (Kohana, CodeIgniter, Zend, Trax...), ale nie musisz z nich korzystać - zasadniczo warto tak naprawdę rozdzielić po prostu widok i kontroler. Smarty? Ja lubię. Znacznie bardziej od takiego PHP-owego kodu widoku, jak we frameworku CodeIgniter czy Kohana jest standardowo (albo w szablonach Wordpressa) - ten jest dla mnie nieczytelny.

Co do tej obiektowości - o ile trudno może ją być osiągnąć w kodzie kontrolera, o tyle nic nie stoi na przeszkodzie, by się dobierać do bazy danych bardziej obiektowo - istnieje coś, o nazwie ORM, mapowanie relacyjno-obiektowe. Parę frameworków PHP zapewnia to w standardzie, chodzi o posługiwanie się tabelami i danymi z tabel bazy jako obiektami.

czy są jakieś ogólnoświatowe konwencje pisania kodu ? komentowania ? walidacji ? testowania ?

PHP samo w sobie jest na tyle niekonsekwentne... ale konwencję się klarują. Możesz przejrzeć zalecenia pisania kodu dla projektu PEAR czy frameworka Zend.
bswierczynski wspomniał o komentarzach PHPDoc - stosuję, mimo iż dokumentacji nie generuję potem.

SVN/CVS? Może niekoniecznie. Możesz zainteresować się Mercurialem (czyli hg). Nie trzyma repozytorium gdzieś na zewnętrznym serwerze (który trzeba mieć), ale u Ciebie na dysku - można cofnąć zmiany, zobaczyć różnice, a nawet robić statystyki kodu, jeśli to potrzebne. Do tego pozwala na synchronizację repozytoriów pomiędzy komputerami - ja na przykład piszę raz na komputerze stacjonarnym, a raz na laptopie - do tego synchronizuję z serwerem (którego nie musi być ;-)) co daje mi nie dość, że mam aktualną kopię roboczą wszędzie, to jeszcze mam kopię zapasową :-) A właśnie, RÓB KOPIE ZAPASOWE.
Stosowałem CVS bardzo długo, teraz na wszystkich projektach mam Mercuriala obsługiwanego przez program TortoiseHg.

Jedna ważna uwaga - planowanie. Gardziłem UML-em, przypadkami użycia, diagramami sekwencji i takimi tam, nadal nie lubię. Ale diagram klas, diagram ERD dla bazy danych, wylistowanie sobie, co program ma robić... polecam, przydatne :-) Ewentualnie możesz też spróbować rozplanować sobie co będziesz robił i kiedy, do kiedy masz termin. Jak wspomniał cepa - inżynieria oprogramowania, zarządzanie projektami, ważna sprawa.

A sam teraz powinienem już zacząć pisać moją pracę magisterską, a na razie tylko plan w Project jest. Może go wydrukuję i nad łóżkiem powieszę?

1 użytkowników online, w tym zalogowanych: 0, gości: 1