Nette a propojení stránky s kódem

S každým článkem jsem natěšenější. :) Po pravdě, už se dávno nemůžu dočkat.

Těším se až to vyzkouším, takhle to vypada jako dobry nastroj.

Co pak to je na http://www.dgx.cz/nette/ ?? Škoda, že to není na začátku zamíchané… 

#2 Petr Weida: Hm, funguje to zajímavě když se parametr game-round změní na nějakej text… Jak to je udělaný?

#3 Reg: Pomocí Nette, pochopitelně…

#4 Tomik: Njn, a k čomu to je dobrý takováhle legrácka?

#5 Reg: Abychom se při čekání na Nette nenudili…

cim dal vic mi to pripmina MS .NET

T smrdí Borlandem. Asi budu zvracet.

Nette se jeví jako opravdu silný systém.

Objektový model vypadá sympaticky, jen mě při čtení napadlo pár věcí:

1. COM je podle mého názoru špatně zvolený název, zvlášť když se jedná o zkratku pro Component Object Model, což je zavedený terminus technicus pro MS technologii.
2. Je nějaký důvod, proč třídy začínají písmenem T?
3. Když se dá dohromady bod 1 a 2, vychází konvence používaná ve frameworku PRADO. Je to záměr?
4. Docela by mě zajímalo, jak bude Nette výkonné. Vypadá velmi flexibilně, což má vždycky nějakou režii. No a když se k tomu vezme v úvahu, že PHP není nejvýkonnější technologií pod sluncem, je určitá obava na místě.

Jinak držím palce, Nette zatím vypadá zajímavě.

#8 thingwath: Já se s tím T poprvé setkal u Turbo Vision. To sice bylo od Borlandu, ale důvod ke zvracení nevidím. Šlo o velice dobrý UI toolkit a takřka průmyslový standard (k vidění byl třeba u M602 nebo účetnictví Pohoda).

Taktéž pochopitelně nechápu, jak to T dokázalo prorůst i do jazyků, kde se neříká type, ale class.

Mne sa to bije s Template z C++ :) No jo, tazko sa da vyhoviet kazdemu :)

#10 Borek: Ano, někde jsem si v článku všiml, že je tam T jako Třída. :)

DGX: Nechcem tu vyvolať flamewar o tom, že je to prasácke, ale <?nette asi zloží PHP parser pri zapnutom short_tags_open.

Naopak chválim možnosť rozdeliť komponent na viac častí. Kde sa definuje šablóna komponenty?

Je nějaký důvod, proč třídy začínají písmenem T?

#10 Borek: Domnievam sa, že vďaka absencii namespace v PHP to slúži len na odlíšenie Nette od iných knižníc. Ak je táto domnienka správna, tak som za prefix N.

Docela by mě zajímalo, jak bude Nette výkonné. Vypadá velmi flexibilně, což má vždycky nějakou režii. No a když se k tomu vezme v úvahu, že PHP není nejvýkonnější technologií pod sluncem, je určitá obava na místě.

#10 Borek: Premature optimization is the root of all evil. Osobne si myslím, že šablóny sa predgenerujú do nejakého PHP medzikusu a nacachujú. Čiže ten celý poprask okolo generovania a spracovávania šablón, komponentov,… v Nette sa deje len raz a to keď sa niečo zmení.

Pomalosť PHP parsera je to posledné čo by ma trápilo.

#14 johno: Hopla, to short_tags_open beriem späť. Nette asi neparsuje PHP parser.

#11 llook: Jenže dnes se píše rok 2006 a máme 21. století. Já hlavně nechápu, proč je třeba před ta jména vůbec něco dávat. To se dělá v jazycích, kde nemají žádné jmenné prostory ani balíčky ani nic podobného a to snad PHP není, nebo jo?

#16 thingwath: PHP namespace nemá…imho se mi to zdá jako zbytečnost tam dávat ty předpony když je to framework…pochybuju že k tomu bude někdo používat další „systém“(nebo jak to nazvat) třetí strany…možná tak nějaký další vlastní balíčky ale tam bych konflikty názvů nepředpokládal

#17 Jakub Podhorský: ja bych nejakou simulaci namespace uvital. V jinych jazycich to ma sve duvody( http://en.wikipedia.org/wiki/Namespace_(programming) ) a proc si je neprenest i do php 4 a 5, v 6 tusim ze maji byt nativne

Pro nějaký prefix bych byl. Třeba kolizi s názvem třídy Page si představit dokážu, s třídou NPage je to lepší.

Jmenné prostory měli být už v PHP5 a dokonce i malou chvilku byli, i když dost mizerně navrhlý. Ale už zase nejsou. 

#7 PiDiBi: na tohle musím reagovat.

dgx už dřív psal, že Nette trošku .NET připomíná, že má komponenty a události. Jenže já s každým dalším článkem žasnu, jak práve .NET nepřipomíná!

Já jsem programátor ASP.NET. KDysi jsem žasnul nad runat=„server“, komponentou přímo v HTML kódu atd. Dnes ale zírám, jak někdo to zvládá daleko elegantnějí. Rozdělení COM – DOM je geniální tah. To pochopí každý, kdo kdy tvořil složité administrační rozhraní. I když teda zkratku COM bych fakt změnil. Komponenta rozdělená na více částí taky. V ASP.NET prakticky nelze použít datagrid pro hlavní stránku blogu, to by udělal jen začátečník. Jenže v Nette to má logiku.

K PHP se asi nedostanu, ale tomuhle musím fandit, to je skutečně revoluční přístup.

#8 thingwath: #10 Borek: Všechny třídy musí začínat nějakým prefixem, neboť v PHP je jmenný prostor děsně zaplácaný. Definovaných 1300 funkcí, 1340 konstant, 75 tříd a 7 rozhraní ještě před vykonáním prvního řádku kódu – a to používám jen několik extensions.

Váhám mezi T a N. Zatím používám T, jako hold Borlandu. Jejich programátoři v roce 1995 napsali VCL pro Delphi, které je v mnoha směrech inspirací pro Nette. Nikoliv tedy .NET, ale Delphi. Nejspíš ale přejdu na N.

#10 Borek: Nette je výkonné dostatečně

#20 Marek: Když jsem studovat ASP.NET, tak jsem se divil, proč je tolik věcí nedotažených nebo zbytečně omezujících. V tomto směru je Nette trošku jinde.

Nemám stejný pocit jako #20 Marek: nebo #21 David Grudl:, že by některé věci v ASP.NET byly nedotažené a že Nette je řeší líp (vím, že přímo tato formulace nezazněla, ale chtě nechtě mi to tak vyznívá).

Nette jde cestou absolutní flexibility, ASP.NET cestou rozumného komprimisu mezi řádem a flexibilitou:

• V Nette můžu dokument podědit od libovolného jiného dokumentu a překrýt libovolný jeho element. V ASP.NET musím použít master pages, které nejsou tak flexibilní, ale při pohledu do zdrojáku je zcela jasné, která část mateřského dokumentu se předefinovává (u Nette to tak očividné není, protože mateřský dokument nenese žádnou informaci o tom, který element je určen pro potomky). Myslím ale, že v praxi budou dědičnost Nette a master pages v ASP.NET používány velmi podobným způsobem.
• V Nette můžu komponentu rozdělit na víc částí, v ASP.NET nikoliv. Nette je flexibilnější, ale opět přináší určitý zmatek do vývoje, protože při pohledu na komplikovanou stránku není jasné, kde všude se Nette komponenta nalézá. V ASP.NET je komponenta atomickou jednotkou a je pravda, že přepsat příklad z článku do ASP.NET by znamenalo o pár řádků kódu navíc (mít navigátor nahoře i dole znamená volat metodu pro přechod na jinou stránku gridu dvakrát místo jednou). Ale jak často je podobná funkčnost potřeba? Napadá mě opravdu minimum případů, kdy se rozdělení komponent hodí – a i potom to v ASP.NET znamená jen o pár řádků kódu navíc, tedy nic hrozného. Asi bude nějaký důvod, proč se rozdělení komponenty na víc částí neujalo v žádné oblasti, kterou znám (HTML, ASP.NET, Windows Forms, XAML, …).
• V ASP.NET musím serverové komponenty označit jako runat=„server“, v Nette se ke každému elementu DOM mohu chovat, jako by byl serverový. To opět ukazuje na rozdílnou filosofii – Nette je maximálně flexibilní, ASP.NET vyžaduje určitý řád a disciplínu (ve skutečnosti má v ASP.NET označení komponenty za serverovou mnoho dalších důsledků, jako automatické používání ViewState, zapnutí schopnosti renderovat jiný výstup pro různé klienty atd. – proto nejsou všechny elementy automaticky runat=„server“).

Prostě Nette na to jde jinak, v určitém smyslu sympaticky, v určitém smyslu trochu chaoticky. Ale uvidíme, těžko soudit podle dvou třech článků :)

#22 Borek: S tím v podstatě souhlasím. Až na tu chaotičnost – naopak, vyšší flexibilita vede k lepšímu řádu, neboť nemusíme nic „hackovat“.

Vyhněme se akademickým diskusím a porovnávání Nette a ASP.NET. Porovnávat bude možné třeba za rok, až se vše v praxi vyzkouší a objeví slabá místa. Zatím to nemá smysl.

Len taka hnidopisska otazka, nemas tam v jednom z tych prikladov chybu?

<com:TDataGrid-items name="grid1">
...
</com:TDataGrid:items>

V otvaracom tagu je items oddelene pomlckou a v uzatvaracom dvojbodkou.

[25] Taktiež je niekde id="grid1" a inokedy name="grid1".

#23 David Grudl: Asi si prehliadol moju otázku. Kde sa definuje šablóna komponenty?

#23 David Grudl: Co naplat, děláš komponentně-událostní framework, tak se asi srovnání s jinými komponentně-událostními frameworky nevyhneš :)

vyšší flexibilita vede k lepšímu řádu, neboť nemusíme nic „hackovat“

To je hodně odvážné tvrzení, ale vypadá to, že mu opravdu věříš :)

#24 hvge: to je samozřejmě překlep.

#25 johno: id je jedinečný identifikátor v DOM, zatímco name je jedinečný identifikátor v COM. Tedy id mi identifikuje konkrétní místo v dokumentu, zatímco name určuje jméno komponenty. Proto víc „oblastí“ má stejné name.

Té otázce ohledně šablony komponenty nerozumím…

#26 Borek: Dobře, zkusme si tedy zrovna onen příklad s datagridem a dvojím stránkováním. Jak se tohle konkrétně udělá v .NET? Vážně nevím, jen se ptám.

[28] Jasné už chápem. Ohľadom tej otázky. No kde je zadefinované to XHTML, na ktoré sa prerobí TDataGrid? Či už items alebo pager.

#26 Borek: Já tomu také věřím. Ale je to asi jako spor mezi zastánci dynamického a statického typování (líbí se mi Van Rossumova argumentace: „Jestliže se podíváte na velké programy napsané v silně typovém jazyce, všimněte si, že mnoho času je stráveno právě obcházením typového systému.“).

#28 johno: Aha, rozumím.

Každá komponenta může mít tolik šablon, kolik má renderovacích částí. Šablony komponent fungují podobně, jako „velká šablona“ stránky. Nakonec stránka je také komponenta. Šablona se tedy naparsuje z přiloženého .HTML souboru a je komponentě dostupná přes DOM.

Samozřejmě komponenta nemusí vůbec šablonu využívat a sama si generovat vlastní (X)HTML výstup.

Také je možné komponentě vnutit novou šablonu. Třeba u takového Repeateru se to rovnou předpokládá.

#27 David Grudl: GridView má vlastnosti PagerSettings, PagerStyle a PagerTemplate, které do značné míry umí řadu potřeb uspokojit. Pokud by bylo opravdu nutné mít jednu část komponenty úplně jinde něž druhou část komponenty, v ASP.NET by se to asi nejlíp řešilo vytvořením nové komponenty (např. Pager), která by po kliknutí na „předchozí“ a „další“ volala odpovídající metody GridView.

Ale jak jsem řekl, nemyslím, že je roztroušení jedné komponenty na více míst častým požadavkem. Kdyby bylo, patrně by to všechny současné komponentové technologie podporovaly (a mně se nevybavuje žádná, která by to dělala).

#30 David Grudl: Rozumiem. Čo je to ten Repeater?

A ďalšia otázka. Ako sa chystáš cachovať template, v ktorom potom máš $document->head->title = 'Nette example'; Doteraz som bol v tom, že Nette šablóna sa prekladá do PHP medzikusu, ale toto ma dosť zmätlo.

#31 Borek: a tohle mi právě připadá chaotičtější. Rozdělování komponent ti jako častý požadavek nepřipadá jen z toho důvodu, že to v ASP.NET nelze řešit elegantně.

Podívej se na to prosím z nadhledem:

• Komponenta je určitý logický celek, je to objekt s nějakým stavem a metodama. Je to produkt práce softwarového architekta.
• HTML výstup se řídí znalostmi použitelnosti, přístupnosti, grafickými potřebami atd. Je to produkt webdesignéra.

Já vycházím s představy, že tyto dva pohledy si mají žít vlastním životem, protože se snaží vyhovět diametrálně jiným požadavkům. Naopak jiné frameworky vnucují souhru – jedna komponenta = jedna oblast v HTML. Mě to připadá velmi omezující.

#32 johno: Kešování funguje na více úrovních. Ta nejmenší odpovídá určitému elementu šablony. „Přepočítává“ se jen „zasažená“ část DOM. Dále je možné kešovat na úrovní komponenty (resp. její části) a tedy i celé stánky.

#33 David Grudl: Prepocitava sa len zasazena cast no znie to genialne, ale fakt ze sa tesim na implementaciu :)

#33 David Grudl: Mám to chápať tak, že šablóna je vlastne plain text a keď zavolám $document->head->title, tak až vtedy sa na ňu pustia šialené regexpy, čo sa k title tagu prekúšu a zmenia jeho obsah? Hmm, to sa mi nejako nezdá.

#33 David Grudl: Aby nedošlo k mýlce, já neříkám, že na to jde Nette špatně. Jde na to jinak, vidím výhody jeho přístupu, ale i drobné nevýhody.

Zpět k tématu: ať už se jedná o webový nebo desktopový vývoj, často je komponenta jednotka zobrazení víc než cokoliv jiného. Existují sice výjimky, jako třeba nevizuální komponenty, ale více méně všude platí, že komponenta je něco, co umí renderovat svou podobu a dělá to na jednom definovaném místě. Delphi, ASP.NET, Windows Forms, XAML, Swing, SWT, … – všichni na to jdou stejně. Nette na to jde jinak.

#36 Borek: To máš pravdu. A v podstatě odsud také pramení má tehdejší kritika ASP.NET:

…tento způsob práce se v žádném případě neshoduje s principem HTML & HTTP a jde jen o násilné naroubování cizorodých postupů na web.

Nebo jinak řečeno, co na desktopu zas tak nevadí, může hodně vadit na webu. Delphi & spol. doslova plývají pamětí, jejich (teoretický) viewstate rychle nabývá obřích rozměrů. Ale nevadí to, protože megabajt paměti je nesrovnatelně „rychlejší a levnější“ než megabajt přenosu přes internet.

#35 johno: Ve skutečnosti je to nádstavba nad DOMNode, což je nejrychlejší způsob práce s XML dokumenty v PHP. Parsování je rychlejší než unserialize nějaké vlastní struktury.

#37 David Grudl: Nejde o paměť, nejde o přenášená data, jde o princip. Komponenta v pojetí Nette je něco jiného než komponenta v pojetí zbytku světa, což může znamenat některé výhody proti všem jiným GUI frameworkům, ale taky určité zmatení pro vývojáře.

Nechci Nette nějak dopředu hodnotit, jsem opravdu zvědavý, co z toho nakonec vyleze. Tyhle poznámky píšu jen jako „early feedback“, abys znal co nejvíc názorů na svou práci (asi by ti moc nepomohlo, kdyby ses v komentářích 20× dočetl něco jako „Už se nemůžu dočkat, Nette bude super!“).

Menší rada radši zřiďte samostatné fórum pro Nette, IMHO v komentářích už tyto dotazy nemají co dělat…

nejsem kdovíjaký programátor v php, tak se omlouvám za možná blbý dotaz, ale jestli to chápu dobře, tak Nette projde text, najde tam odkazy na své funkce, ty pak třeba regexpem nahradí za jejich ekvivalenty v php a výsledný php kód se provede. Ten framework je tedy jakési „php texy“. Můj dotaz tedy zní – bude možné v nějakém debug módu zjistit ten výsledný php kód, který je realizován?

#40 noname: to jde bez závislosti na Nette…

ob_start();
echo 'Hello world!';
$output = ob_get_clean();
echo str_replace('world', 'man', $output);