Změny v Nette\Config pro verzi 2.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.

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)

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 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)

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

tohle jde :)

Á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.

kravčo napsal(a):

Áno, chápete to nesprávne.

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

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

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

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

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)

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

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… ;-)

„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 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

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 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…

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

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

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.

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. ? :)