Změny v Nette\Config pro verzi 2.0

Upozornění: Tohle vlákno je hodně staré a informace nemusí být platné pro současné Nette.
srigi
Nette Blogger | 555
+
0
-

Bude sa YAML kompilovat do cache ako PHP array? Tak to ma Symfony, aby sa nemusel YAML parsovat pri kazdom rq. Okrem toho spravanie je take, ze v development env sa YAML konfiguraky necachuju ale v production ano.

despiq
Člen | 320
+
0
-

zvlastni chovani

neon:
test:
    - [here, and]
    - {then: press, control: enter}
    - {acer: "neco jineho", neco: 'sad asd asd'}
    - {acer: "neco jineho", neco: 'sad asd asd'}

vs

neon:
    - [here, and]
    - {then: press, control: enter}
    - {acer: "neco jineho", neco: 'sad asd asd'}
    - {acer: "neco jineho", neco: 'sad asd asd'}

Editoval despiq (10. 5. 2010 20:52)

Mikulas Dite
Člen | 756
+
0
-

despiq napsal(a):

zvlastni chovani …

Zápis polí podle odsazení ještě není implementovaný? Parser super i tester super, ten ale občas vrací server error.

Editoval Mikulas Dite (10. 5. 2010 21:04)

jansfabik
Člen | 193
+
0
-

David Grudl napsal(a):
To bych asi nechal na post-processing, aby bylo načítání souboru nezávislé na prostředí (což fakticky vedlo kdysi dávno ke zrušení kešování konfigurace) a stejně tak i dědičnost. Protože klíče v konfigu mohou mít mezery a znak <, není problém:

development < common:
   php:
      date.timezone: Europe/Paris

Bude možné používat i dědičnost z YAML?

Honza Marek
Člen | 1664
+
0
-

Je to rozbitý.

žluťoučký: kůň

dává špatnou diakritiku

array(1) {
   "\x9elu\x9dou\xe8k\xfd" => string(3) "k\xf9\xf2"
}

A pak tu mám ještě nějaký prase error (unexpected žluťoučký blabla):

test:
  - [here, and]
  - {then: press, control: enter}
žluťoučký: kůň

Tohle přitom funguje v poho až na koně (viz výše):

neon:
test:
  - [here, and]
  - {then: press, control: enter}
žluťoučký: kůň
Ola
Člen | 385
+
0
-

Honza Marek napsal(a):
A pak tu mám ještě nějaký prase error (unexpected žluťoučký blabla):

test:
  - [here, and]
  - {then: press, control: enter}
žluťoučký: kůň

Zajímavý je, že i když se před to dá jen prázdnej řádek, tak to jede :-)

Editoval Ola (10. 5. 2010 22:51)

redhead
Člen | 1313
+
0
-

Já bych teda hlavně předpokládal jiné chování už v tom základním zápisu

neon:
  - [here, and]
  - {then: press, control: enter}

By podle mě mělo vyblít array(‚neon‘ ⇒ array(..)); a ne array(‚neon‘ ⇒ NULL, array(..));

Chápu to blbě?

Editoval redhead (10. 5. 2010 23:18)

despiq
Člen | 320
+
0
-
neon:
neon:
  - [here, and]
  - {then: press, control: enter}

tohle jde :)

Honza Marek
Člen | 1664
+
0
-

redhead napsal(a):

Já bych teda hlavně předpokládal jiné chování už v tom základním zápisu

neon:
  - [here, and]
  - {then: press, control: enter}

By podle mě mělo vyblít array(‚neon‘ ⇒ array(..)); a ne array(‚neon‘ ⇒ NULL, array(..));

Chápu to blbě?

Já bych to taky čekal.

kravčo
Člen | 721
+
0
-

Áno, chápete to nesprávne.

Zápis

neon:
  - hello
  - world

je ekvivalentom

neon: {
  hello,
  world,
}

pričom (aspoň mne) príde lepšie čitateľný. Viď YAML.

redhead
Člen | 1313
+
0
-

@Kravčo: No právě, že není.. Takhle jsem to myslel taky..

Ale ono to vyblije

array(
	'neon' => NULL,
	'hello',
	'world'
);

místo

array(
	'neon' => array(
		'hello',
		'world'
	)
);

Aspoň podle tvého zápisu ekvivalentu, bych to tak čekal. Nebo to stále nechápu.. :(

Honza Marek
Člen | 1664
+
0
-

kravčo napsal(a):

Áno, chápete to nesprávne.

My to chápem, parser to nechápe. Ale je to očividně bug.

David Grudl
Nette Core | 7823
+
0
-

Je vůbec možné, že tolik chyb dokáže způsobit jeden chybějící znak ve zdrojáku? :-) Fixed

David Grudl
Nette Core | 7823
+
0
-

jansfabik napsal(a):
Bude možné používat i dědičnost z YAML?

Co je to dědičnost z YAML? Jsem YAMLlajk.

blacksun
Člen | 177
+
0
-

Jamlajka? První yaml pes..

jansfabik
Člen | 193
+
0
-

David Grudl napsal(a):

jansfabik napsal(a):
Bude možné používat i dědičnost z YAML?

Co je to dědičnost z YAML? Jsem YAMLlajk.

v YAML existují aliasy:

# obě hodnoty jsou identické
value1: &ANCHOR "první hodnota"
value2: *ANCHOR

v PyYAML (a jeho odvozeninách) se dá zapisovat:

map1: &ANCHOR1
  value1: "první hodnota"
  value2: "druhá hodnota"

map2: &ANCHOR2
  value3: "třetí hodnota"
  value4: "čtvrtá hodnota"

map3:
  <<: *ANCHOR1
  <<: *ANCHOR2
  value5: "pátá hodnota"

výsledek v PHP:

$map1 = array("value1" => "první hodnota", "value2" => "druhá hodnota");
$map2 = array("value3" => "třetí hodnota", "value4" => "čtvrtá hodnota");
$map3 = $map1 + $map2 + array("value5" => "pátá hodnota");

dále mají aliasy tu výhodu, že můžu vytvořit objekt a potom použít jeho instanci vícekrát

JajazXbm
Člen | 29
+
0
-

Já nějak pořád nechápu proč se vymýšlí nový jazyk, proč se implementuje nový parser. Má to spoustu nevýhod a nenapadá mě příliš mnoho výhod. Nebylo by nejjednodušší přeskočit parser a psát ten config rovnou v php poli? Stejnak ty configy píší programátoři, kteří vytvářet pole umí. Tím by se obešel parser, který jenom zdržuje. Nemusel by se zavádět další speciální jazyk.
Pole v php by mělo i výhody, že by se daly při jeho konstrukci používat ostatní php vlastnosti. Jednoduše by šlo v configu napsat:

	if (isLeapYear()) {
		$config['production']['database']['name'] = 'databaze';
	} else {
		$config['production']['database']['name'] = 'dat';
	}
Šaman
Člen | 2599
+
0
-

Myslím, že důvod je ten, že config.ini je soubor který si může upravovat i neprogramující uživatel (provozovatel) aplikace. Jinak by to mohl být config.php (jako u mě donedávna byl:)

Editoval Šaman (13. 5. 2010 9:35)

wotaen
Člen | 82
+
0
-

Šaman napsal(a):

Myslím, že důvod je ten, že config.ini je soubor který si může upravovat i neprogramující uživatel (provozovatel) aplikace. Jinak by to mohl být config.php (jako u mě donedávna byl:)

Na druhou stranu zásah do config.ini je zásahem do aplikace (se všemi důsledky vyplívajícími – nefunkční db, emaily apod) a měla by to provádět osoba na určité technické úrovni. A pokud bude na takové technické úrovni, tak už je celkem jedno jestli edituje
database.host:localhost nebo [‚database‘][‚host‘] = ‚localhost‘ (příklad)
Volbou vhodného zápisu php se dá zajistit čitelnost i pro neprogramujícího uživatele.
Navíc si dovedu představit, že v novém zápisu konfiguráku se časem uchytí další a další fičury, které budou horkotěžko emulovat normální prg. jazyk

despiq
Člen | 320
+
0
-

psani nastaveni do configu je pro mne zdaleka prehlednejsi a srozumitelnejsi na prvni pohled nez zapsani v php

take to nesvadi k nejakym hloupostem jako podminky, to bych rekl ze do konfiguracniho souboru vubec nepatri

noa nakonec je tu srozumitelnost pro nove prichoziho ktera je podle me bezdebat jednoznacna

David Grudl
Nette Core | 7823
+
0
-

Parser se vymýšlí, protože je potřeba parsovat anotace.

buff
Člen | 63
+
0
-

despiq napsal:
noa nakonec je tu srozumitelnost pro nove prichoziho ktera je podle me bezdebat jednoznacna

V dnešním .ini ještě snad ano (snad až na ta většítka v názvu sekcí). Ale když tam bude YAML, který ještě navíc nebude tak docela YAML, tak ta srozumitelnost IMHO dost utrpí.

David Grudl (dávno) napsal přibližně toto:
Srovnej si [příklad YAMLu] a [příklad JSONu]

Ano. Ale u hlubších datových struktur se ta ukecanost minimálně vyrovná velkým počtem mezer nesoucích význam v YAMLu. A já raději uvozovky než nutnost pečlivě hledět na neviditelné mezery a taby (Ale chápu, že to je věc vkusu).

David Grudl napsal:
Parser se vymýšlí, protože je potřeba parsovat anotace.

Sjednocení jazyků v configu a v anotacích (a snad i jinde) beru jako dobrý směr. Ale nový jazyk jako špatný směr. To jen můj názor; chápu že už to asi jinak nebude, když je parser prakticky hotov… ;-)

Honza Marek
Člen | 1664
+
0
-

buff napsal(a):

despiq napsal:
noa nakonec je tu srozumitelnost pro nove prichoziho ktera je podle me bezdebat jednoznacna

V dnešním .ini ještě snad ano (snad až na ta většítka v názvu sekcí). Ale když tam bude YAML, který ještě navíc nebude tak docela YAML, tak ta srozumitelnost IMHO dost utrpí.

„Dnešní ini“ je dost hrozné. Divný zápis polí, nemožnost zapsat do klíče skoro žádné zvláštní znaky, podsekce dělané tečkovým hackem,…

despiq
Člen | 320
+
0
-

„Dnešní ini“ je dost hrozné

to je velice relativni, to ze nenabizi spoustu moznosti predci neznamena ze je hrozne, ale znamena to ze napriklad nevyhovuje pozadavkum narocnejsiho programatora

nicmene predpokladam ze php parser na ini soubory je podle nejakyho standartu, ini soubory predce nevznikly s phkem

Honza Marek
Člen | 1664
+
0
-

Ini je nevyhovující požadavků nette config.ini souboru :) Nad nativním parserem je v současné době nadstavba, která ohackovává všechny pokročilejší možnoti nette config.ini souboru. Proto vznikla diskuze o novém formátu config souboru.

despiq
Člen | 320
+
0
-

Honza Marek napsal(a):

Ini je nevyhovující požadavků nette config.ini souboru :) Nad nativním parserem je v současné době nadstavba, která ohackovává všechny pokročilejší možnoti nette config.ini souboru. Proto vznikla diskuze o novém formátu config souboru.

noatake kvuli parsovani anotaci jak psal David drive

David Grudl
Nette Core | 7823
+
0
-

buff napsal(a):

Ano. Ale u hlubších datových struktur se ta ukecanost minimálně vyrovná velkým počtem mezer nesoucích význam v YAMLu. A já raději uvozovky než nutnost pečlivě hledět na neviditelné mezery a taby (Ale chápu, že to je věc vkusu).

V syntaxi neon není třeba hledět na mezery, ale i tento zápis bude připouštět. Je to na volbě programátora.

Parser se vymýšlí, protože je potřeba parsovat anotace.

Sjednocení jazyků v configu a v anotacích (a snad i jinde) beru jako dobrý směr. Ale nový jazyk jako špatný směr. To jen můj názor; chápu že už to asi jinak nebude, když je parser prakticky hotov… ;-)

Jaký je tedy jiný směr? Čím parsovat anotace?

buff
Člen | 63
+
0
-

Upřímně a bez mučení přiznávám, že vím pramálo o anotacích. Pokud vím, jsou to speciální komentáře, které se dají pomocí reflection načíst a nepřímo tak ovlivňují chod programu. Uvítám zpřesnění i ujasnění, proč se nedají zapisovat v nějakém existujícím jazyce a parsovat existujícím parserem…

Petr Motejlek
Člen | 293
+
0
-

Nevím, čím parsovat anotace, ale nejradši bych byl, aby se u nich znovu nevymýšlela syntax. Zůstal bych u nečeho co zdánlivě připomíná PHP, ale lehce osekaný o volání fcí a metod. Takže něco, co je třeba hodně blízko syntaxi Javy (EDIT: syntaxi anotací Javy ;)). Podle mě by bylo dobře, kdyby si jednu anotaci šlo představit jako zápis pole, takže něco jako

<?php
/**
 * @MyAnnotation('A' => 20, 'B' => 30, 'C' => true, 'D' => null)
 */
?>

S tím, že by se mi líbilo, kdyby se musela dodržovat striktní syntax, která už je v PHP daná, tzn. řetězec je obalený '', nebo "". Ulehčilo by to nějakou práci s ručním domýšlením, co asi chtěl básník říct, když psal tuhle anotaci… ;)

Editoval Petr Motejlek (28. 5. 2010 11:14)

kravčo
Člen | 721
+
0
-

Petr Motejlek napsal(a):

Zůstal bych u nečeho co zdánlivě připomíná PHP, ale lehce osekaný o volání fcí a metod.

David zvolil štandard YAML a osekal ho na úroveň, ktorá umožňuje napísať rýchly parser.

Sám som sa svojho času YAMLom zaoberal a musím len súhlasiť, že na (štruktúrovaný) konfigurák nepoznám lepší formát… Po pridaní tabulátorov to platí dvojnásobne…

Petr Motejlek
Člen | 293
+
0
-

Já odpovídám na ty otázky ohledně anotací, ne konfiguráku…

Honza Marek
Člen | 1664
+
0
-

Když je hotový parser, co brání přejít ve vývojové verzi na config.yaml soubory?

Jan Tvrdík
Nette guru | 2595
+
0
-

Spíš config.neon, ne?

Honza Marek
Člen | 1664
+
0
-

Jan Tvrdík napsal(a):

Spíš config.neon, ne?

A budu pak muset přenastavovat IDE, aby si o *.neon myslel, že je to yaml? To tak :-D

Majkl578
Moderator | 1364
+
0
-

Honza Marek napsal(a):

Když je hotový parser, co brání přejít ve vývojové verzi na config.yaml soubory?

Když už tak yml, ne?

Ale jsem pro .neon.

Patrik Votoček
Člen | 2221
+
0
-

Pokud popátráte v nové docce tak je tam jasně od Davida uvedeno config.neon. Btw taky se celkem divím že stále neexistuje driver pro konfigurák.

kravčo
Člen | 721
+
0
-

Honza Marek napsal(a):

Jan Tvrdík napsal(a):

Spíš config.neon, ne?

A budu pak muset přenastavovat IDE, aby si o *.neon myslel, že je to yaml? To tak :-D

Niektoré IDE správne zvýrazňujú tabulátor v YAML ako neplatný znak v odsadení, keďže gramtika YAML striktne vyžaduje odsadenie medzerami. Ale možno to bude lepšie ako si myslím…

westrem
Člen | 398
+
0
-

Ahoj,
chcem sa spytat v akom stave je NeonParser? Pozeram, ze je sucastou distribucie pre Nette 1.0 ale je aj funkcny? Ked si tak prezeram kod, je tam este jedno TODO :).

Je mozne ho nasadit na parsovanie nejakych textov v tu na fore uvedenom formate alebo si mam este pockat do 19.9. ? :)