Allegro.pl

Powiązane (2)

Pokaż: ustaw jako domyślne
pokaż obrazki

Komentarze (75)

  • Reklamy Google

  • paziek +5  

    Nie wiem, czy kodowanie znaków jest takie piękne. Zwłaszcza na stronie, która jest napisana z użyciem UTF-8 jak tutaj.
    Nie rozumiem po co dawać dla body ID? Przecież jest łatwy dostęp z CSS oraz JS do tego elementu bez pomocy ID. Zbędny syf.
    Descriptive blocks po co to komu? Ja używam odpowiednich nazw dla klas, np. "layer-header", "layer-footer" itp. Jeśli coś nie wspiera CSS to raczej nie jest moim "targetem". Jak dla mnie to zbędny syf tworzący jedynie zamieszanie. Pewnie będzie używany podobnie jak obecnie tabelki - niewłaściwie.
    Ten JS na dole... raz autor używa pojedynczych cudzysłowów przy atrybutach, raz podwójnych... do tego, linkowanie JS ze źródła, nad którym się nie ma kontroli? lol
    <=date('Y');> też działa - jak się ma włączone krótkie tagi - i wygląda IMO lepiej.

    Najważniejsze: nigdy nie stosuj czego takiego jak href="/css/main.css" bo możesz się przejechać. Ja zawsze robię projekty w jakimś podkatalogu mojego serwera WWW, na wypadek gdyby finalnie nie był on właśnie w katalogu głównym. Dlatego robi się href="./css/main.css", chyba, że naprawdę chcesz coś relatywnie do głównego i wiesz, że tam będzie.
    Do tego, przy includowaniu w PHP poprawia to wydajność, bo przy składni include("inc/main-menu.php"); interpreter przeszuka też ścieżki z PATH w poszukiwaniu pliku. A jak dasz ./ do ścieżki, to wie, że plik jest tutaj i nigdzie indziej.

    Pewnie się czepiam, ale skoro to jest idealny sposób formatowania kodu HTML 5 to sam się o to prosił :)

    pokaż komentarz
    paziek
  • v1r0x -1  

    z tym / a ./ jest jeden problem - mod_rewrite jak sobie ktos wymysi ze chce /art/costam/123232-costam.html przykladowo, to to ./ bedzie od tego /art/costam/. chyba ze jest jakis prosty sposob zeby nie robic /.

    pokaż komentarz
    v1r0x
  • u43dqe14m3 0  

    href="/css/main.css" ?
    a nie można dać:
    href="css/main.css"

    pokaż komentarz
    u43dqe14m3
  • Brut_all +3  

    @paziek
    O.o Brawo, właśnie Ci się udało tylko w jednym swoim komentarzu zamieścić kilka najbardziej typowych błędów popełnianych przy tworzeniu WWW. I to, o zgrozo, nazwałeś to poprawianiem tego, co właśnie było dobrze, a reszta go jeszcze zaplusowała...

    Nie rozumiem po co dawać dla body ID? Przecież jest łatwy dostęp z CSS oraz JS do tego elementu bez pomocy ID. Zbędny syf.

    Tagi oraz IDki i klasy, to w HTMLu dwa równoległe światy. Tagi służą głównie budowie struktury dokumentu, a do umieszczania na stronie jakichś naszych obiektów, czy ich typów, służyć powinny głównie IDki i klasy. To tak, jakbyś przygotował dla kogoś jakiś dokument na papierze, on by na to spojrzał i powiedział:
    - zrób większą czcionkę
    - w którym miejscu
    - na kartce
    , zamiast powiedzieć, że "dla całego dokumentu". Niby kartka oznacza właśnie cały dokument i wiadomo, o co chodzi, ale dziwnie co najmniej to brzmi, bo kartka i treść na niej zapisana to dwa różne światy.

    A przechodząc od teoretycznego mądrzenia się do praktyki: ok, ostylowałeś sobie wszystko względem body, zaoszczędziłeś 10 bajtów wielkości HTMLa. Teraz się okazuje, że poza rootem strony by wypadało dodać jeszcze jakiś element. I co? Nagle wywracasz w CSSie wszystko do góry nogami, bo już nie możesz stylować względem body.

    Descriptive blocks po co to komu?

    To aż ciężko mi skomentować, bo to są absolutne podstawy podstaw HTMLa. Nie zastanawia Cię czasem, po co w ogóle ta zabawa w dość skomplikowane HTMLy i CSSy, jeśli można to było zrobić dużo, dużo prościej, choćby przesyłać strony w postaci jednej wygenerowanej grafiki (rozmiarowo by nie wyszło tak strasznie gorzej)?

    A co do tabelek w tym samym paragrafie... o ironio, przecież "tabelkowość" polega właśnie na ignorowaniu/niezrozumieniu "descriptive blocks" O.O

    Najważniejsze: nigdy nie stosuj czego takiego jak href="/css/main.css"

    Najważniejsze: zawsze stosuj właśnie linki bezwzględne! Linki względne to wielka pomyłka, bo skrypt musi wiedzieć, skąd dokładnie został odpalony, aby poprawnie wygenerować linki względne. Z tego powodu znacznie utrudnioną robotę mają wszelakie generatory linków (które są zalecane), do tego dochodzą takie problemy, jak właśnie mod-rewrite, itp.

    Najzabawniejsze w tym jest to, że skrypt, który zamieszcza linki, może nie mieć nic a nic wspólnego z pierwszym uruchamianym skryptem. A więc możesz mieć skrypt zaincluduj-pliki-css.php, wszystkie podstrony go będą linkować, ale w zależności od tego, który z nich to zrobi, załączany skrypt będzie musiał zaincludować cssy z innego adresu - katastrofa... Pozostaje tylko analizowanie zmienych z $.SERVER, aby dowiedzieć się, skąd co załączyć.

    Najlepszy rozwiązaniem jest posiadanie generatora linków, a jeśli nie, to tworzenie wszystkich linków w oparciu o zmienną, która wskazuje na bezwzględnego roota strony. Dzięki temu nie będziesz miał problemu z przeniesieniem strony pod inny adres.

    Odnośnie includów w PHPie, to PHP nie jest głównym tematem tego "artykułu". Jeśli już go się czepiać, to i tutaj, jak powyżej, wszystkie inkludy powinny być robione z pomocą jakiejś zmiennej, która zawiera bezwzględną ścieżkę do roota aplikacji. Inkludowanie względem "./" to też jest złyyy pomysł. Poza tym trochę bez sensu jest to, że analytics.php został załączony poprzez include_once zamiast zwyczajnie include, ale jak już pisałem - PHPowe wstawki nie są tu istotne.

    Jedynie z tym UTF8 nie wiem, czemu tak. Zarówno HTML, jak i XML nie mają nic przeciwko unicodom w treści. Być może chodzi o to, żeby każdy edytor to dobrze wyświetlał, choć to bez sensu.

    Aha, faktycznie przy skryptach wstawili apostrofy zamiast cudzysłowów - z tym jednym jedynym się w pełni zgadzam ;-)

    pokaż komentarz
    Brut_all
  • herbstnebel +4  

    Może ja jestem jakiś zboczony, ale nie zakochałem się w tym. Sorry?

    pokaż komentarz
    herbstnebel
  • feuerfest +2  

    Dewiant!

    pokaż komentarz
    feuerfest
  • herbstnebel -1  

    bo pozwę cię do Hagi!

    pokaż komentarz
    herbstnebel
  • Wernest +42  

    Coś pięknego, rozpłakałem się.

    pokaż komentarz
    Wernest
  • MakRojal +1  

    tak przy okazji : HTML NIE JEST językiem programowania ! Jak widzę oferty pracy : "programista html", to robi mi się niedobrze ;/

    pokaż komentarz
    MakRojal
  • Thunderer -2  

    Koder? Pisarz? Klepacz? Jak widzisz, nie ma tak łatwo. ;]

    pokaż komentarz
    Thunderer
  • SasQ +1  

    Front-end developer, webdeveloper... Czasem też używam określenia "szablonista" ;)

    pokaż komentarz
    SasQ
  • nowyurzytkownik +3  

    Przyjmę pisarza HTML.

    pokaż komentarz
    nowyurzytkownik
  • soop2i +4  

    Zatrudnię skrybę hipertekstowego języka znaczników ( hajper-text-markap-langłidż).

    pokaż komentarz
    soop2i
  • sajam +17  

    Mało obiektywne, poza tym do standardu jakim będzie HTML5 jeszcze daleko. Semantyka dobrze zaprezentowana ;-)

    pokaż komentarz
    sajam
  • TEN_LOGIN_MA__DOKLADNIE__35__ZNAKOW +19  

    czyli znów wracamy do mieszania php-a z html?
    Przykład pokazuje prostą podstronę. A co w przypadku dużych serwisów gdzie php były w co 2 wierszu? Chyba lepiej pracować na szablonach

    pokaż komentarz
  • Winhelp +4  

    Składnia systemów szablonów właściwie dubluje PHP. IMO wystarczy odpowiednio to porozbijać na pliki i będzie OK.

    pokaż komentarz
    Winhelp
  • AltumVidetur -2  

    Nie trzeba od razu używać systemu typu smarty, który podmienia funkcjonalności z PHP na inne, ale jeżeli ma być ładnie i czytelnie to lepiej trzymać się architektury MVC - w szablonie tylko wyświetlanie danych - dołączanie i przetwarzanie w innym miejscu.

    pokaż komentarz
    AltumVidetur
  • Rev +6  

    Jak zajmujecie się projektami, gdzie jedna osoba robi wszystko to spoko. Jeżeli pracuje nad nim więcej osób, to po cholerę front-end developer ma się mieszać do warstwy biznesowej?

    pokaż komentarz
    Rev
  • XpedobearX +3  

    Co tu jest takiego nadzwyczajnego? Chyba tylko to, że jest pomieszane trochę z php i cssy pod różne wersje IE

    pokaż komentarz
    XpedobearX
  • DooBLER +5  

    Widzę, że zaczyna się flamewar robić...

    Systemy szablonów są ogólnie trochę wolniejsze od czystych wstawek w PHP jeśli komuś to nie przeszkadza i lubi się bawić takimi rzeczami to spoko.

    Jeśli chodzi o łatwość używania, jeśli ładnie odseparujemy sobie widok w aplikacji i wysyłamy do niego tylko zmienne do wyświetlenia to moim zdaniem stosowanie wstawek PHP wcale nie jest trudniejsze. Każdy webmaster powinien sobie poradzić z ogarnięciem tego.

    Bo jaka jest różnica między pętlą w np Smarty albo PHP? Nie wiem czemu wielu ludzi robiących strony boi się tagów php w kodzie jeśli nawet Zend takie coś zaleca.

    Długi czas używałem Smarty, OPT, phptal, ale potem zacząłem zwracać większą uwagę na wydajność :) Z przestawieniem na takie rozwiązanie, ani ja, ani inni ludzie od html nie mieli problemu.
    ----------------------------------
    A co do samego wykopu, to nic nadzwyczajnego, w sumie jedyna przedstawiona nowość to te opisowe bloki/tagi :)

    pokaż komentarz
    DooBLER
  • IvanBarazniew +4  

    Z kodem php w szablonach są w zasadzie tylko dwa zasadnicze problemy:

    Problem nr 1. BEZPIECZEŃSTWO
    Dajesz szablonowi pełną możliwość wykonania kodu PHP, co z kolei umożliwia mu np eksport konfiguracji na inny serwer lub wypisanie jej na ekran. Problem wydaje się błahy, ale jak weźmiemy pod uwagę ile osób używa cms'ów mających takie szablony to robi się mniej kolorowo.

    Wystarczy, że niedoświadczony user ściągnie szablon niewiadomego pochodzenia zainstaluje w aplikacji i hasła byebye.

    Problem nr 2. Lenistwo programistów
    - jak masz dużą aplikacje i po raz n-ty musisz zmodyfikować jakąś pierdołę, to naprawdę korci, żeby wstawić ten jeden jedyny warunek do szablony, po co od razu modyfikować business-layer skoro to tylko to jedno miejsce. Ani się obejrzysz a połowa aplikacji będzie napisana w szablonach.

    pokaż komentarz
    IvanBarazniew
  • Izotopus -3  

    Szablony tylko i wyłącznie do bardzo dużych projektów... Jeśli ktoś się uprze to może sobie samemu napisać małego-prostego-szybkiego parserka żeby żadnego pehapa czy innego dziadostwa nie było... :)

    pokaż komentarz
    Izotopus
  • Thunderer -3  

    Szablony są bardzo dobrym rozwiązaniem bo istotnie separują widok od reszty skryptu [ja pracuję w PHP] - w przypadku używania samego kodu PHP za bardzo korci do używania różnych skrótów. Ale fakt faktem, że ruch ludzi zaczynających pisać szablony w czystym PHP zdobywa coraz większą popularność, więc trzeba to będzie przemyśleć. Z drugiej strony specjalnie mnie to nie boli, bo mój framework ma całkiem fajną klasę od szablonów i przestawienie się z jednego na drugi sposób pisania zajmie mi praktycznie zmienienie nazwy silnika w klasie zarządzającej. ;]

    pokaż komentarz
    Thunderer
  • prostynick -1  

    Osobiście bardzo polecam PHPTal. Obecnie rozwijany przez Polaka.

    pokaż komentarz
    prostynick
  • feuerfest +1  

    Najlepiej to pracowac w firmie, gdzie programista programuje, a widokami zajmuja sie forntendowcy ;) Bajka :D

    pokaż komentarz
    feuerfest
  • Deathek 0  

    "Wystarczy, że niedoświadczony user ściągnie szablon niewiadomego pochodzenia zainstaluje w aplikacji i hasła byebye."

    Nie rozumiem stwierdzenia "hasła byebye".
    1) Jeżeli ktokolwiek przechowuje w plikach hasła bez żadnego szyfrowania, to traci je na własne życzenie.
    2) Kod php jest wykonywany na prawach użytkownika dla serwera www (np www-data dla apache2) więc wcale nie musi mieć do czegokolwiek dostępu.
    3) Nie wiem o jakie hasła może Ci aktualnie chodzić (root? userzy?) Owszem, nawet MD5 przy odpowiedniej mocy obliczeniowej da się obejść, ale jeżeli dajesz wszystkim użytkownikom dostęp do etc/shadow (bo inaczej user dla serwera www tego nie przeczyta), to po raz kolejny - na własne życzenie.

    Powyżej nie rozpatrywałem problemu serwerów windowsowych, bo z tymi nie miałem nigdy do czynienia, także przyznaje się do kompletnej niewiedzy w tym temacie.

    A co do wyjmowania danych z baz danych na takiej maszynie itp... Cóż - da się, bo gdyby się nie dało, to by się o tym nie słyszało, ale zazwyczaj jest to zwyczajna głupota albo przeoczenie admina - czyli luka w zabezpieczeniach.

    Wracając więc do tematu - wykonywanie jakiegokolwiek kodu po stronie serwera nigdy nie jest bezpieczne, ale nie przesadzajmy - czy będzie to php czy cokolwiek innego, zawsze istnieje ryzyko. W takim razie powstaje pytanie - czysty HTML, czy dobre zabezpieczenia i minimalne ryzyko?

    pokaż komentarz
    Deathek
  • Brut_all 0  

    @Deathek
    Strasznie zacząłeś coś kombinować z kontami użytkowników OSa, a Ivanowi chodziło zapewne o dane samej aplikacji, tzn. hasła do baz danych, ich zawartość, itp.

    Wracając więc do tematu - wykonywanie jakiegokolwiek kodu po stronie serwera nigdy nie jest bezpieczne, ale nie przesadzajmy - czy będzie to php czy cokolwiek innego, zawsze istnieje ryzyko.

    Tylko że wykonując swój kod to my decydujemy, co on ma robić - co najwyżej popełnimy błędy. Wrzucając taki szablon PHP dajemy cudzej osobie pełną kontrolę nad naszą aplikacją, a wielu wrzucających to laicy i nie będą sobie zdawać z tego sprawy, bo "to przecież tylko szablon".

    W takim razie powstaje pytanie - czysty HTML, czy dobre zabezpieczenia i minimalne ryzyko?

    "Dobre zabezpieczenia" to właśnie system szablonów. No chyba, że znajdziesz sposób na odpalenie PHPa pod kontolą innego PHPa (w sumie można odpalić drugi interpreter pod użytkownikiem z jakimiś minimalnymi uprawnieniami - jest sens?).

    pokaż komentarz
    Brut_all
  • Raens +2  

    Było lepsze kiedyś.

    pokaż komentarz
    Raens
  • abc666 +2  

    Ale w tym kodzie nie ma nic pięknego. Ot zwyczajny kod.

    pokaż komentarz
    abc666
  • Thunderer 0  

    Dlatego jest piękny. ;]

    pokaż komentarz
    Thunderer
  • x_O +1  

    Sorry pisze w django :).
    Dzięki takiemu zestawieniu zaczynam rozumieć, że jak poprawny HTML to tylko z PHP :)

    Nie kopcie tego to jest niepoprawne i tendencyjne. Się kurde uparliście :D

    pokaż komentarz
    x_O
  • ravicious -1  

    Ale to chyba nie ma znaczenia? ;-) Jeśli korzystasz z domyślnego markupu, to i tak musisz pisać kod HTML http://docs.djangoproject.com/en/dev/ref/templates/builtins/

    pokaż komentarz
    ravicious
  • Thunderer -3  

    A co ma jedno do drugiego [HTML do PHP]?

    pokaż komentarz
    Thunderer
  • voldenet -1  

    Gówno prawda.
    Dobry HTML nie ma w kodzie zbędnych spacji, zbędnych enterów, cholernie długich id divów i dziesięciokrotnego dublowania rozmiaru obrazka. W ten sposób można oszczędzić sporo transferu.

    Np. gdyby administratorzy niektórych portali zajęli się zmniejszeniem ilości przesłanych danych, to serwery dawałyby sobie radę po południu (mam tu na myśli np. demotywatory.pl, które nie nigdy działają po południu - czasem jak dostaję takiego linka, to ładowanie trwa zbyt długo...).

    Przykładowo link do profilu użytkownika w polu "autor" wygląda tak:
    <a href="http://www.wykop.pl/ludzie/jakieslosowekonto" title="">jakieslosowekonto</a>
    Można by to zamienić na <a href="/ludzie/jakieslosowekonto">jakieslosowekonto</a> i też będzie działało.

    pokaż komentarz
    voldenet
  • DajPlusaBoSiePotne +8  

    Akurat w przypadku demotywatorów pliki html stanowią niewielką część transferu, ale masz rację, nierzadko spacje stanowią połowę transferu strony, a jak ktoś chce sobie pooglądać kod strony, to są narzędzia do robienia wcięć. :p

    pokaż komentarz
    DajPlusaBoSiePotne
  • redliquid +6  

    Dobra stronka powinna być w locie gzipowana w miarę na ile pozwala jej content (i nie mowie tutaj o samym HTMLu, ale równierz CSS oraz JS) - wtedy nawet milion spacji w dokumencie nie spowoduje wysłania zbędnej zawartości. Jeżeli chodzi o trzymanie się powyższej struktury "pięknego formatowania" - czytaj wcięcia, a nie semantyka - to jest ona praktycznie niewykonalna, jeżeli ktoś używa systemu szablonów (np. OPT).

    pokaż komentarz
    redliquid
  • IvanBarazniew +2  

    Gzipowanie stron dodatkowo obciąża serwer. Gzipowanie nie ulega keszowaniu, co powoduje, że dodatkowe obciążenie serwera występuje przy każdym żądaniu.

    Jak masz jedną mizerną maszynę, to lepiej się przyłożyć do zmniejszenia ilości przesyłanych danych poprzez rezygnację ze zbędnych elementów strony, niż posiłkować się gzipem.

    Co do systemów szablonów to można użyć takiego w którym nie ma ani grama php, są tylko tagi określające co gdzie ma być. Można również użyć technologii transformacji xslt.

    Chcecie zobaczyć piękny kod html zajrzyjcie do źródła strony google.com

    pokaż komentarz
    IvanBarazniew
  • Gru 0  

    Po co od razu Gzip, wystarczy zoptymalizować arkusze CSS przed wgraniem na serwer, są gotowe skrypty wywalające wszystko co nie potrzebne (od komentarzy po zbędne spacje), kompresja taka sięga nawet 50%. I nie trzeba do tego mocy obliczeniowych procesora serwerowego do kompresji każdego zapytania. Oczywiście *html także można prze te filtry przepuścić, zawsze to coś, a jak serwis duży to pozwala od razu zaoszczędzić sporo kasy niemal zerowym kosztem.

    Co do to tego html5, to jak div'y sam sobie opisywałem to wiedziałem co jest i jak. Po co specjalne tagi HTML do oznaczenia blogów w stronie? Żebym musiał się uczyć na pamięć nowego kompletu tagów? A co jak będę chciał zagnieździć w 10 innych bloków jeden w drugim? też będą gotowe tagi z poziomu html5? Jeśli nie to po co taki dziwoląg, każdy będzie teraz mieszać tagowanie na poziomie języka z tagowaniem div.ami.

    pokaż komentarz
    Gru
  • feuerfest +53  

    Demotywatory zamulają, bo mają niewydajny kod PHP. Wiem, bo sam go pisałem ;)

    pokaż komentarz
    feuerfest
  • Diabl0 -6  

    W dobie łączy kilka - kilkanaście Mbps u użytkowników oraz łączy 100+ Mbps na serwerze wpływ wielkości plików HTML/CSS/JS ma bardzo niewielki wpływ na ogólną wydajność serwisów.

    pokaż komentarz
    Diabl0
  • Brut_all 0  

    Po co specjalne tagi HTML do oznaczenia blogów w stronie? Żebym musiał się uczyć na pamięć nowego kompletu tagów?

    Tagi są nie tylko dla Ciebie, ale przede wszystkim dla maszyny, która będzie je czytała. Jej nie wystarczy, że wpiszesz coś o blogu w id lub klasie elementu.

    pokaż komentarz
    Brut_all
  • Thunderer -2  

    GZip jest ok, ale trzeba go umiejętnie używać, mi się podoba działanie wtyczki WP Super Cache na blogach WordPressa - otwiera strumień bufora, zapisuje wszystko, gzip i serwuje "static content" z odpowiednimi nagłówkami każdemu kolejnemu userowi. Wydajność++ i użycie bazy--.

    pokaż komentarz
    Thunderer
  • thorga -1  

    Pójdźmy dalej może wywalmy wszystkie tabulacje i entery - swoją drogą znałam takiego jednego filozofa, co pisał wszystko ciurkiem w jednej linii ze względu na transfer...

    Lała bym po mordzie i przeciągała na linie za autem każdego, kto uważa poprawną tabulację i wizualny podział kodu na logiczne bloki za niepotrzebne. Nawet przy dużych serwisach zaoszczędzisz ile? 10MB transferu miesięcznie? Koszt rzędu 20 groszy.

    pokaż komentarz
    thorga
  • MoustacheJoe +3  

    Po zakończeniu pisania "pięknego kodu" można zachować kopię pliku dla siebie, a sam plik wrzucić do "obfuscatora", który eliminuje zbędne znaki + zmienia kod w nieczytelną papkę.

    pokaż komentarz
    MoustacheJoe
  • Brut_all 0  

    @thorga
    Co się dzieje z tym Wykopem... Jednego dnia nie ma tu żadnej kobiety, następnego na pytanie, czy są, zaczynają odpowiadać, a jeszcze kolejnego zaczynają pisać w tematach IT O_o

    pokaż komentarz
    Brut_all
  • Gru +1  

    @ Brut_all
    Literówka... mialo być bloków (kodu) nie blogów.

    pokaż komentarz
    Gru
  • Brut_all 0  

    :-D Faktycznie. Jednak mój komentarz jest wciąż aktualny.

    pokaż komentarz
    Brut_all
  • IvanBarazniew +1  

    U mnie za
    _ echo date("Y");_
    Auto kodu miałby mały opieprz. Pomijam kwestię kodu php w szablonie. Jeżeli autor umieściłby taki kawałek wypisujący rok, załóżmy na górze i dole strony to:
    - po pierwsze niepotrzebnie woła funkcje date() dwa razy - strata wydajności.
    - po drugie naraża skrypt na błąd polegający na wypisaniu dwóch różnych dat - na górze i na dole strony. W przypadku roku sprawa jest mało prawdopodobna, ale niektórzy genialni programiści wypisują w ten sposób aktualny czas.

    pokaż komentarz
    IvanBarazniew
  • Izotopus -1  

    Więc o co chodzi? Wpisywał czas czy rok? Sam sobie odpowiedziałeś...
    Wpisywanie samo echo data("Y") jest jak najbardziej prawidłowe, po co zmienne do tego mieszać? Ze zmiennymi więcej możesz spieprzyć a z data() już nie ....

    pokaż komentarz
    Izotopus
  • IvanBarazniew 0  

    Wszystko zależy od podejścia: jeżeli patrzysz na ten kod jako na kod ładnej stronki z aktualną datą wypisaną za pomocą php to może i to date("Y") jest na miejscu, ale:

    Jeżeli php jest użyty tylko do wypisania tej nieszczęsnej daty, to już lepiej byłoby go wcale nie używać - uruchamianie interpretera języka tylko po to aby wypisać coś co się zmienia raz na rok jest bezsensem. Lepiej byłoby zatrudnić demona cron do modyfikacji daty raz w roku.

    Jeżeli php jest używany do czegoś jeszcze np - przygotowuje kontent itp, to mamy do czynienia z aplikacją, czyli zmienne i tak tam będą. Poza tym co by człowiekowi szkodziło na zrobienie stałej CURRENT_YEAR inkludowanej do każdej z podstron (jeżeli już chcemy łączyć php z html).

    pokaż komentarz
    IvanBarazniew
  • Thunderer 0  

    Nie no porażką jest w ogóle liczenie / tworzenie czegokolwiek w trakcie wyświetlania szablonu. To tak jak na konferencji. Twoja wiedza to model, Twoje doświadczenie to kontroler, Twoja prezentacja to widok. Co prawda używasz swojej wiedzy podczas mówienia na temat prezentacji, ale to powinno być już dawno przemyślane przez kontroler i zapisane na kartce jako program wykładu. Podczas niego tylko "wyświetlasz" wcześniej przygotowane informacje.

    pokaż komentarz
    Thunderer
  • Izotopus 0  

    Ale w tym przypadku był używany pehap nie tylko do wyświetlania daty.... Wiadomo dla samej daty można sobie wymyślić 1000 innych sposobów.
    Powiedzmy sobie szczerze... Nie istnieją strony www które nie używają żadnych języków skryptowych...

    pokaż komentarz
    Izotopus
  • ravicious -1  

    Hm, ja już od dawna jakiekolwiek widoki piszę w Hamlu - http://haml-lang.com/

    Nie muszę pamiętać o domykaniu tagów, a jedynie o wcięciach, przez co kod jest ładnie formatowany i czytelny.

    Jeśli ktoś akurat w Ruby nie pisze, to jest oczywiście coś dla PHP http://phphaml.sourceforge.net/

    pokaż komentarz
    ravicious
  • Strumien_Objetosci -2  

    Nie rozumiem tych literek :(

    pokaż komentarz
    Strumien_Objetosci
  • Axelio 0  

    Do kompletu polecam też zajrzeć do tego Wykopu:
    http://www.wykop.pl/link/127903/piekny-i-prawidlowy-kod-html

    pokaż komentarz
    Axelio
  • Brydzo -2  

    Błąd w opisie:
    How/What beautiful HTML looks like.

    pokaż komentarz
    Brydzo
  • pies_harry 0  

    Ja mam problem szablonów rozwiązany tak: używam frameworka który dopuszcza jedynie szablon będący czystym HTML-em. W zasadzie składnia szablonu musi być identyczna z HTML-em, żadnych innych elementów. Jak mam wrzucić gdzieś jakąś generowaną treść - namierzam po ID. Dość podobne rozwiązanie do phptal, tylko że więcej automatyki.

    W takim układzie nie ma w ogóle możliwości pomieszania kodu z szablonem, ani prezentacji z logiką. Tego się po prostu nie da zrobić. Moduł przetwarzający HTML-a po prostu nie wciągnie PHP-a ani JS-a z szablonu. Tak samo jak nie wciągnie błędów w HTML.

    pokaż komentarz
    pies_harry
  • Thunderer 0  

    Co to za framework? Jakiś wewnętrzny, czy ogólnie dostępny?

    pokaż komentarz
    Thunderer
  • SasQ 0  

    Podobnie działa XT, czyli XHTML Templates.
    http://neo.infeo.pl/xt/
    I rzeczywiście jest to świetne rozwiązanie do szablonów HTML. Tylko co z szablonami np. e-maili, zapytań do baz danych, czystego tekstu, PDFów i formatów nie opartych na SGML? Jak sobie z nimi radzisz?

    pokaż komentarz
    SasQ
  • Brut_all 0  

    Ja np. TALem generuję CSSy - nie ma z tym żadnego problemu, bo TAL wymaga, aby plik źródłowy był XMLem, wynikowy wcale nie musi.

    Oczywiście do takich typów plików lepsze byłoby coś nie nastawione na XML, ale jeśli nie masz dużych wymagań, to nie będzie z tym problemu.

    EDIT:
    Ok, przeczytałem wcześniejsze posty i zauważyłem, że wcisnąłem się trochę bez sensu...

    Domyślam się, że ta biblioteka pozwala się poruszać po HTMLu w postaci jakiegos DOMa, czy cuś? W takim razie powinno być możliwe generowanie każdego typu dokumentu, który będzie można sprowadzić do postaci DOM. Jeśli tak, to z generowaniem prostego tekstu może być problem :-)

    pokaż komentarz
    Brut_all
  • vvooki -6  

    Ładny kod... faktycznie... ale czy wszystkie rzeczy są użyteczne i tak na prawdę potrzebne to nie jestem przekonany...

    pokaż komentarz
    vvooki
  • vvooki -1  

    Przecież i tak każdy szanujący się programista po zamknięciu projektu używa kompresji kodu... (jeśli jest to na tyle duże przedsięwzięcie, że tego wymaga). Dla wersji roboczych uważam, że jest ok.

    pokaż komentarz
    vvooki
  • MrGrandma -4  

    Jak ma byc piekny, skoro napisany Comic Sansem? Zakop, informacja nieprawdziwa.

    ;)

    pokaż komentarz
    MrGrandma
  • feuerfest +5  

    Gdzie wy tam widzicie comic sans? Nie moge wypatrzyć.

    pokaż komentarz
    feuerfest
  • bkozal +3  

    Ta czcionka nazywa się Monaco.

    pokaż komentarz
    bkozal
  • feuerfest +1  

    I jest domyslnie zainstalowana w Maczkach. Uzywalem jej w swojej pracy dopoki nie odkrylem Panic Sans :)

    pokaż komentarz
    feuerfest
  • MrGrandma -4  

    Gdzie wy tam widzicie comic sans? Nie moge wypatrzyć.

    My babcie mamy tak, ze widzimy wszystko :-3

    pokaż komentarz
    MrGrandma
  • Syntax -4  

    Hmm... Comic Sans :)

    pokaż komentarz
    Syntax
  • 3ddy -1  

    gdyby każda strona tak wyglądała :)

    pokaż komentarz
    3ddy
  • zly_czlowiek -5  

    "Piękny kod" kojarzy mi się z ludźmi używającymi iMac'a :P Oni muszą mieć wszystko 'piękne'...

    pokaż komentarz
    zly_czlowiek
  • Brut_all +5  

    Nie myl ulizanego wyglądu z perfekcjonizmem zawodowym ;-)

    pokaż komentarz
    Brut_all
  • Thunderer -3  

    Dobre podsumowanie. ;]

    pokaż komentarz
    Thunderer
  • feuerfest -2  

    Tylko iMaca? A co z userami Mac mini, Mac pro, MacBook, Macbook pro? :P

    pokaż komentarz
    feuerfest
  • lastof 0  

    Akurat mnie się przez ASIDE i pozostałe rzygać chce. Oczywiście section i wiele innych są bardzo przydatne. Natomiast wszystkie elementy definiujące położenie, to chyba pomyłka.

    pokaż komentarz
    lastof
  • lastof 0  

    Ten DTD nieco przypomina DTD dla trybów prawie standardowych ;-) .

    pokaż komentarz
    lastof
pokaż 

Wykopali i zakopali (367 / 58)