Kam nejlépe umístit pomocné číselníky?

MW

Zdravím a prosím o radu,
kam ukládáte pomocné funkce a číselníky? Mám například toto, co používám stále dokola na více místech a je toho mnohem více:

function getMonths() {

	return $month = array(
	    '1' => 'Leden',
	    '2' => 'Únor',
	    '3' => 'Březen',
	    '4' => 'Duben',
	    '5' => 'Květen',
	    '6' => 'Červen',
	    '7' => 'Červenec',
	    '8' => 'Srpen',
	    '9' => 'Září',
	    '10' => 'Říjen',
	    '11' => 'Listopad',
	    '12' => 'Prosinec');
    }

    function getVat() {
	return $vat = array(
            '21' => "21",
            '15' => '15',
            '20' => '20',
            '0' => '0',
	    );
    }

    function getTypes() {

	return $types = array(
	    'S' => 'S',
	    'O' => 'O');
    }

.....

Ted to mám v BasePresenteru a nejsem si jistý, jestli je to to správné místo :)

Díky!

GEpic

Udělej si na to spešl třídu se jménem třeba ProjectHelpers a používej je staticky…

Např

namespace App\Helpers;

class ProjectHelpers
{
	public static function getMonths()
	{
		return [
			1 => "Leden",
			...
			12 => "Prosinec
		];
	}
}

A kdekoliv k nim přistupuj takto:

	use App\Helpers;

	public function renderDefault()
	{
		$this->template->months = ProjectHelpers::getMonths();
	}

Editoval GEpic (26. 8. 2016 9:07)

MW

By asi šlo.. jen jestli nenarazím, kdyby některá metoda v helperu potřebovala sáhnout do databáze například…

Díky!

GEpic

MW napsal(a):

By asi šlo.. jen jestli nenarazím, kdyby některá metoda v helperu potřebovala sáhnout do databáze například…

Díky!

Není problém si tam předat přeci instanci databáze nebo model :)

Editoval GEpic (26. 8. 2016 9:18)

Pavel Kravčík

Těch helperů si dělej více, je to pak přehlednější. Globální helper může obsahovat měsíce atd. a zbytek pak pro konkrétní modely.

U číselníků menších a neměnných se nám lépe pracuje s tímhle:

PriceEntity
{
	const VAT_21 = 21;
	const VAT_15 = 15;
	const VAT_0 = 0;
}

MW

Díky moc za trknutí :)

CZechBoY

Já si teda měsíce ukládám do překladače, ale ty asi nemáš lokalizovanou aplikaci tak překladač nepoužíváš :-)
Na tu daň by to chtělo u lokalizovaný aplikace spešl třídu, která podle státu spočítá daně atd.

Svaťa Šimara

Pavel Kravčík napsal(a):
…

PriceEntity
{
	const VAT_21 = 21;
	const VAT_15 = 15;
	const VAT_0 = 0;
}

Když se nám změní vyšší hodnota DPH, jak bude třída vypadat?

Buď const VAT_21 = 25; – pak název konstanty neodpovídá,
Anebo const VAT_25 = 25; – pak ale musím změnit název konstanty na všech místech.

Co to trochu lépe pojmenovat?

PriceEntity
{
	const VAT_NORMAL = 21;
	const VAT_LOWER = 15;
	const VAT_FREE = 0;
}

CZechBoY

@Fafin furt se může další daň přidat :D

Pavel Kravčík

@Fafin: Je to jen příklad, že se dají použít konstanty. To, že jsou špatně pojmenované a nezohledňují například platnost od není příliš podstatné. :)

Když budeme řešit nesmyslné detaily – jak přidáš dvě nové ty? :D

	const VAT_MEDIUM = 18;
	const VAT_NOT_BIG_AS_20_BUT_STILL_BIGGER_THAN_18 = 19;

Šaman

Měsíce jsou dost specifické, protože jejich pořadové číslo je plně identifikuje i v lidské řeči. Převod 1 → leden je tedy spíš překlad, než definice kostanty.

Ale jinak podobné číselníky dávám normálně do databáze, včetně třeba pohlaví.
Druhá možnost, taky odzkoušená, je mít to jako konstanty, nebo pole přímo ve třídě entiy, včetně metod pro překlad nějakého uloženého kódu (m, z) na hodnotu (muž, žena).

Editoval Šaman (26. 8. 2016 13:49)

Pavel Kravčík

@Šaman: Přesně ta druhá varianta je hodně friendly, stačí si upravit trochu tu návratovou funkci. To by se hodilo i @MW nahoru.

public function getFooTranslate($key = NULL)
{
	$array = //seznam, statická funkce, reflexe konstant

	if($key === NULL)
	{
		return $array;
	}
	else
	{
		return isset($array[$key]) ? $array[$key] : 'N/A';
	}
}

EDIT: vat pryč, působí jako červený toreador :)

Editoval Pavel Kravčík (26. 8. 2016 15:50)

Šaman

Problém nastane třeba pokud přibude nová sazba vat. Budeš muset sáhnout do kódu. A ještě větší problém bude, pokud bys měl třeba provádět výpočty jak před zavedením nové sazby, tak po ní.
Když je to v databázi, pak není problém přidat novou sazbu, u položky na tuto sazbu odkazovat a při výpočtu prostě vzít správnou sazbu, aniž by o nich php kód věděl.
Několikrát jsem už podobné kalkulačky potkal a právě od té doby se snažím mít v databázi prakticky všechno.

Ty konstanty v entitě jsou fajn, když víš, že se to určitě nebude měnit. A to se nedá zaručit skoro nikdy.

Editoval Šaman (26. 8. 2016 14:13)

Pavel Kravčík

Jasně, pointa je ten parametr do funkce.

VAT samozřejmě musí hlídat více věcí a hlavně dobu platnosti a třeba vztah ke klientovi (stát) atd. To je vedlejší.