Smarty, šablonovací systém - 1 (úvod) (diskuse)

[Merguian]

tak doufam, ze pujde o neco prevratneho, kdyz uz jeden serial mame tady

[Leoš Literák]

Pro redakci neni dulezite, zda uz nekdo dane tema popsal na jinem serveru, pak by uz nikdo nemohl vydavat nic, protoze skoro vse uz bylo nekdy nekde popsano.

[Merguian]

No to jo. Jen mne napadá, jestli v tom případě vůbec něco psát, když se nic nového neděje

[Kyosuke]

Jé, ahoj, Xenobajte!

No, Smarty mě docela zajímá, třeba mi tenhle článek ukáže, proč bych se měl vykašlat na eruby.

[Merguian]

Hoj Smarty je fajn. Dost aktivne ho pouzivam. Alespon pokud resim nejaky projekt v PHP btw: jsi mne povysil z xenobita na xenobajta? tak dik

[Milo Kmeť]

Rovnakú otázku si kladiem aj ja.

[Richard Gavenda]

K tomuhle článku by se mi líbila anketa kolik lidí používá/nepoužívá šablonovací systém. Já osobně ho nepoužívám, protože i v samotném PHP můžu jednoduše oddělit aplikační část od prezentační, kdy na začátku souboru naplním proměnné a na konci už mám jenom HTML kód a výpis proměnných. Přípaně můžu část s HTML kódem a výpisem proměnných includovat z odděleného souboru. Zkoušel jsem několik šablonovacích systémů a žádný z nich mě nepřesvědčil ani v rychlosti ani v jednoduchosti syntaxe.

[dubak]

Aj moje skúsenosti sú rovnaké. Smarty poznám ale od roku 2003 nepoužívam. Odporúčam prečítať si tento článok Beyond The Template Engine a súvisiace diskusie na Sitepoint: Discussion thread for Beyond The Template Engine, Template Engines Really DO Suck

Ak máte dobrú architektúru PHP aplikácie, napríklad MVC, tak žiadny template engine nepotrebujete.

[Libor Chocholaty]

Myslim, ze template enginy ceka skvela budoucnost prave proto, ze aplikace casto maji design poplatny dobe vzniku. V te dobe mohl byt vyhovujici a naprosto postacujici.

Po nejake dobe se zacnou objevovat nove pozadavky na system, se kterymi puvodni tvurci nemohli pocitat, a nastava klasicke managerske dilema: sahnout na funkcni a vyzkouseny core-engine nebo to dobastlit v prezentacni vrstve?

Casto to bohuzel skonci dobastlenim do prezentacni vrstvy s tim, ze nove pozadavky se nejak protlaci stavajicim nezmenenym aplikacnim enginem a v prezentacni vrstve se zpracuji.

Tim se cast aplikacni vrstvy presouva do prezentacni, ale ve firme se nenajde nikdo s rozhodovacimi pravomocemi, kdo by si vzal na odpovednost, sahnout do fungujiciho a odzkouseneho core-enginu. A tak se to bastli a bastli a prilepuje a dobastluje vsude okolo a management si mysli, jak na to pekne vyzral. Change requesty se prece podarilo rychle a uspesne implementovat do stavajiciho systemu bez zasahu do jadra aplikace...

Vitejte v dnesnich casech.

[dubak]

Neviem ako to funguje vo Vašej firme, ale u nás dostane do rúk "change request" programátor a až ten kontaktuje designera. Takže žiadne bastlenie do prezentačnej vrstvy sa nekoná. Designer má presne zadefinované čo má zmeniť a aké nové data mu posiela aplikačná vrstva. Pravidlo sa dá povedať aj inak. Zákazník nekontaktuje designera, resp. designer má zakázané priamo komunikovať so zákazníkom.

[Libor Chocholaty]

A ted si predstav, ze mas aplikaci, ktera bezi u zakaznika a je to pro nej, jak se rika, mission critical system. A zakaznik chce nejakou malou zmenu ve vystupu.

Vsichni lidi z implementacniho tymu vedi, ze by se melo lehce sahnout do core enginu, aby produkoval vhodna data pro zpracovani v prezentacni vrstve, ale nikdo ve firme za zakazku odpovedny si nedovoli sahnout do enginu, protoze jeho pretestovani by bylo prilis narocne.

A nejakej designer a programator se muzou trikrat postavit na hlavu, ale proste management jim nedovoli tu zmenu udelat. A tajne ji udelat nemuzou, protoze by na to testovaci tym prisel a nareportoval zmenu na vystupu z enginu.

A jsme presne tam, kde jsem rikal.

[Daniel Kvasnička ml.]

Ak máte dobrú architektúru PHP aplikácie, napríklad MVC, tak žiadny template engine nepotrebujete.

V clancich, na ktere odkazujete, si autor templating engine napise sam, misto aby pouzil jiny, tak o co jde? Paradigma MVC princip sablony IMHO implicitne vyzaduje.

[dubak]

Bolo to myslené špeciálne pre PHP, zdôrazňujem PHP, asi takto: V PHP nepotrebujem pre vytvorenie elegantnej a efektívnej prezentačnej vrstvy žiadny nový engine s vlastnou syntaxou. Vystačím si s čistým PHP a jedným malým classom. Presne v duchu Vášho podpisu "Simplicity is the ultimate sophistication."

[Daniel Kvasnička ml.]

na začátku souboru naplním proměnné a na konci už mám jenom HTML kód a výpis proměnných. Přípaně můžu část s HTML kódem a výpisem proměnných includovat z odděleného souboru.

A to vam vubec nevadi nehorazna neprehlednost tohohle paskvilu? Vsechny ty echa, prepinani kontextu PHP/XHTML a dalsi blbosti?

Templatovani je suverenne nejprehlednejsi zpusob oddeleni controlleru a view.

[Jiří (BoodOk) Kadeřávek]

Templatovani je zalezitosti 'page' orientovanych aplikaci, tedy tech kde se v jednom kroku UI vytvari a zaroven plni hodnotami. U AJAX aplikaci by melo byt pravidlem, ze vytvorim UI a posleze ho plnim hodnotami (sablony jsou zde k nicemu). To prvni je vhodne pro vyrobu webovych prezentaci, to druhe pro tvorbu interaktivnich vetsinou database-driven aplikaci.

[Daniel Kvasnička ml.]

No ja jsem chtel jen naznacit, ze v pripade, kdy mam sablonu webu a X zpusobu jak ji naplnit, je kolegou popisovany zpusob jako drbani se pravou nohou na levem uchu...

AJAX, fajn vec. Ale nektera data prece na zacatku poslat musite. Nebo poslete vylozene jen view a pak se v nem spusti kaskada XmlHttpRequestu?

[Jiří (BoodOk) Kadeřávek]

Ano, na zacatku poslu View. Kaskada requestu se ale nekone. Jeden ukon uzivatele = jeden XMLHttpRequest. Jeden XMLHttpRequest vetsinou znamena zmenu stavu modelu. Kolik UI prvku si vyzaduje update je vetsinou (ne vzdy) zalezitosti modelu, ktery to realizuje pres controller. Nekdy se nic neaktualizuje, nekdy prejde aplikace do jineho panelu (tuto zmenu realizuje sam controller), nekdy se naplni nejaky seznam (to je zalezitosti modelu), nekdy se aktualizuji hodnoty editovaneho zaznamu (taktez model). Je to ruzne. Zkuste se na to podivat jako na programovani ve Visual Basicu. Nejprve definujete form a posleze s nim manipulujete.

[Daniel Kvasnička ml.]

Pravda je, ze nekdy je potreba na strance aktualizovat tak malou cast, ze reload cele stranky je zbytecnost -- podle toho, co pisete ze vytvarite, tak tenhle pristup k MVC hraje dost roli. Budu (snad) psat o MVC obecne a MVC web frameworcich (hlavne Python) diplomku, tak si delam poradek

V tehle souvislosti muze byt celkem zajimave pouziti googli knihovny ajaxslt, i kdyz nevim, jak moc je browser-friendly. Nemate zkusenosti?

[Jiří (BoodOk) Kadeřávek]

Bohuzel nemam, ja si frameworky radeji vytvarim vlastni.

[lukas.ramlich]

Upozornění pro začátečníky: SMARTY Z VÁS UDĚLÁ IDIOTA (ještě většího)!

Podle mě je Smarty takový začátečnický pokus, který se nečekaně zalíbil začínajícím PHP lamám, protože byl stejně nechutný jako jejich kód. To způsobuje obrovské haló kolem jeho používání a neskomírající komunitu nezkušených začátečníků.

Místo aby se tak začátečník dral systémem pokus-omyl dopředu a ke kvalitě, zůstává u prasáckého postupu, kterému ale může odborně říkat "šablona".

Žádným slušným slovem nelze nazvat počin génia, který se snaží oddělit prezentační vrstvu a vrstu logiky a skončí tím, že do prezentační vrtvy začne cpát cykly, formátovací funkce, rozhodovací bloky a jiné pičičurinky.

[kaaja]

Úplně nesouhlasim. Ne ze by se mi smarty nejak moc libilo, ale zajimalo by me, jak chcete udelat prezentacni logiku bez cyklu a rozhodovacich bloku?

[dubak]

Keď sa má HTML designer naučiť SMARTY syntax pre cykly a if-else, tak je schopný naučiť sa aj toto:

Results found: <?=$total_rows ?><br>
<? if (count($rows) > 0): ?>
    <? foreach ($rows as $row): ?> 
        <?=$row['last_name'];?> 
    <? endforeach; ?>
<? endif; ?>

Ako som uviedol v mojom predchádzajúcom príspevku, je to len záležitosťou správnej architektúry celej aplikácie. To čo som vám ukázal je skutočne všetko čo môže použiť u nás HTML designer.

Dúfam že ste to pochopil a postúpil z kategórie "cvičená opica".

[Jiří (BoodOk) Kadeřávek]

Dúfam že ste to pochopil a postúpil z kategórie "cvičená opica".

A vy jste se prave zaradil do kategorie arogantni trotl. U mne mate ban.

[dubak]

Síce sa to netýkalo Vás, ale ospravedlňujem sa všetkým diskutujúcim. Prečítal som si ešte raz pozorne všetky príspevky v tomto vlákne a tento výrok beriem späť, takže už to nechajme.

Zhrniem moje názory na tento článok:
- dôležitá je architektúra PHP aplikácie
- šablonóvacie nástroje typu Smarty sú zbytočné
- v prezentačnej vrstve sa bez cyklov a rozhodovania nezaobídete, ale nepotrebujete na to nový jazyk. HTML designér musí byť schopný naučiť sa PHP echo, if-else, foreach.

[Jiří (BoodOk) Kadeřávek]

Omluva se ceni. Souhlasim s Vami, ze pri dobre architekture aplikace jsou sablony zbytecne.

[happy barney]

HTML designér musí byť schopný naučiť sa PHP echo, if-else, foreach.

Blbosť, template systém by mal byť nezavislým rozšírením HTML. To, že je php jazyk pre idiotov neznamená, že ho musí ovládať každý.
Pre designéra je imho jednoduchšie napísať napr

<tmpl:foreach name="blabla_list">
  <option><tmpl:variable name="value"/></option>
</tmpl:foreach>

a programátor by si to už mal vedieť skonvertovať (v najhoršom XSLT do Smarty)

[dubak]

To, ktorý z príkladov (môj alebo Váš) je pre konkrétneho HTML designera ľahšie naučiteľný, je veľmi subjektívne. Jedno je však isté, že designer môže použiť asi ľubovoľný HTML WYSIWYG nástroj podporujúci PHP (asi väčšina), ale v prípade Smarty potrebujete nejaký plugin. Ja mám takú skúsenosť, že designéri sú roztržití ľudia nad ktorými musí dohliadať nejaký syntax checker.

[Pavel]

Jasne, hlavne ze v prezentaci nemate cykly a rozhodovaci bloky.

[dubak]

Netvrdím, že tam nemám cykly a rozhodovanie.
1, Mám ich tam, ale sú v jednom a tom istom jazyku, t.j. PHP
2, Moje cykly a rozhodovanie slúžia len na prezentáciu (napr. if nieco > 999 then color = red )

[happy barney]

konštanty patria do biznis logiky, ktorá by napr vo vašom príklade mala generovat atribút povedzme WARN, a prezentácia by mala byť (if WARN then "color=red")

[dubak]

Nehovorím o konštantách. A čo keď sa v eShope rozhodujem podľa atribútu z databázy, if (product['size'] == 'XL') ?
Dobre, v PHP môžem v business logike, ktorá číta z DB, pridať on-the-fly ďalší atribút, product['color']. Ale stále je to rozhodovanie špecifické pre prezentáciu, bez ktorého sa nezaobídete.

Mám rád softwarové inžinierstvo, ale som viac pragmatik ako akademik.

[Pavel]

Ja jsem narazel na tvrzeni:

Žádným slušným slovem nelze nazvat počin génia, který se snaží oddělit prezentační vrstvu a vrstu logiky a skončí tím, že do prezentační vrtvy začne cpát cykly, formátovací funkce, rozhodovací bloky a jiné pičičurinky.

Nejak mi uniklo, ze to vypustil nekdo jiny.

[lukas.ramlich]

- Tak tohle, to je spalovací motor. Směs benzínu se vzduchem vybuchuje ve válcích a tlačí tím na klikovou hřídel, která roztáčí kola. - Úplně nesouhlasím! Ne že by se mi parní stroje nějak líbily, ale zajímalo by mě, jak chcete udělat motor bez kotle, páry a topeniště?

Řekl jsem svůj názor, poradil jsem začátečníkům. Vy si to dělejte jak chcete. Až někdy budete redesignovat stránku a kvůli tomu honit kusy business logiky mezi kousíčky <tr><td><font>, třeba si na mě vzpomenete. Jsem totiž "vedle jak ta jedle" :)

p.s. to měkké "i" v Kaajovi_vylevy je nepovedená slovní hříčka, nebo povedená blbost?

[kaaja]

Samozdrejme, ze business logika mezi html byt nema, ale zase na druhou stranu stranka muze ruzne vypadat pri ruznych podminkach. Samozdrejmne ty podminky si musi programator predem rozhodnou v business logice - do sablony musi jit uz hotova rozhodnoti.

Bohuzel jsem jiz kody, kde se tabulka tvori primo pri nacitani dat z databaze videl.

Jeste bych zminil jednu super vec, kterou mohou sablony poskytnout - muzete mit obecnou obalku stranek a do te pak jen zasazovat konkretni moduly. To sice smarty nema dotazene do dokonalosti - neni to prece oplny obecny framework, ale urcite to lze pouzit.

[zet]

Ve svem sablonovacim enginu uzaviram casti html do {block neco}cast html{/block neco}, opakovani/cykleni uz resim v PHP...

[Lukáš Zapletal]

Jestliže business logiku aplikace chápete tak, že se jedná o kód s cykly, tak to jste vedle jak ta jedle.

[happy barney]

Žádným slušným slovem nelze nazvat počin génia, který se snaží oddělit prezentační vrstvu a vrstu logiky a skončí tím, že do prezentační vrtvy začne cpát cykly, formátovací funkce, rozhodovací bloky a jiné pičičurinky.

cykly? ako by ste chcel inak vypisovať x častí rovnakého typu ? (príklad: články, novinky)
formátovacie funkcie? limitovaná množina, typu escape=url, escape=html ano, zvyšok nie
rozhodovacie bloky? ano, aj tie sú v šablónach potrebné (príklad: zobrazenie login/password pre neprihláseného užívateľa).

čo sa týka šablón, jediná knižnica, čo ma svojimi vlastnosťami ako tak uspokojila, je HTML::Template (ale to sa netýka php)

[narg]

Mě nejvíce fascinuje, jak se lidi snaží vymýšlet hranaté kolo, které jiní lidé používají i když tu máme normální _standartní_ kulaté kolo. hranaté kolo=Smarty, Flexy atp., standartní kulaté kolo = XLST.

[lukas.ramlich]

Někdo vymýšlí hranaté kolo, někdo novou podobu slova "standardní", to si nevyberete.

XSLT je akademický experiment, který se neprosadil ani náznakem. Praktici kódují HTML, snílci XHTML a doufají v jeho zpracování jako XML, utopisti produkují XML, které následně proženou XSLT transformací do výsledného XHTML a doufají, že jednoho dne budou posílat jen to původní XML a příslušný XSLT. To se ale nikdy nestane - je to slepá ulička.

p.s. to v patičce, to je ještě angličtina?

[Jiří (BoodOk) Kadeřávek]

XSLT je akademický experiment, který se neprosadil ani náznakem.
ROFL Clovece, vzdyt vy zrejme ani netusite k cemu muze byt XSLT dobre. To, ze se nepouziva na client-side prece jeste nic nevypovida o jeho vyuziti na strane serveru. Mozna byste mel sva kategoricka tvrzeni lehce revidovat, at nejste k smichu.

[lukas.ramlich]

Tak povídejte, jak se to masově na straně serveru používá... třeba k smíchu nakonec bude někdo jiný. Pár expertimentálních implementací ještě není totéž co "prosazení".

[dubak]

Pomaly pane Ramlich, nie je server ako server. Keď postúpite z PHP a dostanete sa k projektom v Jave z oblasti EAI (Enterprise Application Integration) alebo B2B, tak budete XML a XSLT stretávať na každom kroku.

[lukas.ramlich]

A co z toho plyne? Že Sun má (měl) rád XML a XSLT. O tom, že to je ta PRAVÁ technologie (ten svatý grál, standard), nám to neříká vůbec nic. Ne náhodou v Java světě žije silná myšlenka, že nasazení XML a XSLT je v mnoha případech pouze módní záležitost a koncepční chyba, která silně komplikuje vývoj.

Někteří lidé totiž v běhu za koncepční nádherou a čistotou frameworků zapomínají, kvůli čemu ho vlastně začali programovat. Kvůli zjednodušení vývoje. Konce bývají neveselé. Většinou se zrodí nějaká geniální a zcela univerzální technologie, jejíž použití je ale tak komplikované, že se původní plánované výhody zcela vytratily a vývoj s jejím použitím je ještě bolestivější než předtím!

To je příklad toho vašeho XSLT. Původně zajímavý transformační nástroj je natolik překomplikovaný, že vývoj a údržba šablon aplikace vyvolává potřeba nového specializovaného XSLT programátora.

Trend je jasný. Od XSLT se pomalu ustupuje. Třeba takové JSF - proč myslíte, že jeho šablony žádné XSLT nepoužívají?

[dubak]

Nie je to o Jave. Pracoval ste niekedy s datami vo formáte EDIFACT. Ak nie, tak to ani neskúšajte. Ak Vám ponúknu na výber medzi EDIFACT a ebXML alebo xCBL, tak sa stavím že zoberiete čokoľvek na báze XML len aby ste nemusel robiť so starým EDIFACT.

[lukas.ramlich]

Proč to sem taháte? Jasně že XML je dobrý formát pro výměnu dat! EDIFACT a jemu podobné šílenosti jsou samozřejmě překonané a XML je pro VÝMĚNU DAT opravdu geniální.

Jak to ale souvisí s tím, že XSLT jako šablonovací systém pro www stránky je pitomost?

[Jiří (BoodOk) Kadeřávek]

Napr. XSL transformace 'custom' tagu na strane serveru. Docela zasadne se tim odstini komplexnost UI webove aplikace. Pitomost to tedy rozhodne neni.

[thingie]

Ale no tak, prosím, každý výstup tohoto pána hodnotím jako perlu. Nezklamal ani teď.

[Filip Jirsák]

jednoho dne budou posílat jen to původní XML a příslušný XSLT. To se ale nikdy nestane - je to slepá ulička

Že tohle už dnes v prohlížečích funguje, to vás asi moc netrápí, že?

[lukas.ramlich]

Zapomněl jste dodat " ... v NĚKTERÝCH prohlížečích ...". S chybami a příslušnými dětskými nemocemi. Kdo nezkusil, nepochopí. Pro praxi je to nepoužitelné. I prohlížeč, který to zdánlivě podporuje, ukončí zobrazení některých kombinací XML a XSLT chybou nebo prázdnou obrazovkou a o příčině se nedozvíte NIC! Zkuste si to debugovat metodou pokus-omyl, rychle vás to přejde.

Že XSLT podporuje zrovna váš minoritní prohlížeč neznamená vůbec nic. Ani to, že to bude podporovat i v další verzi.

[Filip Jirsák]

Nezapomněl. To samé můžete prohlásit o libovolné verzi HTML, XHTML, CSS, JavaScriptu, DOM, SVG a dalších a dalších technologiích. Takže jsem to předpokládal automaticky. úplně stejně se ještě před pár lety choval v prohlížečích DOM – a ejhle, ze slepé uličky se vyklubal AJAX. Doufám, že tou slepou uličkou bude AJAX a nativní XML v prohlížečích se naopak prosadí.

[uzivatel]

Do XSLT sa nevyznam, ale nie je to prave staticka zalezitost, kdezto JavaScript (AJAX) je zalezitost dynamicka ? Ako sa da potom take nieco porovnavat ?

Kedysi davno som sa chcel naucit XSLT (je to par rokov a vtedy som nevedel ani poriadne HTML, ale jakz takz som sa v nom vyznal), ale ked som pozrel na tu kopu nezmyselneho kodu, tie vselijake tagy a blbosti tak s lahkym srdcom mozem povedat, ze HTML a CSS je stale dobra vec pokial nedojde uplne nieco jednoduche a prevratne.

[Filip Jirsák]

Jedna z častých věcí, co dělá AJAX, je transformace jednoho XML na jiné skoroXML (HTML), což XSLT zvládá daleko lépe. Výstupem transformace XML+XSL bývá nejčastěji opět XML nebo HTML, obojí je možné dále stylovat i skriptovat. Samozřejmě AJAX a XSLT nejsou vzájemně srovnatelné technologie. Jenom mi nepřipadá, že bastlení (AJAX) nad bastlením (HTML+DOM) je ten správný směr vývoje, to už XML&spol. jsou nějaké standardy, rozšiřitelné a škálovatelné.

[Jiří (BoodOk) Kadeřávek]

Tak pozor, DOM je standardizován, (Java/J/ECMA)Script je standardizován, HTML je standardizováno, XML je standardizováno. O jakém bastlení zde hovoříte? Navíc zkratka AJAX vypovídá o architektuře aplikace jen a pouze technologii, kterou View komunikuje s Controllerem (dokonce AJAX ani neimplikuje způsob, jakým je View aktualizován a jestli obsahuje vůbec nějakou prezentační logiku).

[Filip Jirsák]

Sice je to všechno standardizováno, ale také záleží na implementaci. A navíc DOM a JS je pro opravdové programování view vrstvy strašně neohrabaný. Bastlení je, že se to musí pro každý prohlížeč zvlášť upravovat, bastlení je, že se používají operace, které mohou trvat dlouho nebo nemusí vůbec skončit správně (HTTP komunikace), ale chybí možnosti synchronizace, více vláken, rozumné zpracování událostí… Takže se spoléhá na to, že to ve většině případů "nějak dopadne".

AJAX využívá technologie, které mají sice prohlížeče implementované, ale už je to daleko za hranicí, pro co byly původně navrženy, a je to na tom znát. A řešením není, že se budou dělat stále větší a větší hacky v JS a DOM, ale že přijde nějaká technologie, která tyhle problémy bude řešit efektivně. A XML i XSLT jsou jedny z částí, na kterých by ta nová technologie mohla stát.

[Jiří (BoodOk) Kadeřávek]

Při čtení Vašeho příspěvku mne napadlo přísloví: "Kdo chce hledá způsoby, kdo nechce hledá důvody." Neboli, jak jste napsal, zálží na implementaci. Vypočítat nevýhody čpatné implementace AJAXu je možná efektní, nikoliv však objektivní.

[Filip Jirsák]

V IT se ale vždy hledá kompromis mezi snadností užití, efektivností, náklady na vývoj, rychlostí atd., takže to, že AJAX jakž takž funguje, ještě neznamená, že se má dále rozvíjet. Když navíc každý ví, že to je jen z nouze ctnost, protože zatím nic lepšího nemáme. Transformovat jedno XML na jiné XML pomocí JavaScriptových funkcí pracujících s DOMem sice možné je, ale efektivní, rychlé nebo snadno udržovatelné to není ani náhodou. Vytvářet GUI z primitiv určených původně pro prezentaci především textových informací možné je, ale efektivní, udržovatelné, rozšiřitelné a robustní to není ani náhodou. Žádné vylepšování těchhle technologií tomu nepomůže.

[Jiří (BoodOk) Kadeřávek]

Jak to myslíte, že AJAX je o transformování jednoho XML do druhého? Já mám XML šablonu, pomocí XSL ji transformuji do HTML View. Mám tedy UI kostru aplikace, přičemž vstupy uživatele jsou odesílány na server, který je zpracuje a pomocí javascriptí manipulace s DOMem vykonává aktualizaci View (např. naplní příslušný select výsledkem db dotazu). Já transformuji uživatelův vstup do odezvy UI, kde tam vidíte jaké XML?

[Filip Jirsák]

Výsledek dotazu do DB pošlete nejspíš jako XML (pokud to parsujete z texťáku, je to skoro to samé), následně JavaScriptem na základě toho XML vytvoříte DOM reprezentaci HTML (vy to nazýváte aktualizace view), což je zase jen reprezentace XML (na úrovni DOMu jsou HTML a XML zaměnitelné). Jenže místo přepisovacích pravidel jako v XSLT musíte procházet DOM po jednotlivých elementech, kopírovat atributy atd., a pokud chcete být kompatibilní s MSIE, nemůžete použít ani XPath.

[Jiří (BoodOk) Kadeřávek]

XML mi tedy z databáze určitě neleze. Resp. bych musel přistoupit na velmi vysokou míru abstrakce, abych ve svém konceptu viděl transformaci jednoho XML do druhého. Dokonce si myslím, že ta míra abstrakce by musela být tak vysoká, že potom bych musel vidět XML všude. Já si myslím, že koncept který používám je velmi podobný běžnému způsobu práce desktop aplikací. Prostě nějakým způsobem manipuluji s interaktivními prvky UI. A že k tomu používám Javascript? To je snad zřejmé.

[Filip Jirsák]

Tak co posíláte jako výstup databáze do toho skriptu? CSV, JSON nebo XML, něco jiného asi těžko. To že manipulujete s interaktivními prvky UI je vaše abstrakce, HTML žádné interaktivní prvky UI nemá, musíte je simulovat prvky HTML. Tím skriptem tedy nemanipulujete s UI, ale vytváříte DOM (což je jen jiná reprezentace XML), který pak vložíte do HTML stránky, prohlížeč to vyrenderuje a teprve tím vznikne GUI.

[Jiří (BoodOk) Kadeřávek]

Já mám každý interaktivní prvek navázán na tzv. kursor. Kursor je adresa ve jmenném prostou modelu. Je to tedy adresa nějakého údaje. Př: mám cursor //Orders/First/order_id, ten je svázán se vstupním prvkem (INPUT) s id Orders__First__order_id. Model se dynamicky přepočítává na základě změny vstupní cursorů. Takže mám např. kursor //User/First/usr_username (svázaný s inputem User__First_usr_username) a pokud ten změní svou hodnotu, pak dojde k přepočtení celého modelu a výsledkem je, že //Orders ukazuje na objednávky nového uživatele a dojde tedy k aktualizaci hodnoty //Orders/First/order_id a následně i prvku Orders__First__order_id. Uvnitř to funguje tak, že při změně modelu je prostřednictvím třídy HTMLView aktualizována hodnota prvku s id Orders__First__order_id. Konkrétní implementace této třídy to činí tak, že provede Orders__First__order_id.value = $Model->Cursor('//Orders/First/order_id'). Žádný DOM v 99% případů nevytvářím, je hotov v okamžiku inicializace aplikace.

[Filip Jirsák]

To ale funguje pouze pro input=text, cokoliv složitějšího (už i ten seznam), vyžaduje složitější manipulace. Pravda, taky je to AJAX, ale většinou si pod AJAXem člověk představí nějaké složitější GUI komponenty.

[Jiří (BoodOk) Kadeřávek]

Co si kdo predstavi pod AJAX je kazdeho vec. Ja jen odkazi na to, co ta zkratka znamena a tam o zadnych rich komponentach rec neni. Podotykam, ze input=text je alfou a omegou kazde interaktivni aplikace, pokud pomineme Solitaire a spol. Jisteze muzete select.options.add povazovat za praci s XML, ja ale rikam, ze se jedna o zkresleny pohled (XML optikou).

[Filip Jirsák]

Do povědomí lidí se AJAX dostal s Gmail a spol. – tam těch input=text je hodně málo. I pro ostatní interaktivní aplikace je běžný input=text nedostačující – potřebujete různé kalendáře, masky, historie apod. To, že se to v AJAXových aplikacích redukuje na samotný input=text je sice pravda, ale není to zadarmo – trpí tím uživatelská přívětivost programu.

[Jiří (BoodOk) Kadeřávek]

Možná tím trpí přívětivost, těžko říci. Pokud je ovšem větší přívětivost na ukor spolehlivosti nebrat. Když mám např. maskovaný vstup, uvedu masku v labelu (nebo zašedle přímo v inputu, je-li prázdný) a validaci podle masky provádí controller. Pokud hodnota nesedí, uživatele upozorní a input vrátí na předchozí hodnotu. Když začal VB, který považuji za prototyp IDE pro okenní programování, pak obsahoval možná 10 widgetů. Postupně přibývaly další a další, ovšem ne vždy se dalo říci, že jejich použití je cestou k vyšší uživatelské přívětivosti. Takže asi tak. U AJAXu více než kde jinde platí: Keep It Simple. Potom lze vytvářet i poměrně rychlé a spolehlivé aplikace.

[Filip Jirsák]

Zrovna o spolehlivosti se u AJAXu dá mluvit jen těžko. Pokud se např. nepodaří stáhnout celý skript, nebo se nepodaří nahrát správně data, prakticky není šance, jak by se z toho mohla AJAXová aplikace (klientská část) zotavit. Uživatel jen může zkusit dát reload stránky, doufat, že "se" aplikace spraví a moc to nepoškodí workflow.

Jiné widgety než input=text nejspíš nějaký smysl dávají, protože input=text fungovalo plně i v textovém režimu (TUI), a lidé asi měli nějaký důvod přejít ke GUI – a s možností mnoha dalších widgetů ten důvod pravděpodobně velmi úzce souvisí.

Pro jednoduché aplikace asi AJAX nějaký smysl má (i když pak je zase diskutabilní jeho výhoda oproti klasickým HTML formulářům), ale jako náhrada desktopových aplikací je to podle mne slepá větev. Protože výhoda desktopových apliakcí je právě v tom, že umožňují dělat velice různorodé a přizpůsobivé widgety, které pružně reagují na to, co uživatel dělá a přinášejí mu spoustu drobností, které mu práci usnadní. AJAXová aplikace může být plně funkční a dokonce i emulovat různé widgety, ale nedokáže umožnit pohodlné užívání aplikace.

[Jiří (BoodOk) Kadeřávek]

Zrovna o spolehlivosti se u AJAXu dá mluvit jen těžko. Pokud se např. nepodaří stáhnout celý skript, nebo se nepodaří nahrát správně data, prakticky není šance, jak by se z toho mohla AJAXová aplikace (klientská část) zotavit. Uživatel jen může zkusit dát reload stránky, doufat, že "se" aplikace spraví a moc to nepoškodí workflow.

• Jak se zotaví aplikace v prostředí client-server?
• Vám běžně chodí jen půlky stránek a skriptů?

Jiné widgety než input=text nejspíš nějaký smysl dávají, protože input=text fungovalo plně i v textovém režimu (TUI), a lidé asi měli nějaký důvod přejít ke GUI – a s možností mnoha dalších widgetů ten důvod pravděpodobně velmi úzce souvisí.

• Tvrdil někdo, že jiné widgety smysl nedávají?
• Mimochodem TUI s klávesovými zkratkami je prototypem velmi vhodného a vysoce produktivního prostředí.

Pro jednoduché aplikace asi AJAX nějaký smysl má (i když pak je zase diskutabilní jeho výhoda oproti klasickým HTML formulářům)

Nevím jestli má naše diskuse smysl, pokud výhodu AJAXu vidíte pouze v možnosti vytvářet i velmi složité, obskurní widgety? Zjevně jste se hlouběji problematikou nezabýval.

Protože výhoda desktopových apliakcí je právě v tom, že umožňují dělat velice různorodé a přizpůsobivé widgety, které pružně reagují na to, co uživatel dělá a přinášejí mu spoustu drobností, které mu práci usnadní.

Opravdu? Viděl jste někdy opravdu enterprise aplikaci, velký informační systém?

[Filip Jirsák]

Jak se zotaví aplikace v prostředí client-server?

Před započetím déletrvající operace uživatele o déletrvající operaci informuje (to v AJAXu lze), v okamžiku korektního ukončení operace tuto informaci skryje (to v AJAXu lze), v okamžiku nekorektního ukončení tuto informaci taky skryje a zobrazí chybovou zprávu (v AJAXu nelze), a umožní uživateli akci zopakovat (v AJAXu lze, ale nikdo neví, jak to dopadne), v průběhu celé operace informuje uživatele o jejím průběhu (v AJAXu nelze) a umožní jí přerušit (v AJAXu nelze).

Vám běžně chodí jen půlky stránek a skriptů?

Ano, běžně.

Mimochodem TUI s klávesovými zkratkami je prototypem velmi vhodného a vysoce produktivního prostředí.

Vysoce produktivní prostředí je do určité míry komplexity systému/ů. Pokud uživatel používá více systémů nebo je systém rozsáhlý, je množství naučených postupů nezvládnutelné. Mimoto AJAX klávesové zkratky umožňuje používat jen v omezené míře, přitom klávesové zkratky jsou právě to, co činí ono TUI s klávesovými zkratkami vysoce produktivním prostředím.

pokud výhodu AJAXu vidíte pouze v možnosti vytvářet i velmi složité, obskurní widgety?

Naopak, v nemožnosti AJAXu vytvářet vysoce efektivní a provázané widgety vidím jeho nevýhodu.

Opravdu? Viděl jste někdy opravdu enterprise aplikaci, velký informační systém?

Viděl už jsem dost informačních systémů, které se nezabývali právě takovými drobnostmi, jako je práce se schránkou, klávesové zkratky, ovládání klávesnicí nebo myší, změna velikosti oken, multi document interface, rychlé přepínání mezi detailem a celkem. A pracovat se s nimi sice dalo, ale bylo to hodně neefektivní.

[Jiří (BoodOk) Kadeřávek]

Před započetím déletrvající operace uživatele o déletrvající operaci informuje (to v AJAXu lze), v okamžiku korektního ukončení operace tuto informaci skryje (to v AJAXu lze), v okamžiku nekorektního ukončení tuto informaci taky skryje a zobrazí chybovou zprávu (v AJAXu nelze), a umožní uživateli akci zopakovat (v AJAXu lze, ale nikdo neví, jak to dopadne), v průběhu celé operace informuje uživatele o jejím průběhu (v AJAXu nelze) a umožní jí přerušit (v AJAXu nelze).

Můžete mi napsat proč by nemělo být možné monitorovat déletrvající operaci? Je to komplikovanější, jedná se o asynchronní proces, ale pokud použijete kontrolní spojení, pak to možné prostě je. Stejně jako je možné operaci přerušit. Je to sice náročnější na server, ale pokud je to nezbytné, co naděláte. Můžete proti AJAXu argumentovat, ale Vámi popisované nevýhody jsou obecné AJAX nespecifické nevýhody technologie nad HTTP. Dokud zde nebude něco jiného, obdobně silně standardizovaného a 100% kompatibilního, pak se jedná o čistě akademickou diskusi.

[Filip Jirsák]

Můžete mi napsat proč by nemělo být možné monitorovat déletrvající operaci? Je to komplikovanější, jedná se o asynchronní proces, ale pokud použijete kontrolní spojení, pak to možné prostě je.

Možné to není. Kontrolním spojením můžete monitorovat odesílání ze serveru, ale pro monitoring je důležité monitorovat příjem u klienta – a tam máte jen dva stavy – počátek a konec. Nic mezi tím nezjistíte. Navíc prohlížeče i servery mají obvykle nastaven limit pro počet současných spojení, takže s těmi kontrolními spojeními se také musí zacházet opatrně.

Stejně jako je možné operaci přerušit. Je to sice náročnější na server, ale pokud je to nezbytné, co naděláte.

Opět – můžu přerušit vysílání, ale ne příjem. I když přeruším vysílání, pořád ještě musím zpracovat a zahodit již odeslaná data.

Můžete proti AJAXu argumentovat, ale Vámi popisované nevýhody jsou obecné AJAX nespecifické nevýhody technologie nad HTTP.

Tohle konkrétně jsou nevýhody specifické pro AJAX, jiné technologie komunikující přes HTTP umožňují sledovat množství přenesených dat, nastavit timeouty spojení, dozvědět se, že se spojení přerušilo atd.

Dokud zde nebude něco jiného, obdobně silně standardizovaného a 100% kompatibilního, pak se jedná o čistě akademickou diskusi.

Nikdy jsem netvrdil, že tady nyní něco lepšího máme. Říkal jsem jen to, že AJAX je sice zatím to nejlepší, ale je to z nouze ctnost a než vymýšlet, jak vylepšit nevylepšitelný AJAX, je potřeba zaměřit se na vývoj něčeho nového, co bude vytvořeno s ohledem na tvorbu GUI a interaktivitu.

[Jiří (BoodOk) Kadeřávek]

Co to je prerusit vysilani, prerusit prijem? Vy snad dokazete prerusit predavani parametru a navratovych hodnot mezi procedurami v desktop aplikaci. Nezlobte se, ale vymyslite si tady nejake pseudoproblemy. Operace se vykonava a ja ji dokazi zastavit, ale vzdy v jejim prubehu, ne v prubehu predavani vstupnich nebo vystupnich hodnot. Vysilani je predani parametru a prijem je prijem navratove hodnoty. Copak XMLHttpRequest neumoznuje nastavit timeout? Copak nedokazete zjistit mnostvi dat prenesenych timto kanalem. A co si asi myslite, ze XMLHttpRequest vlastne je? Jak se asi lisi od bezneho GET/POST pozadavku? Jen a pouze tim, ze jen proveden v kontextu stavajiciho DOM. Jinak se jedna o bezny HTTP request, to XML je tam jaksi nedopatrenim navic (ted uz i chapu vasi ekvilibristiku s transformaci XML).

[Filip Jirsák]

Co to je prerusit vysilani, prerusit prijem? Vy snad dokazete prerusit predavani parametru a navratovych hodnot mezi procedurami v desktop aplikaci.

V desktop aplikaci můžu důvodně očekávat, že volání funkce bude trvat v řádu milisekund. Při asynchronní komunikaci musí počítat s tím, že může trvat sekundy i desítky sekund.

Copak XMLHttpRequest neumoznuje nastavit timeout?

Ne.

Copak nedokazete zjistit mnostvi dat prenesenych timto kanalem.

Ne.

A co si asi myslite, ze XMLHttpRequest vlastne je? Jak se asi lisi od bezneho GET/POST pozadavku? … Jinak se jedna o bezny HTTP request, to XML je tam jaksi nedopatrenim navic

Běžný HTTP request umožňuje odesílat i přijímat proud dat (postupné zpracování), nastavovat timeouty apod. Tj. umožňuje mi řídit přenos dat – ne jen dát nějaký požadavek a pak se modlit, abych v dohledné době dostal odpověď. XMLHttpRequest má sice navíc XML, ale hlavně mu spousta podstatných funkcí oproti HTTP requestu chybí! (Resp. má je skryté v interní implementaci, nedostupné pro AJAX aplikaci.))

[Jiří (BoodOk) Kadeřávek]

XMLHttpRequest umoznuje samozrejme nastavit timeout. Vyplyva to z podstaty asynchronniho volani. Pokud si reknu, ze kdyz mne do 60 s. nedojde response, tak proste po 60 s. spojeni zrusim. Asynchronni pozadavek XMLHttpRequestu (ano existuje i blokujici synchronni pozadavek) je velmi komfortni zalezitosti. Dovoluje Vam mit klienta stale pod kontrolou. Prit se o tom s Vami nehodlam, je to proste tak.

[Filip Jirsák]

XMLHttpRequest umoznuje samozrejme nastavit timeout.

Jak?

[Jiří (BoodOk) Kadeřávek]

XMLHttpRequest object obsahuje metodu abort, a pozadavek lze tudiz stornovat naprosto kdykoliv. A protoze muzete pozadavek zaslat jako asynchronni neblokujici, je jen na Vas, jaky timeout si nastavite a ve kterem okamziku pozadavek stornujete.

[Filip Jirsák]

XMLHttpRequest object obsahuje metodu abort, a pozadavek lze tudiz stornovat naprosto kdykoliv. A protoze muzete pozadavek zaslat jako asynchronni neblokujici, je jen na Vas, jaky timeout si nastavite a ve kterem okamziku pozadavek stornujete.

Timeout v síťové komunikaci má být ochranou před nečekaným výpadkem komunikace. Takže jediná rozumná implementace timeoutu je měření doby, která uplynula od posledních přijatých dat.

Pokud nastavíte "externí" timeout (tj. čas vůbec není svázán se síťovou komunikací), jako to můžete udělat pro XMLHttpRequest s metodou abort(), můžete nastavit nějaký pevný čas, takže se komunikace bude zbytečně přerušovat při posílání většího množství dat nebo zatížené síti, nebo si musíte předem zjistit množství dat a podle něj nastavit timeout, nebo timeout řídit z dalšího spojení. Ani jedno není zrovna efektivní.

Navíc mám pocit, že abort() se v některých implementacích choval divně a stahování přerušil jen zdánlivě, ve skutečnosti se skrytě stejně stáhl soubor celý. Ale to už je možná vpořádku.

[Jiří (BoodOk) Kadeřávek]

Cas muze byt svazan se sitovou komunikaci, a to pomoci vlastnosti readyState, ktera je pri zahajeni prijmu dat na hodnote 3. Pokud by v teto pozici mela setrvavat prilis dlouho, muzete spojeni zrusit. Samozrejme zalezi i na implementaci na serveru, zda jsou data odeslana behem vykonu nebo az po skonceni operace. V kazdem pripade jsem presvedcen, ze implementace XMLHttpRequestu nabizi dostatecne moznosti, jak pripadne vypadky komunikace osetrit.

[Filip Jirsák]

Což ale neřeší problém, který nastane během spojení (přerušení spojení). Navíc o implementaci readyState v MSIE mám pochybnosti, když jsem to kdysi testoval, dostával jsem stavy třeba v náhodném pořadí (nejdřív completed, pak interactive).

Myslím si, že AJAX je pro uživatele až na výjimku jednoduchých formulářů méně komfortní než desktopová aplikace, a už vůbec nevidím v AJAXu nějaké rezervy do budoucna. Ale asi se na tom neshodneme, a náhradu AJAXu tu taky asi nevykřesáme…

[Jiří (BoodOk) Kadeřávek]

AJAX je pro uživatele až na výjimku jednoduchých formulářů méně komfortní než desktopová aplikace

Ano, existuje pohled, pri kterem to muzeme tvrdit. Avsak muzeme take tvrdit, ze desktopova aplikace je daleko mene komfortni, pokud se zamerime na jeji TCO (instalace, aktualizace, bezpecnostni aktualizace), a to zdaleka nejen pro uzivatele, ale taktez pro jejiho vyrobce a spravce. Jsem toho nazoru, ze pokud mam na vyber, kterou technologii zvolim, pak musim mit setsakra dobre zduvodneni, proc zrovna tu 'desktopovou' a musim si byt jist, ze takovy (srovnatelny nebo jen o malo mensi) komfort neposkytne online aplikace se vsemi vyhodami, ktere to online nabizi.

[Filip Jirsák]

TCO je asi jediný argument ve prospěch AJAXu oproti desktopovým aplikacím – jinak by se i dnešní desktopové aplikace dělaly jako lokální webserver, který si uvnitř sebe spustí instanci webového prohlížeče Desktopová aplikace ale může mít nějaký tenký zavaděč, který se postará o instalaci i aktualizace (viz třeba Java WebStart) – a pak už jsou TCO srovnatelné.

Problém je, jak onen komfort pro uživatele vlastně zjišťovat. Pro nějakého počítačově málo vzdělaného uživatele může mít AJAXová aplikace stejný komfort jako desktopová, protože nic jiného než vyplňování textů do políček dělat nebude, a v případě problémů si někoho zavolá. Pokročilý uživatel už dokáže využít pokročilejších funkcí, které desktopová aplikace může nabídnout oproti AJAXu.

[Jiří (BoodOk) Kadeřávek]

Jinak by se i dnešní desktopové aplikace dělaly jako lokální webserver, který si uvnitř sebe spustí instanci webového prohlížeče.

http://www.nusphere.com/products/phpdock.htm
Jinak, díky za diskusi.

[Filip Jirsák]

http://www.nusphere.com/products/phpdock.htm

PHP zrovna nemusím, ale koukám, že už je to nějaký pátek, co jsem s ním dělal, a že už od té doby existují asi i dobrá IDE.

Jinak, díky za diskusi.

Rádo se stalo, nápodobně.

[Daniel Kvasnička ml.]

většinou si pod AJAXem člověk představí nějaké složitější GUI komponenty.

bohuzel

[Kovář David]

Tak se zkuste podívat na stránku

http://svn.jahia.org/svn/jahia/trunk

A pak se nezapomeňte podívat na zdrojový kód této stránky. Ukázkový příklad jak lze použít XSLT transformaci. Je to strojově čitelné a současně se může kdokoli podívat přes webový prohlížeč.

BTW: funguje to ve Firefoxu, Opeře a dokonce i v IE6 (sedmičku jsem nezkoušel, ale dá se to předpokládat). To mi řekněte na jakém trhu se pohybujete a jak se jmenuje ten Váš prohlížeč co to nezvládne.

Mějte hezký den a užívejte si svých pokrokových technologií.

[Daniel Kvasnička ml.]

Sefiku, pracoval vy ste vubec nekdy s XML a musel/chtel jste nejake informace z nej poslat do prohlizece? A jak jste to prasil? V PHP do pole a pak to z toho doloval krumpacem? A kdyz vytahnete data z databaze a chcete je zpracovat X ruznymi zpusoby, tak to vyzenete do pole a pak napisete kupu hov...pardon, kodu v PHP, ktery to doluje a zene ven? Diky, nechci.

XSLT pouzivam hodne, hlavne na generovani menu, drobku a mapy webu z XML, kde mam strukturu jakkoliv sloziteho webu ulozenou, protoze XML je perfektni format na znazorneni hierarchicnosti.

doufají, že jednoho dne budou posílat jen to původní XML a příslušný XSLT

No, pokud jako jedine vyuziti XSLT vidite transformaci jednoho XML souboru jednim XSL souborem a pak poslani do prohlizece, tak pak se neni co divit vasim recim.

[Kyosuke]

To si vyprošuji. Standardní kulaté kolo je LISP, když už…

[Tom.š Ze.le.in]

A je to tady. Já jsem to čekal už jak jsem četl ten článek. To zas budou řeči o smug lisp weenies. Podívají se, pane - oni to vědí, já to vím, a nikoho jiného to tady u toho článku asi moc nezajímá :) :)

[Kyosuke]

Já jen dovádím do důsledků uvažování typu „když A a B umějí totéž a A tu bylo dřív, zavrhneme B, protože je tu navíc a zbytečné“. Protože podle téhle logiky je XSLT zbytečné, pouštějí se fanoušci XSLT jejím používáním na značně tenký led dvojího metru.

[Michal Vyskočil]

Na zive jim redsys ořezává koncové a počáteční <>. Musím uznat, že závorky, kterými to někdo obcházel, ten sghtxml kód poměrně zkrášlily

(html)
    (head)(/head)

    (body)
        (h1)(/h1)
    (/body)
(/html)

[Honza "tux" Friesse]

Určitě to vypadá líp. Ale co teprve:

(html (head (title "Titulek")) (body (h 1 "Nadpis")))

[Pavel Kysilka]

kratce doplnim po precteni par prispevku, ze to xslt ma par vyhod.

- zkuste zvalidovat nejakou php sablonu. jasne, ze to jde zobazenim v prohlizeci. a pokud jeste neverite, tak zkuste 4 navazne formulare a sebou s nejakym ukladanim.

- html a weby nejsou vse. html je pouze jeden z vystupu.

pro ty, co neveri, tak 2 roky jiz velmi uspesne xslt pouzivam(bankovni system, vyvojova verse penguina). nicmene xslt podporuje i samotny microsoft. i kdyz ne nejak extra dobre. a pres 3 roky jsem sablony pouzival v php nez jsem presel na javu.

bye gf

[deda.jabko]

blahopreji k uspechu s xslt, kolik vam jeste zbyva vlasu? ;-]

xslt je hezke, problem je ze se jedna o kompletni turingovsky jazyk s naprosto nehoraznou syntaxi ;-]

muj osobni pocit je, ze slozitejsi transformace nad 500 radku uz jsou neudrzovatelne....

[happy barney]

ale sú, a jednoducho, len treba mať správny prístup k rozvrhnutiu kódu

[Kyosuke]

Hmm, položím hloupou otázku: Co v tomhle kontextu přesně znamená slovo „zvalidovat“?

[Jiří (BoodOk) Kadeřávek]

Já se přidám. XSL poměrně s úspěchem používám v AJAX/MVC aplikaci plošně nasazené v jedné z velkých českých finančních institucí. To plošně znamená, že aplikace je používána cca 5000-10000 uživateli na 2000 obchodních místech. Naprosto bez problémů, s udržením kompatibility MSIE/Gecko/KHTML/WebCore.

[Petr Bravenec]

Smarty někde používám a někde nepoužívám. Smarty mě naučilo, jak oddělit logiku od vzhledu - ale úplně stejně dobře se na to dá použít i PHP samotné a to bez potřeby učit se nějaký nový jazyk. Navíc dělat ve Smarty některé věci je pěkný opruz, PHP je snazší.

Na uvedeném příkladu nechápu jednu věc: Pomocí Smarty je oddělený "html kodér" od "programátora" - proč teda není oddělený návštěvník webu od šablon? Co je na šablonách, knihovnách, pluginech a konfiguraci (!) tak zajímavého, že k nim musí mít přístup kdokoli, kdo napíše http://web.kdesi.u.kohosi/templates/hello_world.tpl?! Přijde mi to jako dost překvapující, nebezpečné a nedomyšlené. Správně navržená adresářová struktura by měla vypadat, myslím, trochu jinak.

[Pavel Dobeš]

Treba pear.php.net, HTML_QuickForm? Nevim, co to znamena mene pracne, ne je samotne PHP...

[petr]

To musíte ještě podstoupit mod_rewrite hell... Já nevím, ale nějak mi přijde pohodlnější použít prostředí, které s těmito fakty tak nějak počítalo již při návrhu. Ale asi jsem moc moderní nebo možná hloupej či nezkušenej, že mi PHP+MySQL přijde nepoužitelné...

[Láďa]

Spíš moderní. Použitá databáze je vcelku fuk, kdo si chce ušetřit práci, tak stejně použije object-relational mapping, takže MySQL se v pohodě dá. Ale PHP už nepoužitelné je a Smarty je toho výborný příklad. Když už šablony, tak by měly být: - buď čistě jako rozšíření HTML v podobě dalších atributů jako používá například Zope, kdy do HTML tagů můžete přidat třeba podmínky, nahrazování obsahu proměnnou atd. - nebo alespoň ve stejném jazyce jako například v Ruby on Rails (které šablonovací jazyk prostě nepoužívá). Osobně mi vyhovuje druhý příklad, jelikož dělám jak HTML+CSS, tak i kód za tím. První se ale může hodit, kde to dělají dva různí lidé, webdesigner potom může kód pořád jednoduše upravovat, prohlížeče i všechny WYSIWYG editory šablonovací atributy ignorují. Ale v případě Smarty zobrazí všechny {foreach}, {if} a s plnou parádou zboří existující design.

[Jiří (BoodOk) Kadeřávek]

Ale PHP už nepoužitelné je a Smarty je toho výborný příklad. Když už šablony, tak by měly být: - buď čistě jako rozšíření HTML v podobě dalších atributů jako používá například Zope, kdy do HTML tagů můžete přidat třeba podmínky, nahrazování obsahu proměnnou atd. - nebo alespoň ve stejném jazyce jako například v Ruby on Rails (které šablonovací jazyk prostě nepoužívá).

Zkuste si to po sobě přečíst ještě jednou. Tvrdíte, že PHP je nepoužitelné, protože existuje Smarty? Vy si skutečně myslíte, že pro PHP neexistují šablonovací systémy v PHP, případně, že neexistují šablonovací systémy založené na XSL? Víte vůbec jaký je rozdíl mezi programovacím jazykem a frameworkem?

[Ditys]

Zdravím, existuje nějaký slušný framework (= míň pracný než samotné PHP) na tvorbu formulářů? Asi nejlépe přes objekty...

[Merguian]

No bodejť. Je jich víc. Zkus třeba na phpclasses.org v oblastí HTML.

[xtrip]

PHP PEAR HTML_QuickForm http://pear.php.net/package/HTML_QuickForm

[Simon Toth]

A co takhle TENG? Prave to pouzivam v jednom projektu a vypada to dost dobre (hlavne to neni vazane pouze na PHP).

[tulpik]

Teng, http://teng.sourceforgne.net.

Smarty? Fuj!

[Daniel Kvasnička ml.]

eh... nemyslis, ze neobjektoveho bordelu uz je v PHP dost? Tohle me odradilo jen jak jsem videl ty priklady tam.

[Daniel Kvasnička ml.]

S veeeelikou radosti v srdci jsem ted obevil PHPTAL, port TAL z pythoniho Zope. To mi imponuje a jeste vice mi imponuje, ze ty sablony jsou cistounke XML