<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Dlaczego konfiguracja w XML.</title>
	<atom:link href="http://blog.dywicki.pl/2006/09/07/dlaczego-konfiguracja-w-xml/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.dywicki.pl/2006/09/07/dlaczego-konfiguracja-w-xml/</link>
	<description>Pragmatyzm kontrolowany</description>
	<lastBuildDate>Wed, 28 Dec 2011 11:54:05 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=abc</generator>
	<item>
		<title>By: MeME</title>
		<link>http://blog.dywicki.pl/2006/09/07/dlaczego-konfiguracja-w-xml/comment-page-1/#comment-25998</link>
		<dc:creator>MeME</dc:creator>
		<pubDate>Sat, 26 Apr 2008 12:54:56 +0000</pubDate>
		<guid isPermaLink="false">http://blog.dywicki.pl/2006/09/07/dlaczego-konfiguracja-w-xml/#comment-25998</guid>
		<description>Witam,

Google mi mówi, że ta witryna może wyrządzić szkody w moim komputerze?

-- 
Pozdrawiam
MM</description>
		<content:encoded><![CDATA[<p>Witam,</p>
<p>Google mi mówi, że ta witryna może wyrządzić szkody w moim komputerze?</p>
<p>&#8211;<br />
Pozdrawiam<br />
MM</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Splatch&#8217;s devblog &#187; Blog Archive &#187; Wygodny edytor do konfiguracji XML</title>
		<link>http://blog.dywicki.pl/2006/09/07/dlaczego-konfiguracja-w-xml/comment-page-1/#comment-11254</link>
		<dc:creator>Splatch&#8217;s devblog &#187; Blog Archive &#187; Wygodny edytor do konfiguracji XML</dc:creator>
		<pubDate>Thu, 02 Aug 2007 21:46:22 +0000</pubDate>
		<guid isPermaLink="false">http://blog.dywicki.pl/2006/09/07/dlaczego-konfiguracja-w-xml/#comment-11254</guid>
		<description>[...] możliwości. Troszkę dywagacji na ten temat było jakiś czas temu w poście pod tytułem &#8220;Dlaczego konfiguracja w XML&#8220;. Jednym z problemów związanych z XMLem jest konieczność zapamiętania nazw znaczników i [...]</description>
		<content:encoded><![CDATA[<p>[...] możliwości. Troszkę dywagacji na ten temat było jakiś czas temu w poście pod tytułem &#8220;Dlaczego konfiguracja w <acronym title="eXtensible Markup Language">XML</acronym>&#8220;. Jednym z problemów związanych z XMLem jest konieczność zapamiętania nazw znaczników i [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: menic</title>
		<link>http://blog.dywicki.pl/2006/09/07/dlaczego-konfiguracja-w-xml/comment-page-1/#comment-3535</link>
		<dc:creator>menic</dc:creator>
		<pubDate>Tue, 06 Mar 2007 21:42:24 +0000</pubDate>
		<guid isPermaLink="false">http://blog.dywicki.pl/2006/09/07/dlaczego-konfiguracja-w-xml/#comment-3535</guid>
		<description>YAML moze jest na topie i jest cool, ale mi nie pasuje. Zgadzam sie ze Splatch&#039;em co do tej spacji w yaml&#039;u. Sam miałem taką sytuacje. GDzies było o jedna za duzo, badź był tabulator zamiast spacji i pare godzin w plecy ;)</description>
		<content:encoded><![CDATA[<p>YAML moze jest na topie i jest cool, ale mi nie pasuje. Zgadzam sie ze Splatch&#8217;em co do tej spacji w yaml&#8217;u. Sam miałem taką sytuacje. GDzies było o jedna za duzo, badź był tabulator zamiast spacji i pare godzin w plecy ;)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Splatch&#8217;s devblog &#187; Blog Archive &#187; Agavi 0.11 RC3, flow</title>
		<link>http://blog.dywicki.pl/2006/09/07/dlaczego-konfiguracja-w-xml/comment-page-1/#comment-3351</link>
		<dc:creator>Splatch&#8217;s devblog &#187; Blog Archive &#187; Agavi 0.11 RC3, flow</dc:creator>
		<pubDate>Fri, 23 Feb 2007 22:51:45 +0000</pubDate>
		<guid isPermaLink="false">http://blog.dywicki.pl/2006/09/07/dlaczego-konfiguracja-w-xml/#comment-3351</guid>
		<description>[...] łączenia konfiguracji, w końcu brak narzędzia do walidacji zapisanych danych. W poście &#8220;Dlaczego konfiguracja w XML&#8221; porównywałem XML również do YAMLa. Sporą zmianą, naturalnie, na lepsze było [...]</description>
		<content:encoded><![CDATA[<p>[...] łączenia konfiguracji, w końcu brak narzędzia do walidacji zapisanych danych. W poście &#8220;Dlaczego konfiguracja w <acronym title="eXtensible Markup Language">XML</acronym>&#8221; porównywałem <acronym title="eXtensible Markup Language">XML</acronym> również do YAMLa. Sporą zmianą, naturalnie, na lepsze było [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Vee</title>
		<link>http://blog.dywicki.pl/2006/09/07/dlaczego-konfiguracja-w-xml/comment-page-1/#comment-1112</link>
		<dc:creator>Vee</dc:creator>
		<pubDate>Sun, 24 Sep 2006 08:53:50 +0000</pubDate>
		<guid isPermaLink="false">http://blog.dywicki.pl/2006/09/07/dlaczego-konfiguracja-w-xml/#comment-1112</guid>
		<description>Te konfigurowanie wszystkiego w XMLu też już mnie rozbraja :/ A frameworki, gdzie każdą akcję opisuje się w XMLu to już jakiś idiotyzm dla mnie.

U mnie najczęśćiej konf to zwykły .php z podstawowymi sprawami jak dane do bazy i ścieżki. Reszta, to najczęściej konfiguracja dostępna dla urzytkownika - trzymana w tabelce bazy danych.

A te mody na YAMLe czy inne to już w ogole magia ;P</description>
		<content:encoded><![CDATA[<p>Te konfigurowanie wszystkiego w XMLu też już mnie rozbraja :/ A frameworki, gdzie każdą akcję opisuje się w XMLu to już jakiś idiotyzm dla mnie.</p>
<p>U mnie najczęśćiej konf to zwykły .php z podstawowymi sprawami jak dane do bazy i ścieżki. Reszta, to najczęściej konfiguracja dostępna dla urzytkownika &#8211; trzymana w tabelce bazy danych.</p>
<p>A te mody na YAMLe czy inne to już w ogole magia ;P</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Łukasz Dywicki</title>
		<link>http://blog.dywicki.pl/2006/09/07/dlaczego-konfiguracja-w-xml/comment-page-1/#comment-966</link>
		<dc:creator>Łukasz Dywicki</dc:creator>
		<pubDate>Sun, 10 Sep 2006 20:58:20 +0000</pubDate>
		<guid isPermaLink="false">http://blog.dywicki.pl/2006/09/07/dlaczego-konfiguracja-w-xml/#comment-966</guid>
		<description>@pawel_k
Wydaje mi się, że do plików językowych najlepsze będą pliki INI. Pliki te są szatkowane bardzo często, zwykle jest tak, że jeden request to kilka plików z tłumaczeniami. INI będzie parsowane znacznie szybciej niż jakikolwiek YAML. Tracimy w tym momencie na czytelności, ale co takiego potrzeba komuś kto tłumaczy teksty? Czy wcięcia w YAMLu są aż takie przydatne przy tłumaczeniu?
Wątpię.

@seaquest
&quot;Yaml, czy też ini są dużo szybsze od XML&quot;. Co do INI - bez wątpienia się zgodzę. Co do YAMLa nie. XML jest obsługiwany przez funkcje napisane w C - może to być od biedy SimpleXML. YAML to wyrażenia regularne i walonka z obróbką ciągów w samym PHP. IMHO w życiu parsowanie YAMLa w PHP nie dogoni XMLa, choć przy rozszeżeniu do YAMLa napisanym w C sytuacja bez wątpienia ulegnie zmianie.
Naturalnie YAML jest czasami czytelniejszy niż XML, ale jakoś nie porywa mnie on sam w sobie. Chodzi mi dokładnie o to, że jestem uzależniony od wcięć. Można się wkurzyć, kiedy po 2 godzinach walki z aplikacją okazuje się, że w jednym miejscu zabrakło jednej spacji. 
Jednym słowem XML jest dla mnie wystarczająco czytelny by tworzyć w nim konfiguracje a funkcjonalność, którą oferuje w połączeniu z innymi technologiami jest tym, czego YAML nigdy nie miał i mieć nie będzie. XML to nie tylko konfiguracja. YAML to tylko konfiguracja.</description>
		<content:encoded><![CDATA[<p>@pawel_k<br />
Wydaje mi się, że do plików językowych najlepsze będą pliki INI. Pliki te są szatkowane bardzo często, zwykle jest tak, że jeden request to kilka plików z tłumaczeniami. INI będzie parsowane znacznie szybciej niż jakikolwiek YAML. Tracimy w tym momencie na czytelności, ale co takiego potrzeba komuś kto tłumaczy teksty? Czy wcięcia w YAMLu są aż takie przydatne przy tłumaczeniu?<br />
Wątpię.</p>
<p>@seaquest<br />
&#8220;Yaml, czy też ini są dużo szybsze od <acronym title="eXtensible Markup Language">XML</acronym>&#8220;. Co do INI &#8211; bez wątpienia się zgodzę. Co do YAMLa nie. <acronym title="eXtensible Markup Language">XML</acronym> jest obsługiwany przez funkcje napisane w C &#8211; może to być od biedy SimpleXML. YAML to wyrażenia regularne i walonka z obróbką ciągów w samym <acronym title="Pre-Hypertext Processing">PHP</acronym>. <acronym title="In my humble opinion">IMHO</acronym> w życiu parsowanie YAMLa w <acronym title="Pre-Hypertext Processing">PHP</acronym> nie dogoni XMLa, choć przy rozszeżeniu do YAMLa napisanym w C sytuacja bez wątpienia ulegnie zmianie.<br />
Naturalnie YAML jest czasami czytelniejszy niż <acronym title="eXtensible Markup Language">XML</acronym>, ale jakoś nie porywa mnie on sam w sobie. Chodzi mi dokładnie o to, że jestem uzależniony od wcięć. Można się wkurzyć, kiedy po 2 godzinach walki z aplikacją okazuje się, że w jednym miejscu zabrakło jednej spacji.<br />
Jednym słowem <acronym title="eXtensible Markup Language">XML</acronym> jest dla mnie wystarczająco czytelny by tworzyć w nim konfiguracje a funkcjonalność, którą oferuje w połączeniu z innymi technologiami jest tym, czego YAML nigdy nie miał i mieć nie będzie. <acronym title="eXtensible Markup Language">XML</acronym> to nie tylko konfiguracja. YAML to tylko konfiguracja.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: pawel_k</title>
		<link>http://blog.dywicki.pl/2006/09/07/dlaczego-konfiguracja-w-xml/comment-page-1/#comment-953</link>
		<dc:creator>pawel_k</dc:creator>
		<pubDate>Sat, 09 Sep 2006 10:11:34 +0000</pubDate>
		<guid isPermaLink="false">http://blog.dywicki.pl/2006/09/07/dlaczego-konfiguracja-w-xml/#comment-953</guid>
		<description>@mike
to co napisałem powinno byc niedorzecznoscią i tez tak sadzilem az jeden koles nie wydzwanial do mnie bo mu strona nie dziala... jak sie okazalo przez panel admina na swoim home.pl zminil &quot;dla bezpieczenstwa&quot; haslo do bazy, nie uaktualizujac konfiga.

co do plikow z językiem to podtrzymuje swoje zdanie ze yaml jest znacznie lepszy niz xml bo to nie programista bedzie tlumaczyl aplikacje na kilka jezykow i tu nie jesmu n\ma byc wygodniej. i tu czytelnosc yamla sie przydaje.

tak na prawde nie ma sensu prowadzic nowej wojny w stylu cake vs symfony,wlasciwie to co mozna powiedziec to to ze racja jest jak dupa, kazdy ma wlasną...

 i yaml i xml maja swoje wady i zalety, a tak w rzeczywistosci to do koniguracji, bo o tym jest ten temat, nie nadaja sie z powodu ciaglego parsowania i trzeba to przez cache przerzucic zeby mialo sens.</description>
		<content:encoded><![CDATA[<p>@mike<br />
to co napisałem powinno byc niedorzecznoscią i tez tak sadzilem az jeden koles nie wydzwanial do mnie bo mu strona nie dziala&#8230; jak sie okazalo przez panel admina na swoim home.pl zminil &#8220;dla bezpieczenstwa&#8221; haslo do bazy, nie uaktualizujac konfiga.</p>
<p>co do plikow z językiem to podtrzymuje swoje zdanie ze yaml jest znacznie lepszy niz xml bo to nie programista bedzie tlumaczyl aplikacje na kilka jezykow i tu nie jesmu n\ma byc wygodniej. i tu czytelnosc yamla sie przydaje.</p>
<p>tak na prawde nie ma sensu prowadzic nowej wojny w stylu cake vs symfony,wlasciwie to co mozna powiedziec to to ze racja jest jak dupa, kazdy ma wlasną&#8230;</p>
<p> i yaml i xml maja swoje wady i zalety, a tak w rzeczywistosci to do koniguracji, bo o tym jest ten temat, nie nadaja sie z powodu ciaglego parsowania i trzeba to przez cache przerzucic zeby mialo sens.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: seaquest</title>
		<link>http://blog.dywicki.pl/2006/09/07/dlaczego-konfiguracja-w-xml/comment-page-1/#comment-952</link>
		<dc:creator>seaquest</dc:creator>
		<pubDate>Sat, 09 Sep 2006 07:03:33 +0000</pubDate>
		<guid isPermaLink="false">http://blog.dywicki.pl/2006/09/07/dlaczego-konfiguracja-w-xml/#comment-952</guid>
		<description>No właśnie. Yaml, czy też ini są dużo szybsze od XML&#039;a (mówię o samym procesie parsowania). Oczywiście robi się cache i wtedy te różnice szybkości pewnie nie są tak duże, ale wydaje mi się, że Yaml jest momentami bardziej czytelny niż XML.</description>
		<content:encoded><![CDATA[<p>No właśnie. Yaml, czy też ini są dużo szybsze od <acronym title="eXtensible Markup Language">XML</acronym>&#8216;a (mówię o samym procesie parsowania). Oczywiście robi się cache i wtedy te różnice szybkości pewnie nie są tak duże, ale wydaje mi się, że Yaml jest momentami bardziej czytelny niż <acronym title="eXtensible Markup Language">XML</acronym>.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: mike_mech</title>
		<link>http://blog.dywicki.pl/2006/09/07/dlaczego-konfiguracja-w-xml/comment-page-1/#comment-951</link>
		<dc:creator>mike_mech</dc:creator>
		<pubDate>Fri, 08 Sep 2006 22:20:51 +0000</pubDate>
		<guid isPermaLink="false">http://blog.dywicki.pl/2006/09/07/dlaczego-konfiguracja-w-xml/#comment-951</guid>
		<description>@pawel_k równie dobrze mogłeś zapytać: &quot;A co jak ciocia Zosia będzie chciała coś zmienić?&quot;
Wywoływanie tutaj jakiegoś szefa do zmiany czegkolwiek w aplikacji to już nawet nie abstrakcja tylko niedorzeczność.
Tak samo jak szef jak i jego klient będą oczekiwali kliknięcia, maksymalnie dwóch w celu zmiany czegokolwiek.
Więc wybór technologii sprowadza się do szybkości wydajności i wygody programisty, która wbrew pozorom wcale nie jest bez znaczenia. Więc jeśli szalony użyszkodnik ma okazję w ogóle grzebać w konfiguracji to znaczy że coś jest nie tak z projektem aplikacji.</description>
		<content:encoded><![CDATA[<p>@pawel_k równie dobrze mogłeś zapytać: &#8220;A co jak ciocia Zosia będzie chciała coś zmienić?&#8221;<br />
Wywoływanie tutaj jakiegoś szefa do zmiany czegkolwiek w aplikacji to już nawet nie abstrakcja tylko niedorzeczność.<br />
Tak samo jak szef jak i jego klient będą oczekiwali kliknięcia, maksymalnie dwóch w celu zmiany czegokolwiek.<br />
Więc wybór technologii sprowadza się do szybkości wydajności i wygody programisty, która wbrew pozorom wcale nie jest bez znaczenia. Więc jeśli szalony użyszkodnik ma okazję w ogóle grzebać w konfiguracji to znaczy że coś jest nie tak z projektem aplikacji.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: pawel_k</title>
		<link>http://blog.dywicki.pl/2006/09/07/dlaczego-konfiguracja-w-xml/comment-page-1/#comment-950</link>
		<dc:creator>pawel_k</dc:creator>
		<pubDate>Fri, 08 Sep 2006 19:28:56 +0000</pubDate>
		<guid isPermaLink="false">http://blog.dywicki.pl/2006/09/07/dlaczego-konfiguracja-w-xml/#comment-950</guid>
		<description>moim zdaniem kwestia jes inna; konfiguracja powinna być stała i się nie zmieniać (lub niezby często sie zmieniac). a co za tym idzie, najlepiej powinna być zrobiona w samym php. idąc tym tropem, jeśli już korzystamy z xml&#039;a czy yaml&#039;a config powinien byc keszowany, zeby niepotrzebnie nie marnować czasu na przetwarzanie czy to xml&#039;a, yamla czy nawet plików ini.
teraz pytanie - czy jak szef firmy będzie chciał zmienić koniguracje to czy będzie mu wygodniej pisac w xml czy yaml? czy osoba tłumacząca plik internacjonalizacji bedzie bardziej zadowolona z yaml&#039;a czy xml&#039;a? oczywiscie problemem nie powinien byc zadem przypadek ale jacy ludzie są wszyscy wiemy :/
moim zdaniem jesli wszyskim zajmuje sie programista, to raczej bedzie mu wszystko jedno i wybierze odpowiadajace mu rozwiazanie, jesli wkracza szalony uzyszkodnik lepiej pozostawic mu yaml&#039;a.
na koniec dodam ze yaml nie został stworzony do tego w czym dobry jest xml - czyli do wymiany danych.</description>
		<content:encoded><![CDATA[<p>moim zdaniem kwestia jes inna; konfiguracja powinna być stała i się nie zmieniać (lub niezby często sie zmieniac). a co za tym idzie, najlepiej powinna być zrobiona w samym php. idąc tym tropem, jeśli już korzystamy z xml&#8217;a czy yaml&#8217;a config powinien byc keszowany, zeby niepotrzebnie nie marnować czasu na przetwarzanie czy to xml&#8217;a, yamla czy nawet plików ini.<br />
teraz pytanie &#8211; czy jak szef firmy będzie chciał zmienić koniguracje to czy będzie mu wygodniej pisac w xml czy yaml? czy osoba tłumacząca plik internacjonalizacji bedzie bardziej zadowolona z yaml&#8217;a czy xml&#8217;a? oczywiscie problemem nie powinien byc zadem przypadek ale jacy ludzie są wszyscy wiemy :/<br />
moim zdaniem jesli wszyskim zajmuje sie programista, to raczej bedzie mu wszystko jedno i wybierze odpowiadajace mu rozwiazanie, jesli wkracza szalony uzyszkodnik lepiej pozostawic mu yaml&#8217;a.<br />
na koniec dodam ze yaml nie został stworzony do tego w czym dobry jest xml &#8211; czyli do wymiany danych.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

