Konfigurācijas glabāšana

[F3llony]

Miljards gadus vecs topiks, bet nule atkal kļuvis aktuāls. Domāju un nevaru izdomāt, un šeit nu ir saraksts ar visām opcijām, kas vien ienākušas prātā.

 

PHP masīvi failos

<?php 
return [
  'a' => 1,
  'b' => 2
];

Pros:

• Smieklīgi fleksibls (tas ir PHP fails, duh)
• Opcached
• Dikti ātrs

Cons: 

• Nolāpītie masīvi

JSON

{
  "a": 1,
  "b": 2
}

Pros:

• Vari dalīties ar konfigiem offline ar citām platformām (kura gan neatbalsta džeisonu?)
• Diezgan viegli lasāms

Cons:

• Lēnāks
• Diezgan tizli rakstāms

YAML

---
  a: 1
  b: 2

Pros:

• viss, kas JSON + vēl vieglāk lasāms

Cons:

• Lēns kā suns

INI

[config]
a=1
b=2

Pros:

• ātrāks par JSON un YAML

Cons:

• tikai 2 līmeņi

PHP objektu konstantes

<?php 
class Config_Foobar
{
  const a = 1;
  const b = 2;
}

Pros:

• nav tika fleksibls, kā PHP masīvi - tikai konstantas vērtības
• opcached
• dikti ātrs
• tu vari izmantot autoload
• IDE autocomplete

Cons:

• konstantas vērtības (moš tas ir labi?)
• viens līmenis (izņemot, ja tu esi lielisks un lieto 5.6, tad tu vari tur iebāzt arī masīvus)

Ja 5.6+, tad mans personiskais favorīts. 

 

PHP Objektu statiski propi

 

Tas pats, kas konstantes, tikai tupāka sintakse un nevajag 5.6.

 

 

Thoughts? Konstruktīvas idejas?

Edited December 24, 2014 by F3llony

[l27]

Ērti konfigurācijai izmantot konstantes vai objektu konstantes, jo tad var izmantot IDE priekšā teikšanu.

[F3llony]

Pieliku listē. Bet no otras puses, šis liekas itkā hardkodētu immutējamus konfigurācijas objektus, kas neliekas pareizi. Bet vai tam vispār ir nozīme?

[l27]

Pieliku listē. Bet no otras puses, šis liekas itkā hardkodētu immutējamus konfigurācijas objektus, kas neliekas pareizi. Bet vai tam vispār ir nozīme?

Parasti to liek config failā, kas developmentam ir savs, production savs. Neredzu nekādu hard codēšanas problēmu.

 

Ja objektu izmanto, kā konfig, tad masīvus var definēt metodēs (ja nav PHP5.6).

 

 

Vēl var izmantot

• config.php - vispārējā konfigurācija - dev/test/prod kopīga
• config-local. php - specifiska instalācijai

Vēl var skaldīt:

• config_www.php
• config_console.php
• config_fronted.php
• config_backend.php

Edited December 24, 2014 by l27

[F3llony]

Tas ir pašsaprotami, bet tā darot zaudē PSR autoload un jāpieraksta savs, kas ielādēs konfigus atkarībā no vides. Bet tad mēs zaudējam inheritance un autocomplete būtu tikai ar type hintiem. 

[l27]

Pieliku listē. Bet no otras puses, šis liekas itkā hardkodētu immutējamus konfigurācijas objektus, kas neliekas pareizi. Bet vai tam vispār ir nozīme?

Hardkodēd nedrīkst programmas tekstā. Config fails ir izņēmums. Nesaprotu par ko satraukums, ka kaut kas hardcodēts?

Galvenais, lai kodā ir ērti izmantots un saprotams un konfigurācija ir vienā vai dažos failos.

Edited December 24, 2014 by l27

[F3llony]

Es runāju par kaut ko citu. Ilustrēju problēmu:

 

<?php
namespace Config
{
    // Prod
    class ConfigFooBar()
    {
        const x = 1;
    }
    // Dev, citā failā, obviously
    class ConfigFooBar()
    {
        const x = 2;
    }
}
namespace Blah
{
use Config;
    class MyClass
    {
        $x = ConfigFooBar::x; // Nemutējama statiska reference
        // Autoloader eksplodē liesmās
    }
}

Kuru no ConfigFoobar ielādēs PSR? To, kurš ir attiecīgajā namespace failā. Lai to novērstu ir jāveido divi faili, katrs savā namespace/direktorijā.

 

Tad vēl ir sintakse $foobar::x, un tad varētu typehintot, bet tas nemaina faktu, ka nepieciešams papildus autoload un pieeja pēc name piedrazo scope ar daudz mainīgajiem. Šī pieeja nav īsti ne ar ko labāka par imutējamu konfig konteineri kā servisu vai di.

 

P.S. Es tagad iedomājos arī par spec/unit testiem. Well...

Edited December 24, 2014 by F3llony

[l27]

Es runāju par kaut ko citu. Ilustrēju problēmu:

 

Kuru no ConfigFoobar ielādēs PSR? To, kurš ir attiecīgajā namespace failā. Lai to novērstu ir jāveido divi faili, katrs savā namespace/direktorijā.

 

Tad vēl ir sintakse $foobar::x, un tad varētu typehintot, bet tas nemaina faktu, ka nepieciešams papildus autoload un pieeja pēc name piedrazo scope ar daudz mainīgajiem. Šī pieeja nav īsti ne ar ko labāka par imutējamu konfig konteineri kā servisu vai di.

 

P.S. Es tagad iedomājos arī par spec/unit testiem. Well...

 

 

Parasti uz DEV sistēmas config failā ir vieni setingi, uz testa citi un productiona citi. Nekad dev konfig failā nekrāmē production konfig. Sevišķi MySql connection details nevienam nav jāredz.

 

Ja būs viena config klase, nu nebūs konflikti.

[F3llony]

Izlasi taču manu komentāru. Es runāju par kaut ko pilnīgi citu.

[F3llony]

Papildus dažas problēmas ar konfigurāciju, par kuru risinājumiem vēl neesmu pārliecināts: shēmas konfigiem (domā, man vajag lai x saturētu masīvu ar skaitļiem, nevis masīvu ar būliem) un normāls konstrukts, kā šo konfigu lasīt. 

[l27]

Ja tik dziļi brauc iekša, paņem gatavu framework un nedomā par sīkumiem. Piemēram iekš Yii viss ir atrisināts.

VIenīgi nevar izmanto IDE priekšā teicēju.

[F3llony]

Paldies par ieteikumu! Būs jāpalūko, kas tie tādi freimworki par zvēriem. Nekad iepriekš nebiju dzirdējis. 

 

 

>:( ...

[codez]

Uztaisa abstraktu konfigurācijas interfeisu, kuru izmanto neatkarīgi no tā, kā glabājas konfigurācija.

Uztaisa konfigurācijas ielādētāju katram atsevišķam, nepieciešamajam gadījumam (yaml, php, json, utt.).

Ja ielādēšana katrreiz par lēnu, konfigurāciju kešo.

Ja svarīgs kopējais ātrums nomainām PHP pret Scalu.

[briedis]

Nez, parasti katram freimworkam ir savs standarta veids, kā glabāt. Visbiežāk jau tas ir masīvs. 

 

Es vispār nesaprotu, kur ir problēma. Kāpēc configi vispār jāšēro? Katrai sistēmai savs veids kā viņš glabājās. Ja ir custom sistēma, tad taču nenošērosi savu custom configu. Ja ir standarta freimworks, tad arī ir standarta configs.

 

Esmu cilvēks, kam patīk izmantot IDE, tāpēc ja rakstītu no 0, gan jau rakstītu klasē, lai suggestioni forši strādā.

[F3llony]

Uztaisa abstraktu konfigurācijas interfeisu, kuru izmanto neatkarīgi no tā, kā glabājas konfigurācija.

Tā (ne)darbosies validācija tikai 1 līmenī, konfigurācijas struktūra parasti ir vismaz 2 līmeņi. Interfeiss nekādā veidā nepalīdzēs enforsēt shēmu.

 

Uztaisa konfigurācijas ielādētāju katram atsevišķam, nepieciešamajam gadījumam (yaml, php, json, utt.).

 

Nav pat tādas vajadzības. Ja viens avots, tad viens avots.

 

Ja ielādēšana katrreiz par lēnu, konfigurāciju kešo.

 

Ja ielādēšana katru reizi ir par lēnu, konfigurāciju glabā PHP un izmanto opcache.

 

Ja svarīgs kopējais ātrums nomainām PHP pret Scalu.

 

Go home, troll. Scala is irrelevant and gay. 

 

 

@Briedis es tev pilnīgi piekrītu, taču problēma šeit tāda, ka atkal, single level. Ide tev nepateiks priekšā masīva saturu. Ja, piemēram, JS mēs varam pateikt ka 

{
    foo : {
        bar: []
    }
}

un IDE to pat atrisinās, tad PHP tādas konstrukcijas vēl diemžēl nav. 

Edited December 24, 2014 by F3llony