Změny v Nette\Config pro verzi 2.0

Dále jsou tu adaptéry pro načítání a ukládání konfigurace do souborů. Mám za to, že schopnost ukládat nikdo nevyužívá (nebo ano?)

Ukládání využívá Ormion. A kdyby třída Environment uměla načíst více konfiguračních souborů, tak bych tim asi generoval nějaký nastavení aplikace.

Jo a Ormion využívá jen ConfigAdapterIni, stačí mi načíst a uložit pole, použití třídy Config by mi nepřineslo žádnou výhodu.

To ukládání využíváš jako určitou formu cache?

ad Environment a konfigurace: to nechme na další vlákno.

myslim, ze ked importujes iba nejaku sekciu configu, zmenis nieco, das ulozit, ostatne sekcie uz vo vygenerovanom subore nie su. ale je to uz trochu dlhsie co som toto riesil.

David Grudl napsal(a):

Má představa je taková, že třída Nette\Config\Config by se mohla zjednodušit až na úroveň primitivní přenosky dat s vlastností, že k jejím prvkům lze přistupovat přes $config->item a zároveň přes $config['item']. Váhám, zda neexistující klíče mají vracet tiše NULL nebo upozornit – buď přes E_xxx nebo výjimkou.

Souhlas + tiché vracení NULL za předpokladu funkčnosti isset($config['klic']).

Dále se mi zdá, že by bylo dobré:

• načítání více config souborů
• možnost zkratky pro přístup k prvkům v sekcích $config['database/username']

David Grudl napsal(a):
Nebo INI nahradit jiným formátem…

YAML by nebyl od věci přesně ze zníměných důvodů – především omezenosti INI formátu.

Ukládání bych určitě nerušil. To že se zruší uživatelské formátování a komentáře je samozřejmost a člověk s tím počítá. Neviděl bych to jako důvod k odstranění.

Tiež by som bol za pridanie načitavania viacerych configov. Aby sa to nemuselo obchadzať ako je to tu: /cs/2634-nacteni-vice-konfiguracnich-souboru

Editoval Cifro (27. 4. 2010 23:20)

Co třeba JSON? Jeho použití by myslím hodně prospělo i config.ini souboru. JSON zachovává výhody ini souboru a má trochu širší možnosti, takže můžu mít třeba klíče jaké chci a navíc by mohla zmizet spousta další magie v config.ini souboru.

{
	common: {

		php: {
			"date.timezone": "Europe/Prague",
			"iconv.internal_encoding": "UTF-8",
			"mbstring.internal_encoding": "UTF-8"
		},

		variable: {
			lang: "en",
			tempDir: "%appDir%/temp",
			logDir: "%appDir%/log"
		},

		service: {
			"Nette\\Security\\IAuthenticator": "UsersModel",
			"Nette\\Loaders\\RobotLoader": {
				option: {
					directory: ["%appDir%", "%libsDir%"]
				},
				run: true
			}
		}
	},

	"production < common": {
		database: {
			host: "127.0.0.1",
			//...
		}
	},

	"development < common": {

	}
}

Osobně se mi to hrozně líbí a přijde mi to o dost přehlednější než ini soubor.

Ty uvozovky okolo dedicich zapisu jsou dost divny
bez dedeni pises bez uvozovek a pri dedeni s to je divny ne?

prehledny to je o tom zadna ale to vyse mi prijde zvlastni

Honza Marek napsal(a):

Co třeba JSON?

Nějaký takový jednoduchý formát by mi vyhovoval:

common:
  php:
    date.timezone: Europe/Prague
    iconv.internal_encoding: UTF-8
    mbstring.internal_encoding: UTF-8

  variable:
    name: František Dobrota :-)  ; tohle je kometář
    string: " delimited string \x0A "
    tempDir: %appDir%/temp
    logDir: %appDir%/log

  service:
    Nette\Security\IAuthenticator: UsersModel

    Nette\Loaders\RobotLoader:
      option:
        directory: [%appDir%, %libsDir%]
      run: TRUE

To by se dalo parsovat „jen“ asi jednou tak pomaleji než funguje současné řešení via INI. (Zkoušel jsem YAML parser ze Symfony a ten jen 20× pomalejší). Výhodou oproti INI je naprostá volnost pokud jde o používání znaků v klíčích a hodnotách.

Problém vidím v závádění další syntaxe, přitom hodně podobné YAMLu.

Případně ještě jednodušší alternativa pro zápis pole:

Nette\Loaders\RobotLoader:
  option:
    directory:
      - %appDir%
      - %libsDir%
  run: TRUE

Při tomto zápisu by bylo výhodnější options oproti option apod.

Yrwein napsal(a):

http://components.symfony-project.org/yaml/

Uvažoval jsem nad tím, ale je to pomalé. Pro mírně jednodušší syntax dovedu napsat 10× rychlejší parser. Otázka je, zda-li je lepší kešovat, nebo zavádět novou syntax.

Teď mně tak napadlo… JSON?

Zavádění další syntaxe bych se vyhnul. Syntaxí je i tak spousta – proč pro konfiguraci další?

Imho je lepší kešovat než zavádět novou syntax.

Když se na to člověk podívá selským rozumem: Proč parsovat (byť seberychlejším parserem) něco co se vůbec nemění?

Mimoto YAML má spoustu fičur, které z něj dělají daleko silnější nástroj. Např. reference nebo aliasy.

Honza Marek napsal(a):

despiq napsal(a):

Ty uvozovky okolo dedicich zapisu jsou dost divny
bez dedeni pises bez uvozovek a pri dedeni s to je divny ne?

Pokud se v klíči vyskytují mezery a jiné divné znaky, tak tam ty uvozovky být musí. Jinak ne.

Pokud by sis to nechtěl pamatovat, tak bys je mohl psát všude. :-)

Honza Marek napsal(a):

despiq napsal(a):

Ty uvozovky okolo dedicich zapisu jsou dost divny
bez dedeni pises bez uvozovek a pri dedeni s to je divny ne?

Pokud se v klíči vyskytují mezery a jiné divné znaky, tak tam ty uvozovky být musí. Jinak ne.

Pozor, v případě JSONu by tam ale ty uvozovky měly být vždycky, viz například zdejší pojednání. Bez nich ten JSON skutečně neprojde žádným validátorem (například JSONLintem, JSON Formatterem…).

Mně se JSON taky líbí, ale právě bez těch uvozovek. S těmi uvozovkami mi přijde takovej zbytečně ukecanej a technickej… Každopádně to, že by konfigurační soubor měl syntaxi nevalidního JSONu, by bylo asi to nejblbější, co by šlo udělat :(.

Editoval Tharos (29. 4. 2010 14:15)

A nešlo by to prostě mít pár tříd, CommonConfiguration, ProductionConfiguration atd., které by měly proměnnou $config (pole), která by se dala přepisovat podle potřeby dědičností?
Sice to nebude tak hezké napohled, ale hlavně odpadne parsování a bude to rychlejší.

wotaen napsal(a):

A nešlo by to prostě mít pár tříd, CommonConfiguration, ProductionConfiguration atd., které by měly proměnnou $config (pole), která by se dala přepisovat podle potřeby dědičností?
Sice to nebude tak hezké napohled, ale hlavně odpadne parsování a bude to rychlejší.

To mě přijde neskutečně ohyzdné, když už třídy, tak s atributy… ;) Viz výše.

Vsechno je to hrozne hezky, ale ackoliv je INI lehce omezene nekterymi drobnostmi, co je na nem ve skutecnosti tak spatneho, ze by bylo treba ho vymenit? Krom toho ho osobne povazuju za pomerne standardni format pro konfiguracni soubory. Opravdu potrebujeme v konfiguraci delat takove vylomeniny, ze nutne potrebujeme jiny format?

Neberte to jako dogma, ale do ted to pomerne slusne fungovalo a opravdu by me zajimal nejaky opravdu vazny duvod, proc INI vymenit. Obzvlast, pokud zustane zachovany system adapteru (jeste jsem ten commit moc neprolejzal…), tak si ev. kazdy muze napsat co jemu libo:-)

Nová syntax bude podporovat zápis:

• pole: {"Alice", "Bob", "Cindy"} a ["Alice", "Bob", "Cindy"]
• hash: {hr: 65, avg: 0.278} a {hr = 65, avg = 0.278} a {hr => 65, avg => 0.278} (také {'hr': 65, 'avg': 0.278})
• boolean: true | false | yes | no
• čísla: -10.5
• řetězce: "word" 'word' "word\x0A\u000A" nebo jakýkoliv tok znaků neobsahující !"#$&'()*+,-/:;<=>?@[]^{|} a whitespace (v případě blokového zápisu budou pravidla volnější)
• komentáře: # comment
• objekt: @name(type="string", length=32,)

A zároveň blokový zápis:

common:
	php:
		date.timezone: Europe/Prague
		iconv.internal_encoding: UTF-8
		mbstring.internal_encoding: UTF-8

american:
  - Boston Red Sox
  - Detroit Tigers
  - New York Yankees

@David Grudl: dalsi texy? :D

Ano, bude to hrát stejnou roli jako třeba v Pythonu.

Heh :) tak to jsem nečekal.

Jsem nadšen :)

Honza Marek napsal(a):

David Grudl napsal(a):
…

Proč se dá jedna věc napsat deseti způsobama? Nebylo by lepší říct, že chceme třeba dvojtečky a = a ⇒ ne?

Souhlasím.
<ot>Totéž se mi nezamlouvá u makra var LatteFilteru.</ot>

Davide, ve tvé ‚specifikaci‘ nikde nevidím tečkovou syntax (krom příkladu), konstanty a dědičnost. jak bude pořešeno tohle?

Editoval paranoiq (30. 4. 2010 9:07)

paranoiq napsal(a):

Davide, ve tvé ‚specifikaci‘ nikde nevidím tečkovou syntax (krom příkladu), konstanty a dědičnost. jak bude pořešeno tohle?

Tečková syntax je hack na INI soubory který komplikuje situace, kdy skutečně je potřeba v identifikátoru tečka. Vhodnější než nějaké uvozovkování common.php."date.timezone": Europe/Prague mi přijde prostě využít YAML formát, takže z původního

[common]
php.date.timezone: Europe/Prague
php.iconv.internal_encoding: UTF-8
php.mbstring.internal_encoding: UTF-8

na

common:
   php:
      date.timezone: Europe/Prague
      iconv.internal_encoding: UTF-8
      mbstring.internal_encoding: UTF-8

Konstanty myslíš jako třeba?

variable.name = USER_NAME

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