Podstrony
- telcocafe
- [PHP+MySQL] Problem z połączeniem mysqli('localhost', 'xxx', 'xxx', 'xxx'
- [PHP] Wyrażenia regularne. Zamienić name="info_imie" na name="{info_imie}"
- [php] Dodanie textu do pliku. Problem... :) POMOCY!!!!!!!!!!!!!
- [PHP] Skrypt cenzury Chcę cenzury!!!
- Dobre programy do edycji php Dobre programy do edycji php
- [PHP] podział na strony php: podział na strony
- [PHP i MySQL] jak pobrac liczbe rezultatow Jak pobrac liczbe rezultatow???
- jak zrobic aktualizacje php? pomocy!!!!!
- Błąd w PHP-Fusion pomocy !!!!!
- Daczego nie dziala?? skrypt php nie chce działać!!!
- zanotowane.pl
- doc.pisz.pl
- pdf.pisz.pl
- ciaglawalka.pev.pl
telcocafe
Niektórzy zwracają uwagę, że kod PHP powinien być oddzielony od HTML. Tylko jak to rozumieć? Szablony dla każdego modułu?- lartykuł, plik, obraz, nowość itp. (z tym się zgadzam)
llprywatne wiadomości - trochę skomplikowane, bo kod HTML jest w pliku, który wyświetla listę folderów, pobiera ilość wiadomości należących do zalogowanego użytkownika i dołącza podmoduł (np. redagowanie, wyświetlanie) - to znaczy, że powinny być dołączane jeszcze 2 pliki wyglądu?
llwstawki - np. link do profilu użytkownika bądź do innych podstron - myślę, że tego nie trzeba oddzielać
llkomentarze, nowości, lista plików, artów, użytkowników - tu trzeba albo pętlę FOREACH w szablonie z dozwolonym kodem PHP, albo odczytać szablon funkcjami file_get_contents() i str_replace(), co uniemożliwi użycie kodu PHP (chyba, że zastosuję system szablonów - najlepiej własny)
lledycja danych użytkownika, itp. - podobnie jest w PhpBB
llpanel administracyjny - tu chyba nie ma wielkiej potrzeby na oddzielenie kodu PHP od HTMLl
A. Czy oddzielenie kodu HTML od PHP we wszystkich modułach jest bardzo istotne?
B. Czy odczyt danych powinien następować przed wysłaniem do przeglądarki znacznika <html>? Aktualnie robię to tylko dla kategorii oraz artów, plików, obrazów, stron informacyjnych, aby móc zmienić tytuł <title>.
Chciałbym poznać Waszą opinię na ten temat. Może jeszcze dokonam zmian, bo to dopiero początek tworzenia kolejnej wersji skryptu.
Użytkownik Ferrari edytował ten post 21 czerwiec 2007, 10:34
A. Czy oddzielenie kodu HTML od PHP we wszystkich modułach jest bardzo istotne?
Tak
Niektórzy zwracają uwagę, że kod PHP powinien być oddzielony od HTML. Tylko jak to rozumieć? Szablony dla każdego modułu?
B. Czy odczyt danych powinien następować przed wysłaniem do przeglądarki znacznika <html>? Aktualnie robię to tylko dla kategorii oraz artów, plików, obrazów, stron informacyjnych, aby móc zmienić tytuł <title>.
poczytaj o szablonach z dziedziczeniem
na przykładzie "prywatnych wiadomości". U siebie mam logikę widoku:
############################## # Send messages - emails ############################## class PMessage(forms.Manipulator): def __init__(self): self.fields = (forms.TextField(field_name="subject", length=30, maxlength=200, is_required=True), forms.LargeTextField(field_name="contents", is_required=True),) def send_pmessage(request, target_user): if request.user.is_authenticated() and str(request.user) != str(target_user): ruser = User.objects.get(username=str(target_user)) manipulator = PMessage() if request.POST: new_data = request.POST.copy() errors = manipulator.get_validation_errors(new_data) if not errors: manipulator.do_html2python(new_data) from django.core.mail import send_mail send_mail(new_data['subject'], new_data['contents'], request.user.email, [ruser.email], fail_silently=False) return HttpResponseRedirect("/user/") else: errors = new_data = {} form = forms.FormWrapper(manipulator, new_data, errors) return render_to_response('userpanel/pmessage.html', {'form': form}) else: return HttpResponseRedirect("/user/")
Jak widać brak kodu HTML, natomiast kod używa określonego szablonu, do którego przekazuje dane jakie mają zostać w nim wyświetlone:
{% extends "pages/body.html" %} {% block content %} <h2>Wyślij prywatny email</h2><form action="." method="post"> <div class="content"> <table> <tr class="rowA"> <td class="first" style="width:25%;"><b>Temat</b></td> <td>{{ form.subject }}{% if form.subject.errors %}<br />*** {{ form.subject.errors|join:", " }}{% endif %}</td> </tr> <tr class="rowB"> <td><b>Treść</b></td> <td>{{ form.contents }}{% if form.contents.errors %}<br />*** {{ form.contents.errors|join:", " }}{% endif %}</td> </tr> </table> </div> <div class="box"><br /><div style="text-align:center;"><input type="submit" value="Wyślij"></div><br /></div> </form> {% endblock %} {% block crumb %}<a href="/">Home</a> > <a href="/user/">Panel Użytkownika</a>{% endblock %}
System szablonów django, jak wiele innych obsługuje dziedziczenie. Zawartość podanych powyżej bloków zostanie wstawiona do szablonu głównego w określone miejsca, a całość zostanie zwrócona klientowi jako wynik :) gotowa strona.
Z punktu widzenia CMSa z systemem skór należy tak to poukładać by różne skóry dostarczały jedynie szablon główny oraz CSS - kod stosowany w podrzędnych szablonach musi być zunifikowany, tak by CSS skórki mógł je "stylować" (a nie żeby skórka składała się z 50 plików) przykład CSS - punBB, antyprzykład: PHP-Fusion - układ strony (HTML) zagnieżdżony w kodzie, a skórki mogą wpływać wyłącznie na podstawowy wygląd.
Użytkownik Riklaunim edytował ten post 21 czerwiec 2007, 13:00
Najprawdopodobniej podzielę pliki wyglądu na skórki (szablon główny, CSS, pliki graficzne) oraz pliki struktury stron ("widoki") np. dla artykułu, itd. Ikony niezwiązane z layoutem może też będą osobno.
Fakt, że to bardzo ułatwi pracę np. grafikom, ale tego kodu PHP nie może być dużo. Problem tu stanowi iteracja w modułach typu: news, lista plików, itp. Jak trzeba, to trzeba. I tak na końcu pewnie utworzę wtyczkę kompilującą szablony z {var} itd. do plików z kodem PHP. Przemyślę to jeszcze i zabieram się do dalszego tworzenia skryptu.
Będą też uniwersalne pliki wyglądu - np. dla list artów, plików, linków... albo list samych tytułów zawartości.
Użytkownik Ferrari edytował ten post 21 czerwiec 2007, 14:18
Fakt, że to bardzo ułatwi pracę np. grafikom, ale tego kodu PHP nie może być dużo. Problem tu stanowi iteracja w modułach typu: news, lista plików, itp. Jak trzeba, to trzeba. I tak na końcu pewnie utworzę wtyczkę kompilującą szablony z {var} itd. do plików z kodem PHP. Przemyślę to jeszcze i zabieram się do dalszego tworzenia skryptu.
użyj smarty lub czegoś podobnego i problem z głowy - masz tam pętle i inne rozwiązania, do tego smarty kompiluje szablony do "szablonów z PHP". Zamiast tworzyć ograniczone własne rozwiązanie warto wykorzystać istniejące dobre rozwiązania.
Będą też uniwersalne pliki wyglądu - np. dla list artów, plików, linków... albo list samych tytułów zawartości.
CSS i jeszcze raz CSS. Listę LI można dowolnie "ostylować" :)
Wracając jeszcze do układu plików - w odpowiednim miejscu w BODY trzeba wyświetlić wynik. Są 2 metody:
Pre-generowanie (A) (podobnie jak w PunBB)
Wykorzystanie buforowania wyjścia i dołączanie modułów wraz szablonami przed <html>. W ten sposób mamy już całą zawartość do wyświetlenia + ustawiony tytuł <title>. Rozwiązanie zapisuje wynik działania modułów w pamięci RAM (albo SWAP :D) - wraz z komentarzami, aby potem je wrzucić do szablonu głównego w <body>.
:: Znacznie większe zużycie RAM-u (np. 10 jednoczesnych wywołań po 50 kb = 500 kb - ok 1 MB).
Generowanie krok po kroku ( B )
Wszystkie moduły są dołączane z głównego szablonu na podstawie stałej MOD zdefiniowanej przez index.php. Jednak przed <html> dla modułów treści (pliki, arty, wolne strony, newsy, obrazy) wykonywany jest dodatkowy plik - content.php, który pobiera dane o zawartości i jej kategorii oraz ustawia tytuł, gdy użytkownik ma dostęp. Dla innych modułów <title> jest ustawiany automatycznie przez index.php - jeżeli istnieje klucz w tablicy $lang (w pliku języka) taki sam, jak nazwa modułu (np. user, cats, poll). Zresztą tytuł strony "Pokaż użytkownika: anonim" nie jest na tyle ważny jak tytuły kategorii (nimi zajmuje się index.php) bądź artów, plików, obrazów, wolnych stron czy nowości, co znacznie ułatwi pozycjonowanie (niektórzy też pomijają wpisy w Google, jeżeli część tytułu nie jest pogrubiona).
:: Mniejsze zużycie RAM-u, lecz narzucony szablon dla większości modułów (nie liczyć np. głosowania, logowania czy pobrania pliku, bo to się wywołuje z innych plików niż index.php)
Być może zostanę przy B jak aktualnie, chyba, że są znacznie
przekonujące argumenty za rozwiązaniem pre-generowania (A), wtedy piszcie, co wiecie. :)
Użytkownik Ferrari edytował ten post 23 czerwiec 2007, 16:40
nawet nie chce mi się w to wczytywać. Będziesz jeszcze tak teoretyzował przez rok, dwa? chyba jesteś jedyną osobą na forum.php.pl czy tutaj, która wymyśla jak zrobić szablon, jak zrobić to czy tamto próbując osiągnąć namiastkę tego co już istnieje i z czego wszyscy korzystają. Problem zmiany zawartości taga title? to żaden problem ;)
jak nie problem, to napisz coś na ten temat :)