 |
|
|
|
|
| Autor | Wiadomość |
|---|---|
|
Napisane: 08.02.2010 [13:59]
|
|
|
biesior
admin
Twórca tematu
zarejestrowany: 20.03.2008
Posty: 1338
|
Często podczas tworzenia szablonów developerzy nadużywają dobrodziejstwa związanego z możliwością zmapowania niemalże dowolnego elementu w pliku HTML. Przykład z życia Weźmy choćby prosty nagłówek strony, w którym chcemy użyć dynamiczny tekst dla nagłówka H1, także dynamiczny dla podnagłówka H2 no i oczywiście do tego wszystkiego wstawić logo z linkiem do strony głównej... ze względu na wielojęzyczność serwisu także dynamicznie... no i na końcu gdzieś tam trzeba umieścić pole wyszukiwania oraz selektor języków (dwa ostatnie z własnymi szablonami, także odpuszczamy sobie strukturę): Tworzymy więc prościutki kod HTML: HTML <div id="header"> <a href="###LOGO_HREF###">###LOGO_FILE###</a> <h1 class="title">###HEADER_TITLE###</h1> <h2 class="subtitle">###HEADER_SUBTITLE###</h2> ###SEARCHFIELD### ###LANGUAGE_SELECT### </div> Jest ok, mamy szablon, mamy do niego CSS, to teraz pozostaje dopisanie TypoScriptu do obsługi znaczników, załóżmy, że cObject TEMPLATE nazywa się temp.mojSzablonGlowny i ma już zdeklarowane niezbędne rzeczy takie jak plik szablonu, czy główny subpart, więc jedyne co musimy jeszcze napisać to TYPOSCRIPT temp.mojSzablonGlowny.marks {
LOGO_HREF = TEXT
LOGO_HREF.value = http://mojadomena.loc/
LOGO_FILE = HTML
LOGO_FILE.value = <img src="fileadmin/szablony/gfx/logo-firmy.jpg" />
HEADER_TITLE = ...
HEADER_SUBTITLE = ...
SEARCHFIELD < plugin.tx_dooWstawieniaPolaWyszukiwania
LANGUAGE_SELECT < plugin.tx_doZmianyJezykow
// i tak dalej...
}Voila! działa! fajnie! Nie ma w tym podejściu żadnych błędów, jest on najczęściej stosowanym i zazwyczaj spełnia swoją rolę. Jednakże ma też jedną dużą wadę - sztywność. Większość wartości wpisaliśmy do bardzo określonych miejsc, przez co tym co dzieje się dookoła nich możemy sterować wyłącznie za pomocą modyfikowanych plików szablonów, co wiąże się z przepisywaniem własności cObjectu TEMPLATE, kontrolowaniem dużej ilości podobnych plików HTML (jeśli zmieniamy coś globalnie, musimy poprawić wszystkie szablony alternatywne, zwalidować, etc. etc...)... czyli dochodzi nam też drugi problem: zamieszanie... Można też inaczej Ron Hall z Busy Noggin, przy okazji prezentacji swojego frameworka TV! dowodzi, że większość serwisów internetowych (nie tylko TYPO3) bazuje na 2,3 może 4 głównych obszarach, tj. nagłówku, kolumnie głównej i ewentualnie stopce, + być może kolumnie bocznej - pod warunkiem, że jest ona stała na wszystkich podstronach serwisu. O co chodzi, w naszym pierwszym przykładzie szablonu HTML za pomocą 6 znaczników obsłużyliśmy zaledwie nagłówek a gdzie pozostają? menu główne, menu niższych poziomów, linki stopki, treść stopki, logotypy do stron partnerów (nie daj bóg każdy deklarowany w osobnym znaczniku brrrr....) etc. Znaczników w każdym szablonie można "natrzaskać dziesiątki i każda najdrobniejsza zmiana pociągnie za sobą przebijanie się ponownie przez olbrzymią strukturę szablonu... podczas gdy o dynamicznej zmianie układów nie ma już w ogóle mowy, chcesz nowy układ pisz nowy szablon HTML! Wg. Rona w dużym uproszczeniu CAŁY szablon HTML można zmieścić w (z pominięciem nagłówka HTML). Oczywiście jest to przykład mocno uproszczony, na potrzeby budowy i walidacji szablonu zamiast znaczników marks sensowniej jest zbudować kompletny szablon i fragmenty do podmiany objąć znacznikami typu subparts: HTML <body> <div id="header">###HEADER###</div> <div id="content">###CONTENT###</div> <div id="footer">###FOOTER###</div> </body> I co z tym fantem? Teraz zamiast 6 znaczników w nagłóku mamy do dyspozycji 1 a całość możemy śmiało skonstruować choćby z pomocą TS'owego cObjectu COA: TYPOSCRIPT marks.HEADER = COA {
10 = TEXT
10.value = Fajna strona!
10.wrap = <h1 class="title">|</h1>
20 = TEXT
20.value = Serwis budowany dynamicznie
20.wrap = <h2 class="subtitle">|</h2>
// itd. itd...
}Co uzyskaliśmy w ten sposób? dużo większe możliwości wpływania warunkami na wygląd podstron w zależności od treści. np. jeśli nie chcemy na podstronach strony o UID 123 używać podnagłówka możemy dodać warunek: TYPOSCRIPT [pidInRootline = 123] temp.mojSzablonGlowny.marks.HEADER > [global] Przypomnę, że w pierwszym przypadku wyczyszczenie wartości HEADER_SUBTITLE spowodowałoby pojawienie się ostrzeżenia walidatora HTML o pustym znaczniku H2! poza tym, teraz bez problemu zmienimy klasę tego znacznika prostym zapisem bez modyfikacji pliku szablonu!: TYPOSCRIPT temp.mojSzablonGlowny.marks.HEADER.wrap = <h2 class="subtitle-alternative">|</h2> Innym ciekawym wykorzystaniem dynamicznej treści całego obszaru są kolumny. W standardowym podejściu do szablonów musimy stworzyć osobne pliki szablonów dla układów 1, 2 i 3 (i 4 i 5... i 10-cio) -kolumnowych. W podejściu Rona (które w przypadku swoich układów wielokolumnowych dzoszlifował z matematyczną wręcz precyzją) kolumny też możemy po prostu obsłużyć jednym cObjectem, i tak... zgadłeś niech to też będzie COA  TYPOSCRIPT marks.CONTENT = COA
marks.CONTENT {
10 < styles.content.getLeft
10.wrap = <div id="kolumna_lewa">|</div>
20 < styles.content.get
20.wrap = <div id="kolumna_glowna">|</div>
30 < styles.content.getRight
30.wrap = <div id="kolumna_prawa">|</div>
}Proste i jasne ? no jasne, że proste Oczywiście choć te przykłady zostały stworzone z użyciem mapowania szablonów via TS jedyna różnica w TemplaVoila polega na sposobie podmapowania poszczególnych obszarów, reszta powinna się odbywać na w miarę analogicznych zasadach. Sesja wygasła, zaloguj się, żeby się wylogować.
T3CI Certified Level 2 TYPO3 Night Crew Member. KO System enthusiast |
|
Napisane: 08.02.2010 [14:14]
|
|
|
dpacholczyk
zarejestrowany: 17.09.2008
Posty: 1006
|
Czyli generalnie Ron zmierza do tego, że wg. niego lepiej jest cały kod html wpakować via TS a nie w pliku html ? Jeżeli tak to widzę sporą wadę tego rozwiązania. Otóż każdy developer spotkał się z tym, że stawia stronę klientowi, oddaje ją i tyle. Pałeczkę przejmuje klient który już sobie tym zarządza. Wszyscy są happy. My idziemy na piwo za zarobione pieniążki, a klient szpanuje swoim klientom, że ma fajową stronę. Problem pojawia się, gdy ów klient chce sobie coś tam zmodyfikować, a nie ma speca od T3 w firmie. Ostatnio na forum często są wątki od ludzi którzy nagle przejęli schedę po jakimś adminie TYPO3, który w bezczelny sposób nie zostawił po sobie nic i wszelki słuch po nim zaginą. Co teraz ? Dodatkowe koszta bo o ile dla Nas wydaje się ten TS banalnie prosty to dla początkowego usera to czarna magia. Jednakże rozwiązania wydaję mi się - ze strony developera - bardzo fajne i ciekawe. Nie raz miałem strony gdzie musiałem tworzyć nawet 6 ext template`ów. Konfigurować je itp itd. Tu wystarczy jeden warunek i pozamiatane. Moim zdaniem wybór rozwiązania ( 1. ext tamplate na plikach html, 2. implementacja via TS ) to dość sporna kwestia i zależy chyba w dużej mierze od klienta. Certified Level 2 TYPO3 Night Crew Member.
|
|
Napisane: 08.02.2010 [15:48]
|
|
|
biesior
admin
Twórca tematu
zarejestrowany: 20.03.2008
Posty: 1338
|
Co konkretnie Ron miał na myśli można zobaczyć w jego video poświęconym frameworkowi: http://templavoila.busynoggin.com/ Oczywiście zawsze będzie dyskusyjne jaki powinien być właściwy stosunek HTML do TS wychodząc z Twojego punktu widzenia klient i tak musi zatrudnić kogoś od TYPO3, bo co z tego, że sam może dostawić znacznik w HTML: ###MENU_WSKAZANYCH_STRON### skoro ktoś ze znajomością TS jeszcze musi napisać lib.menuWskazanychStron = HMENU... Busy Noggin udowodnił za to, że trzymając się tej koncepcji za pomocą zmiany TS można bardzo wyraźnie wpływać na układy graficzne całych podgałęzi serwisu a co za tym idzie zrezygnować z mozolnego re-mapowania kolejnych wersji alternatywnych szablonów, których jedynym zadaniem jest np. zmiana klasy jednego kontenera. Oczywiście najsensowniej jest po prostu zaplanować na wstępie z chirurgiczną precyzją elementy które mają ulegać modyfikacjom w różnych obszarach serwisu i te właśnie tworzyć w formie cObjectów COA. Z całą pewnością wiele serwisów (zwłaszcza tych niewielkich - posiadających najwyżej kilka, kilkanaście stron o identycznym układzie, dostępnych w jednym języku) można śmiało obsłużyć za pomocą struktur HTML zapisanych na sztywno w HTML. Jednakże, gdy wchodzi w grę już jakikolwiek cień wielojęzyczności i/lub zmiennych układów treści, zadania związane z budową struktury dokumentu powinny być przesuwane w kierunku TypoScript'u. Sesja wygasła, zaloguj się, żeby się wylogować.
T3CI Certified Level 2 TYPO3 Night Crew Member. KO System enthusiast |
