PHP - 5.díl: Druhý pokus o strukturované prvky

17.11.2007 21:17 | Přečteno: 1604× | Programování

Již delší dobu jsem zde nic nenapsal o svých zkušenostech s PHP, jelikož jsem na svůj projekt neměl moc času. Teď se mi ale podařilo přijít na lepší způsob, jak vytvořit strukturovanou diskusi, nebo menu.

Předchozí pokus byl mým prvním zápisem v blogu o PHP. To se mi však pro složitost moc nezamlouvalo a tak jsem se snažil při psaní strukturované diskuse přijít na něco lepší a myslím, že se mi to i povedlo. Ostatně posouzení nechávám na vás v diskusi pod tímto zápisem.

V datazázi musí být uložené údaje od id komentáře, jeho úrovni(level) a předchůdci(parent) a další věci jako text nadpisu, komentáře, nebo cokoliv dalšího. Celé toto pole načítám v jednom SQL dotazu, kde zadám uspořádání podle úrovně(level). Druhým a posledním SQL dotazem zjistím maximální hodnotu úrovně komentářů.

Pokračuju vytvořením zdrojového a cílového pole. Ve zdrojovém poli si v cyklu vytvořím pro každou úroveň podpole a do nich v následujícím cyklu doplním komentáře se shodující se úrovní:

// Resulting array of comments
		$cmnt = array ();
		// Source array
		$child = array ();
		
		// Generate subarray for each comment level
		for ($i = 0; $i <= $lmax; $i ++) {
			$child[$i] = array ();
		}
		
		// Add comment's to subarrays by level.
		for ($i = 0; $i <= $lmax; $i ++) {
			// Cross db array
			for ($lv = 0; $lv < count($rows1); $lv ++) {
				// If level of db array is the same as source subarray, then add comment's to this subarray.
				if ($rows1[$lv]["level"] == $i) {
					array_push($child[$i], $rows1[$lv]);
					$rows1[$lv] = null;
				}
			}
		}

Tím mám připravené zdrojové pole, následně zavolám funkce godown a goup v tomto pořadí. Zdrojové a cílové pole předávám odkazem. První funkce vypadá takto:

function godown($childs, $max, $start, $cmnt) {
	// Parse level from $start to $max
	for ($i = $start; $i <= $max; $i ++) {
		$exist=0;
		// If is set first comment in current level
		if (isset ($childs[$i][0])) {
			// Check if exist's parent of this comment. If so, then we counldn't add this comment into resuling array
			// and delete from source array, because we need add it after parent and if parent exists, then wasn't parsed
			// and added into resulting array yet.
			for ($k = 0; $k < count($childs); $k ++) {
				if ((!empty ($childs[$k])) && ($childs[$i][0]["parent"] == $childs[$k][0]["comm_id"])) {
					$exist = 1;
				}
			}
			// If parent don't exist then we add this comment on the end of resulting array and delete it from source array.
			if ($exist == 0) {
				array_push($cmnt, $childs[$i][0]);
				array_shift($childs[$i]);
			}
		}
	}
}

Do jejich parametrů předávám zdrojové pole- $childs, maximální úroveň-$max, první úroveň-$start, která je při prvním volání 0 a později se nastavuje z funkce dgoup. Posledním parametrem je cílové pole.

Jako první v cyklu procházejícím komentáře podle úrovně testuju, jestli první komentář v dané úrovni existuje-postupně totiž komentáře odebírám pomocí array_shift, k tomu ale až za chvilku. Pokud tedy komentář existuje, tak ještě testuji jestli neexistuje jeho předek, protože pokud by existoval(ještě by nebyl zrušený), znamenalo by to, že by se komentář vypsal u jak na něj přijde řada u jiného rodiče.

Pokud zjistím, že komentář žádného rodiče nemá, tak jej přidám na konec cílového pole $cmnt a odeberu ze zdrojového pole $childs.

function goup($childs, $max, $cmnt) {
	// Parse level from max to 0 - first level of comment.
	for ($j = $max; $j >= 0; $j --) {
		$exist = 0;
		// Check if is set first comment in current level
		if (isset ($childs[$j][0])) {
			// Check if exist's parent of this comment. If so, then we counldn't add this comment into resulting array
			// and delete from source array, because we neet add it after parent and if parent exists, then wasn't parsed
			// and added into resulting array yet.
			for ($k = 0; $k < count($childs); $k ++) {
				if ((!empty ($childs[$k])) && ($childs[$j][0]["parent"] == $childs[$k][0]["comm_id"])) {
					$exist = 1;
				}
			}
			// If parent don't exist then we add this comment on the end if resulting array and delete it from source array.
			if ($exist == 0) {
				array_push($cmnt, $childs[$j][0]);
				array_shift($childs[$j]);
			}
			// If exist comment in upper level, then we call funcion godown with current level - 1 in params.
			if (isset ($childs[$j-1][0])) {
				godown(& $childs, $max, $j-1, & $cmnt);
			}
		}
	}
}

Funkce pro průchod komentáři směrem nahoru je velmi podobná té předchozí, jenom je zde přidána kontrola jestli existuje první komentář nižší úrovně a jestli ano, tak se zavolá funkce godown.

Nakonec vypisuji strukturovanou diskusi, menu, nebo cokoliv jiného.

Na závěr bych vás chtěl požádat, abyste mi do diskuse napsali, co si o tomto řešení strukturovaného výpisu myslíte, případně nějaké návrhy na vylepšení

       

Komentáře

[outsider]

PHP? To ještě někdo používá? =-O

PS: Jako zarytému perlistovi mi zásadně vadí, že komentáře jsou delší než vlastní kód!

[Daniel Kvasnička ml.]

PS: Jako zarytému perlistovi mi zásadně vadí, že komentáře jsou delší než vlastní kód!

U nas ve firme se naopak rika, ze komentar musi byt delsi nez metoda (Java)... sice trochu nadsazka, ale v podstate jde o vyjadreni principu, ze spatne komentovany kod muze byt super dobry, ale kdyz k nemu nekdo po case prijde a musi ho studovat, tak produktivita prace jde do haje.

[happy barney]

njn, ak je program podobnej kvality ako uvedeny kod v php, tak sa necudujem potrebe komentarov

[Daniel Kvasnička ml.]

Nevim na co narazite... Potreba kvalitnich komentaru nema s programatorskymi kvalitami kodu co delat. Muzete mit sebelepsi a efektivnejsi kod, ale kdyz k nemu prijde nekdo dalsi nebo vy sam po X mesicich, muzete na to koukat jak puk...

[happy barney]

narážam napr na to, že to, čo tu autor písal v troch šialených častiach s vnorenými cyklami a podobne, sa pri troche dobrej vôľe dá (prehľadnejšie) napísať na menej ako 10 riadkov. Ale nepovažujte ma za mernú mincu, v mojom zmýšľaní sa môže (výrazne) vyskytovať deformácia perl-om

[Miloslav Ponkrác]

To je právě ono, proč se programátorské věci mají probírat na programátorských fórech. Protože jinak dostanete spoustu balastu jako "proč nepoužiješ jiný jazyk", "používám jazyk X, který je lepší, než Tvůj jazyk Y", "jak se mají dělat komentáře", "jak odsazovat bloky", "kdo je větší borec", a podobné přínosné debaty. Nehledě na to, že tu je procento dobrých programátorů určitě nižší, než na programátorských fórech.

[Kyosuke]

Ehm, několik programátorských fór jsem viděl, a přišlo mi, že je-li tam něčeho víc, tak všech lidí... A největší chuťovka jsou "herní programátorská fóra"...tam se člověk občas najde takový hlody, že nestačí koukat. (BTW, Vy přeci jste PHPkář, ne? Není tohle Vaše? Ač tedy pokud ano, asi by zasloužil CPress vyčinit za jméno autora. )

[Miloslav Ponkrác]

Jasan, některá programátorská fóra jsou dobrá, některá horší. Ohledně toho PHP - ano, v PHP jsem toho dost napsal, a i tu knížku jsem vydal já Můj nápad, že jim napíšu knížku o LISPu se u CPressu nesetkal s pochopením

[Kyosuke]

Esli ji někdy budete psát, připište si mě jako od(p)borného recenzenta. Právě si studuju CL-SQL, které mělo "LINQ" roky před Microsoftem...

[Miloslav Ponkrác]

Ano ano, píšu si Vás jako odbroného recenzenta a dovolil jsem Vám přidat ještě funkci sponzora Ne to je samozřejmě legrace. LISP je úžasný jazyk, ale co je mu platné, že má spoustu nádherných věcí, když v praxi hraje někde vzadu. Ale LINQ se mi líbí, však taky Microsoft svůj jazyk příšerným způsobem zhackoval, aby to tam nacpal - ale mám pocit, že ten C# už je dnes totální balast ve stylu pejsek s kočičkou vařili dort. Jde tam spoustu věcí, ale je to už totální smetiště nekonzistentních věcí hala bala nad sebou.

[Kyosuke]

Mno, ještě uvidíme. Za poslední tři-čtyři roky aktivita kolem CL, zvláště na common-lisp.net, povážlivě vzrostla. Třeba to jednou neskončí na smetišti dějin - ostatně je to jeden z mála jazyků, co je schopný celkem bez problémů rozběhnout čtyřicet let starý program (jeden takový pravidelně používám ), a to nikoli v čtyřicet let starém runtimu, ale v letošním kompilátoru používajícím nejnovější technologie. Jsem zvědav, kde bude za čtyřicet let Java nebo PHP. Ale to už jsme hodně mimo...

[Miloslav Ponkrác]

No aktivita možná vzrostla, ale nikde to nevidět. Tedy ano - zjišťuji, že na vysokých školách se začíná učit algoritmizace na Scheme, což já osobně jedině podporuji - je to mnohem lepší, než to učit na paskvilech stylu Java, apod..

Pravda, LISP je dost dlouho kompatibilní, ale každý programovací jazyk, který má ambice přežít déle, než pár let slávy a potom pád se o zpětnou kompatibilitu důkladně stará - viz třeba Cobol, Fortran, i to C (kde rozběháte v dnešním kompilátoru 37 let staré programy ), C++ (zatím příliš mladé), Ada, Objective C - to jsou všechno jazyky, které se důsledně o zpětnou kompatibilitu starají.

Osobně naprosto nachápu, proč některé jazyky ruší zpětnou kompatibilitu a ještě to obhajují, jako jsou třeba - Python, Ruby, Perl, ... atd., což mě moc mrzí a považuji to za obrovskou hovadinu.

A PHP o tom ani nemluvte, to je stále nekompatibilní a každá další verze to totálně překope a donutí Vás to často dost přepsat. Nehledě na to, že v poslední době si autoři PHP nedělají problémy se stabilitou a chybovostí. Lidi to snesou, tak co Jenže nic srovnatelného s PHP pro tento účel nenajdete, takže se to trpí.

No a Javě se tak zcela zpětnou kompatibilitu taky zachovat nikdy nepovedlo, přes všechny proklamace. Řekl bych, že Java je hlavně věc enterprise aplikací.

[Kyosuke]

No aktivita možná vzrostla, ale nikde to nevidět.

No když už si toho všiml i takový bulvár jako DDJ, tak na tom něco bude...

[Messa]

A co to má vlastně dělat - co má být výsledkem? Vypsat nějakou stromovou diskuzi?

Když dělám strukturovanou diskuzi já, tak do databáze jen ukládám ID prvku (komentáře apod.), ID rodičovského prvku (nebo NULL) a data (předmět, text apod.). Výsledná stránka se stromově uspořádanými položkami jde udělat buď hromadou dotazů vždy na položky s konkrétním ID rodiče, nebo vyselektováním všech prvků a sestavení mapy ID rodiče => pole prvků s daným ID rodiče; vytvoření stromové struktury je už jen probírání se touto mapou.

Přiznám se, že tvé řešení jsem moc nepochopil (ani jsem se o to moc nesnažil a ten kód také není moc čitelný, dokonce i na to, že je to v PHP ;)), předpokládám ale, že cílem není vypisovat jen položky až od určité úrovně.

Jinak ještě je zajímavé vyhledávání v celých podstromech, to je popsané v jednom článku na Intervalu.

[Josef Kufner]

A když se k id rodiče přidá ještě levý a pravý, tak se na jeden select a bez rekurze dá s diskuzí udělat cokoliv. Ono vlastně to id rodiče je celkem nepraktický údaj.

[happy barney]

pravy a lavy su imho vhodne na read-only stromy, prepocet pri pridavani .. fuj, fuj
osobne pouzivam pomocnu tabulku (predok, potomok, hlbka), kde je kazdy prvok (prvok, prvok, 0). A select ide joinom z dvoch tabuliek.

[Josef Kufner]

To sice jo, ale když se to udělá dobře, tak se toho přepočítává málo a většinou je počet zápisů výrazně menší než počet čtení, takže se ta troška režie navíc ztratí (tím spíš, když se to nemusí zamykat).

[Daniel Kvasnička ml.]

Pokud se nejak vyznamneji prosadi STX, pujdou vsechny tyhle zpusoby ukladani stromovych struktur do kyticek... I dneska bys to mohl udelat pomoci XML a XSLT, akorat ze kdyby se ti diskuse rozrostla, bylo by to trosku pametove narocnejsi

Jak pise Elliot Harold (Elliotte Rusty Harold on native XML data servers):

Roughly 80% of the world’s data cannot plausibly be stored in a relational database. The 20% that does fit there is important enough that we’ve spent the last 20 years stuffing it into relational databases and doing interesting things with it. I’m still doing a lot of that.

But there’s a lot more data out there that doesn’t look like tables than does.

[Messa]

A nebo rovnou objektovou databázi. Ale tyhle způsoby ukládání do kytiček rozhodně nepůjdou

I když zrovna to STX mi připomíná XSLT, a jak bych podle toho chtěl postavit dostatečně funkční databázi, na to už mi fantazie nestačí... (Ale to neznamená, že bych se to nechtěl rád dozvědět ) Leda že bych měl nějaké velké XML soubory a nad nimi tyto příkazy prováděl.

[Daniel Kvasnička ml.]

A nebo rovnou objektovou databázi.

A nebo. Ale mam pocit, ze ty se prosazuji jeste pomaleji nez XML storage. Je nejaka objektova DB, ktera by byla podobne rozsirena jako ZopeDB?

I když zrovna to STX mi připomíná XSLT, a jak bych podle toho chtěl postavit dostatečně funkční databázi, na to už mi fantazie nestačí... (Ale to neznamená, že bych se to nechtěl rád dozvědět ) Leda že bych měl nějaké velké XML soubory a nad nimi tyto příkazy prováděl.

STX v podstate (z uzivatelskeho hlediska) je XSLT. Zmente namespace a odstrante nutnost stavet kvuli transformaci cely XML strom do pameti a mate STX (zhruba ) Kdyz se kolem toho motaji lide jako Michael Kay a Petr Cimprich, tak celkem verim, ze z toho neco bude.

Pokud bude STX na urovni XSLT 2.0, bude jeho sila dost velka -- i kdyz nejaky rozumny nastroj na UPDATE/INSERT chybi. XUpdate se jaksi neujalo, umi ho snad jen 4Suite a mozna Saxon?

[Miloslav Ponkrác]

Objektové databáze se nijak moc neuchycují - a není divu, protože jednak nikdo pořádně neví za jaký konec objektové databáze vzít, a jednak v případě objektových databází selhávají v kritických zátěžích na rozdíl od relačních a jednak relační databáze začínají přejímat objektové prvky a tím prosazení objektových databází ztěžují.

Jinak o objektových databázích už se mluví velmi mnoho roků a stále tu nejsou a můj skromný názor je, že objektové databáze se ani nikdy významněji nerozšíří, není důvod.

[Kyosuke]

Kvalitních objektovývh databází je sice jako šafránu, ale existují. A nějak nemyslím, že by měly problémy s velkým množstvím dat. Problémy mají s cenou. Relační databáze na většinu věcí přeci jen stačí nebo se dají mírně přiohnout a existuje spousta implementací, které nic nestojí a přitom obslouží víc dat, než může člověk, co není ochotný nic zaplatit, vůbec využít. Takže pro ty zoufalce, co nutně potřebují dělat grafové algoritmy v praxi nad desítkami gigabajtů dat, si můžou firmy jako Franz (AllegroCache, AllegroGraph) a Gemstone (Gemstone/S) nasadit cenu o dost výše.

To, že relační databáze přejímají objektové prvky, je sice pěkné, ale z velké části je to dobré do marketingových materiálů. Objektová databáze bez pořádné integrace do klientského jazyka mi přijde jako mírně kvadruplegický software. Relační kalkul je natolik omezený, že serializovat jeho dotazy do SQL a posílat na server ke zkompilování a spuštění není až takový problém. Ale třeba u toho AllegroGraphu by to bylo lámání přes koleno, nemluvě o tom, co všechno by nefungovalo. Myslím, že současný stav ještě nějakou dobu vydrží... "Objektově-relační databáze", "STX" a "Pes přeoperovaný na chobotnici" z mého pohledu patří do téže množiny (a sice do množiny obskurností).

[Miloslav Ponkrác]

O to výkonu bychom si promluvili u mnoha terabajtových databází, tady relační databáze fungují, ale objektové už by dávno ryly čumákem pěkně hluboko v zemi.

Navíc algoritmy a vše kolem relačních databází se vyvíjelo desítky let a dosáhly velmi slušného a efektivního stavu, objektové databáze nemají tento náskok.

Relační databáze je jednoduchá - a z toho vyplývá její nutně vyšší efektivita a výkon, když jde do tuhého. To je stejné jako Unix versus Windows - Unix je svým uspořádáním jednoduchý až primitivní systém a proto když jde o výkon tak Unix zvítězí. Čím jednodušší princip máte, tím to bude rychlejší a efektivnější, když půjdete do vysokých zátěží - a tohle plus u relačních databází sotva překonáte. U vysokých zátěží nakonec se čistá objektová databáze neukáže jako vhodné řešení.

[Kyosuke]

A opravdu je technicky nutné, aby objektová databáze při "relačních datech" měla nižší výkon? Vždyť návrháři relačních databází nemají žádnou magickou hůlku, kterou by návrháři objektových databází neměli. Nemluvím o grafových algoritmech nad celým datasetem , jen o situaci, kdy do kvalitního OODBMS nacpete "tabulky". BTW, AllegroCache se tváří, že terabajty zvládá. Ale cenu nechtějte znát...

[Miloslav Ponkrác]

Každá abstrakce stojí výkon - tak tomu vždycky bylo a bude. Objektová databáze se může pouze limitně blížit výkonu relační databáze, ale při potřebě skutečného výkonu nikdo soudný objektovou databázi nenasadí.

Možná, že AllegroCache se tváří, ale nikdo to nikdy v reále pořádně nevyzkoušel. Zato terabajtových relačních databází s mnohaletým provozem je na světě relativně dostatek a osvědčily se. A o tom to je ...

[Daniel Kvasnička ml.]

"Objektově-relační databáze", "STX" a "Pes přeoperovaný na chobotnici" z mého pohledu patří do téže množiny (a sice do množiny obskurností).

Rozvedte to s tim STX trochu. Jak si predstavujete reseni nejvetsiho problemu XSLT a dalsich dnesnich technologii na transformaci/dotazovani do XML -- tedy nutnosti reprezentovat cely XML strom v pameti? (krome nazoru "tahnete s XML do haje" )

[Kyosuke]

Ehm, já - přiznávám - vždycky tak nějak cítil, že mimo dokumentové formáty, kde XML využívám, je XML spíš problém než řešení... Takže dokonce i vůči STX mám svoje výhrady, i když se mi to samozřejmě líbí kvůli závorkám. Ale flat-namespace humor stranou...já nevím. Nedávno jsem prostě našel zajímavé, jednoduché a funkční (funkcionální? ) technologie, které mě definitivně přesvědčily, že lidi ve W3C jsou asi placeni od kilogramu popsaného papíru nebo co. Esli se mi podaří dostat se v psaní nějakých těch schematických článků k SSAX/SXML (což by byl tak třicátý až šedesátý díl ), třeba se o tomhle zmíním, včetně možných řešení.

[Miloslav Ponkrác]

Já si osobně taky myslím, že XML je dost o problémech, ale je in a každý kdo jí používá je happy a cool. Ale dost humoru.

Dokonce i s tou poznámku o nekompetentnosti W3C naprosto souhlasím, je to organizace velice škodlivá (píši o současném stavu), a kdyby byla zrušena v tuto chvíli - možná by si spousta lidí oddechla. Ale to už jsme aý moc drsný.

[Daniel Kvasnička ml.]

Já si osobně taky myslím, že XML je dost o problémech

Kdyz ho razite nekam, kam se nehodi, tak jo. Ale ja i kdyz jsem narazil na problemy, tak nikdy nebyly takove, abych se musel divat po alternative -- ona totiz srovnatelne rozsirena a podporovana alternativa pro praci se stromovymi daty neni (ne, YAML opravdu neni alternativa k XML, pokud nechcete zustat u ukladani konfiguracku pro pristup do DB ). Kombinace XML a XSLT mi proste osobne mnohokrat pomohla a usetrila velkou sposutu casu (generovani statickych webu v kombinaci s Antem, datova zakladna pro dynamicke vicejazycne weby v kombinaci s DB etc...). Nemluve o tom, ze to reseni je prenositelne a kdyz se rozhodnu pouzit ho misto v Pythonu nebo PHP v Jave, tak muzu.

ale je in a každý kdo jí používá je happy a cool. Ale dost humoru.

No tak u XML myslim tohle uz opada. Ted se na nej spise hazi spina a roli ruzovoucke in super technologie prejima uz zmineny YAML, ktery nemalo lidi (hlavne railsistu) povazuje za spasitele...

[Kyosuke]

Konceptuelně je XSLT fajn, ale celkový návrh toho jazyka je fakt brutální... Nedivím se schemerům, že vytvořili SXSLT a udělali z toho pořádný jazyk. YAML je spíš nástroj na serializaci všelijakých objektů, a to ve formátu, na kterém se víceméně dohodli rubisté, pythonisté, perlaři a další podobná havěť, což je trošku uitečnější, než když má každý svoje, jako tomu bylo doposud. Takže to prostě míří trošku jinam, páč XML je jazyk na serializaci XML infosetu , ale na data typu "tabulka uživatelů" a podobně mi přijde pořád ještě lepší YAML, obzvlášť pokud do toho člověk musí lozit editorem ručně.

[Miloslav Ponkrác]

Až bude něco lepšího, než XSLT rád to uvítám, protože XSLT je hrozné. Já osobně když porovnám YAML a XML, tak mi přeci jen přijde XML trochu koncepčnější, a raději budu serializovat do XML, než do YAML.

Koneckonců v Pythonu jsem se nemálo napsal a nemálo jsem komunikoval i s dalšími pythonisty, ale zásadně tam šlo vše do XML, o YAMLu jsem ani neslyšel. Poprvé jsem slyšel o YAMLu u Ruby, ale tam mě to nepřekvapuje, tam jsou na proprietární vymyšleniny experti a navíc jim tam dělá problémy Unicode, které japonský autor Ruby jaksi z principu nesnáší, takže v Ruby Unicode není a stringy jsou vnitřně jen bloky bajtů. Takže se nedivím, že s těmito problémy si Ruby raději ukuchtilo něco svého.

Proto mě pak docela překvapilo, že Python by údajně se měl podílet na YAML, navíc když si fulltextově dám prohledat celý oficiální pythonovský manuál, tak na slovo YAML tam najdu nula výskytů. Zatímco na XML tam najdu hned minimálně 3 různé knihovny pro práci. Takže je jasné, co se u Pythonu používá.

[Kyosuke]

Zatímco na XML tam najdu hned minimálně 3 různé knihovny pro práci.

Ano, a všechny tři jsou odporné a použitelné jen s krajním sebezapřením. Pro mě jako kdyby tam vůbec nebyly, já jsem rád, že tam pořád ještě jsou, jen kvůli zpětné kompatibilitě se softwarem, co je používá. Jediná pořádná XML knihovna pro Python, kterou jsem aspoň trochu ochoten vzít na milost, je lxml. ElementTree API je ještě rozumně použitelné, ale v "referenční implementaci" mi chybí pořádný XPath, takže od lxml mě nikdo neodtrhne.

[Miloslav Ponkrác]

Jenže tento stav má opět na svědomí W3C, W3C už zmastila špatně leccos. Celé DOM je dílo W3C komise - a to jejich "flattened OOP modelu" a velkým ústupkům Javě, kterážto jako jazyk moc abstraktních prostředků chudinka nemá, ale W3C to tedy udělala hlavně pro ní. SAX pak vzniknul jako průmyslový standard jak procházet obrovské dokumenty bez toho aniž by to všechno naráz leželo v paměti jak si představuje W3C (která vymyslela DOM model tak nešikovně, že to leží v paměti občas i několikrát).

Tudíž to musíte brát tak, že prostě DOM/SAX je základ a nad tím je třeba vystavět jinou lepší knihovnu, která nabídne lepší API. No a to je potřeba ještě vymlátit.

Co W3C dělá, prostě špatně a nedomyšleně dělá, to platí už nějakou dobu ...

[Daniel Kvasnička ml.]

ale na data typu "tabulka uživatelů" a podobně mi přijde pořád ještě lepší YAML, obzvlášť pokud do toho člověk musí lozit editorem ručně.

To byste se divil. Me je XML na editaci moc prijemne a to z jedhono duvodu -- ze je vizualne symetricke. Vidim, kde tag konci a kdyz to mam rozumne zformatovany, tak vim, k cemu ze tenhle koncovej tag patri. U YAMLu tezko.

[Kyosuke]

Z téhož důvodu já používám S-výrazy... Pokud se dotyčný výraz vejde na jednu obrazovku, což se mi většinou děje, zvlášť u kódu , tak je pro mě uniformní indentace mnohem lepším vizuálním pomocníkem než koncová značka. Samozřejmě u stromové struktury přes celý velký soubor můžou koncové značky začít být výhodné, ale to jsou právě ty dokumentové soubory, u kterých, jak píšu, mi XML nevadí. Nicméně kolem sebe zvláště od Vimařů slyším, že dotyční XML nepoužívají, pokud nemusejí. (Čestnou výjimkou je DocBook, což je ovšem pochopitelné, protože to je případ, kdy se kladivem opravdu zatlouká hřebík a ne vrut, a tehdy si rozumní lidé to kladivo opravdu vezmou.)

[Miloslav Ponkrác]

Jo jo, DocBook se mi taky líbí. Jen by bylo dobré, kdyby existoval na Windows nějaký balík, který by nástroje pro DocBook prostě zaráz nainstaloval. Jinak je to brutální a rozchodit to na winech je hrůza, děs a utrpení.

[Daniel Kvasnička ml.]

Co presne myslite "nastroji pro DocBook"? Neni to v podstate jen sada XSL/XSL-FO stylesheetu a nejaky ten Saxon a Apache FOP? (O DocBOoku toho zas az tak moc nevim, tak mozna jsem neco prehledl)

[Miloslav Ponkrác]

Ano, myslím tím v podstatě jen něco co přechroustá DocBookové XML a vyjde z něho několik základních formátů. Kdysi jsem to zprovoznil jako skripty a vyšlo z toho HTML na jednu stránku, HTML na moc stránek, TeX, RTF, PDF, soubor nápovědy. Dost se mi to líbilo, ale pak klekl disk a při pomyšlení, že bych to musel dávat dohromady znovu na to raději kašlu. Ale kdyby to někde existovalo...

[Daniel Kvasnička ml.]

Nicméně kolem sebe zvláště od Vimařů slyším, že dotyční XML nepoužívají, pokud nemusejí.

<flame>Vim neumi automaticky uzavirat tagy nebo zvyraznovat XML syntaxi? </flame>

[Kyosuke]

Rzohodně umí s XML hůř než Emacs. nXML v Emacsu je lepší než motorová pila v DOOMu. Ale jinak jsem vděčný aspoň za ten XML Copy Editor, i když by mohl umět trošku víc. Celkově to je škoda, ale deduktivně mi přijde, že absence pořádného XML režimu pro Vim se dá vysvětlit jedině nenávistí vimařů vůči XML. (Ovšem jestli mi teď nějaký vimař neexistenci pořádného vimího balíku pro XML vyvrátí sporem, nebudu se ani trošku zlobit. )

[Miloslav Ponkrác]

Ono je to spíš tím, že to pro vim nikdo nenaprogramoval. Nic jiného v tom nehledejte. On je totiž vim (přestože ho výhradně používám) v některých věcech až moc jednoduchý - třeba se mi z něj nedaří vyrazit zobrazení plného Unicode, a leccos se až příliš lepí. Takže podpora XML by nejspíš asi byla nalepená jako binárka (něco v C jako .so, nebo .dll), případně naprogramovaná v Pythonu (podle Brama nejlepší skriptovací jazyk). Ale vim se s podporou Pythonu standardně nedodává a při pokusu jej zkompilovat jsem narazil to Bramovo hnusné AAP, které cpe každému (jako náhradu makefile) na potkání, kdokoli chce vim vyvíjet, tak jsem s kompilací vimu skončil a stahuji jenom binárky. Tím skončil i můj pokus v Pythonu napsal lepší podporu XML.

[Miloslav Ponkrác]

Ale ano, souhlasím, XML se moc cpe do věcí, kam se skutečně nehodí jen proto, že je to to super XML. YAML není alternativa k XML, to také souhlasím.

Na XML se nehází špína, možná v odborných kruzích se sem tam pípne, že se XML nadužívá, ale v reálu je XML používáno více, než si zaslouží.

A znovu říkám, o YAML se nemusíme bavit, to je prostě směšná záležitost typu, jakých si u Ruby vymysleli spousty, YAML je IMHO velmi nedomyšlená a nedotažená věc. YAML jsem nikdy v životě nepoužil, protože tady to XML je opravdu podle mého názoru lepší.

Chtěl jsem jen napsat, že každá technologie dotažená do konce je užitečná na určité oblasti použití - a sám XML poměrně často používám. Je fajn, že jsou na XML v každém jazyce dotažené parsery, někdy i několik - skoro všude najdete aspoň DOM a SAX, je fajn, že jsou na to nástroje, transformace (nejen XSLT) apod., a to je velmi příjemné. Na druhé straně je dnes XML už moloch, a je mnoho použití, kde se XML používá jen proto, že je to XML, i když tam v podstatě překáží.

[Kyosuke]

...YAML se nemusíme bavit, to je prostě směšná záležitost typu, jakých si u Ruby vymysleli spousty, YAML je IMHO velmi nedomyšlená a nedotažená věc.

Ale? Že o tom tolik víte... FYI, YAML rozhodně nevymysleli rubisté, ti ho jen přijali.

[Miloslav Ponkrác]

Vím o tom naporsté prdlajs, to se přiznám bez mučení. Aplikaci s YAML jsem viděl jen u Rubistů, nikde jinde.

[Messa]

XML strom by mohl být uložený na disku, jeho části rychle přístupné přes index... (IMHO) Ale to už by byla spíš objektová (nebo stromová ) databáze, a tomu bych XML databáze neříkal - proč to omezovat na XML...

[,/.]

hahahaha, no ja z toho normalne smichy nemuzu Lepsi vtip nez tvuj zdrojovy kod asi dlouho neuvidim, )))