Vlastný nette config file

Lukass445

Zdravím,

viac ako otázka sa pýtam na radu. Rozmýšľam totiž o implementovaní vlastného config súboru, no neviem, či sa to vyplatí robiť pomocou neon-u alebo iných utilitiek. Skôr som rozmýšľal nad vkladaním týchto informácií do databázy, napr. v DB ako „page_unavailible_message“:„Ľutujeme, stránka aktuálne nie je k dispozícii z dôvodu …“ alebo „items_per_page“:„10“. Takže alternatívy pre takýto súbor config nastavení sú:

Databáza
Config.neon a pod.
PHP súbor

mne osobne sa najviac páči asi php súbor, nejakým spôsobom sa neskôr v špecifických presenteroch odkazovať na konštanty cez rodiča base presentera. Teda ak som napr. v PostPresenter-i, tak by som si konštantu zavolal len pomocou parent::ITEMS_PER_PAGE. Nie je to ale praktické z dôvodu prehnaného množstva dát(konštánt) v jednom súbore a asi to nie je ani najlepší spôsob z hľadiska umiestnenia takýchto informácií.

Ukladanie týchto dát do databázy mi príde rýchle, s dodatočnou administráciou aj pekne cez nejaký grid modifikovateľné. No pri strate týchto riadkov z databázy alebo inej katastrofe – napr. pri kopírovaní celého webu sa tieto data môžu stratiť a nette by vyhadzoval chyby, ak by tieto riadky v databáze neexistovali.

Priznám sa, úplne nerozumiem využitiu config.local.neon súboru. Do kolonky parameters: môžem vkladať parametre podobného charakteru ako spomínam vyššie? Nikde to totiž neviem nájsť vysvetlené. (Prirodzene okrem údajov pre pripojenie do DB)

Čo je teda najlepší spôsob?

Vopred ďakujem za Vaše rady, prípadne Vaše spôsoby riešenia podobného problému

Editoval Lukass445 (8. 11. 2014 17:07)

bazo

na parent::ITEMS_PER_PAGE hned zabudni a uz duplom zabudni, ze to bude v presenteri

na taketo nastavenia mas dve moznosti:

1. ulozene v subore – ak si nepotrebujes tieto nastavenia modifikovat na beziacej aplikacii, odporucam neon alebo nette vie nacitat aj z php, ale neon je preferovany format v nette

do kolonky parameters: si moze vkladat hociake parametre ake potrebujes

2. ak si potrebujes tieto nastavenia modifikovat na beziacej aplikacii

potom ked mas komponentu napr UserGrid tak predas $itemsPerPage cez konstruktor za pouzitia generovanej tovarnicky

cize

<?php

class UsersGrid {
	function __construct($itemsPerPage)
}
interface UsersGridFactory{
	public function create();
}
?>

config.neon bude vyzerat takto:

	parameters:
		usersGrid:
			itemsPerPage: 5
	services:
		- {implement: UsersGridFactory, arguments: [%usersGrid.itemsPerPage%]}

v pripade ze to chces nacitat z db vytvoris si dalsi sluzbu napr ConfigLoader a potom spravis UsersGrid zavisly na tejto sluzbe, ale to uz sa mi tu nechce pisat

tato sluzba moze loadovat nastavenia aj z config.neon alebo odhocikial

jasne?

Editoval bazo (10. 11. 2014 13:50)

amik

config.local.neon se používá k něčemu úplně jinému – konfigurace, kterou nechci verzovat. Obvyklý problém webů je, že část konfigurace je závislá na prostředí, kde běží. Do config.local.neon se dávají např. přístupové údaje do databáze, protože budou jiné u tebe na localhostu a jiné na serveru. Proto se takovýto soubor neverzuje (přes git atd), neverzovat celý config by bylo nesystémové, např. při přidání nové definice služby bych musel upravit ručně config na localhostu i na všech serverech, kde web běží.

Proto si ve verzovacím systému nastavíš ignore na config.local.neon a ten všude založíš ručně jen s těmito parametry odlišnými dle prostředí.
Já osobně mám zvyk zaverzovat např. soubor config.local.neon.example, který se nikde nenačítá, ale pokud někam deployuju novou kopii webu z gitu, mám vždy po ruce výchozí podobu config.local.neon, kterou jen lokálně zkopíruji a upravím.

Proč si vlastně chceš psát vlastní config?
- vše, co má neměnnou konfiguraci za běhu aplikace (zadrátování služeb, routování atd…) se dá zapsat do config.neon a pomocí vlastní služby a DI dopravit do aplikace. Rozhodně raději doporučuji nastudovat principy DI a tohohle využít, než vymýšlet oslí můstek s psaním vlastních konfiguráků.
- pokud se něco mění (např. uživatel si může nastavit, kolik chce příspěvků na stránku), pak je to rozhodně lepší dát do databáze a normálně s tím jako s databází pracovat přes Nette\Database, zase nevidím důvod, proč na to vymýšlet nějakou konfigurační abstrakci :)