vai leitot RETURN vai tomēr ne (diskusijas turpinājums)

[daGrevis]

> bet tad jau tev sanāk katrai kontrolera metodei būvēt savu custom formas klasi ar visiem validācijas nosacījumiem, ne?

 

Jā, katrai vietai ir sava validācija. :)

 

Nu, visbiežāk, kā Vaļuks minēja, forma tiek veidota no modeļa, so, ja ir modelis, es pasaku, ka mana forma ir modeļforma, un tā automātiski iegūst fieldu un sane nosacījumus bāzētus un kolonas tipiem. Tās ir klases definīcija, kas manto `ModelForm` un pasaka, ka, lūk, īstais modelis ir šis. Tad arī, ja kkas neapmierina, varu, piemēram, pateikt, ka šo un to fieldu nevajag, vai, to un šito fieldu tikai vajag; tas pats attiecas un validācijas rūļiem. Bet tas jau ne pa tēmu biku. :)

[nemec]

Tad jātaisa vēl viens modelis, kur glabāsi operācijas (šos amount un pie reizes var arī type), lai vēlāk varētu izsekot kas kur un kā notika.

[codez]

Tad jātaisa vēl viens modelis, kur glabāsi operācijas (šos amount un pie reizes var arī type), lai vēlāk varētu izsekot kas kur un kā notika.

Bet, ja es nevēlos šos datus glabāt un man viņi nav vajadzīgi?

Jā, katrai vietai ir sava validācija. :)

 

Nu, visbiežāk, kā Vaļuks minēja, forma tiek veidota no modeļa, so, ja ir modelis, es pasaku, ka mana forma ir modeļforma, un tā automātiski iegūst fieldu un sane nosacījumus bāzētus un kolonas tipiem. Tās ir klases definīcija, kas manto `ModelForm` un pasaka, ka, lūk, īstais modelis ir šis. Tad arī, ja kkas neapmierina, varu, piemēram, pateikt, ka šo un to fieldu nevajag, vai, to un šito fieldu tikai vajag; tas pats attiecas un validācijas rūļiem. Bet tas jau ne pa tēmu biku. :)

Ja dati ir modeļa kontekstā, tad viss ok, es var taisīt formu, kura veidojas no modeļa, vai kā es daru, definēju validācijas nosacījumus pašā modelī.

Bet, ko darīt, ja Requesta dati ir jāvalidē, bet tie nav kontekstā ar nevienu no modeļiem?

Edited March 8, 2013 by codez

[daGrevis]

Nu neko, manuāli sadefinēt iekš `Form`, nevis `ModelForm` -- kādi dati tur būs, kādi fieldi. Atkal darbojas minētais princips, ka tiks izveidoti validācijas rūļi pēc fieldu tipiem. Tos atkal var uzlabot un visādi mainīt. Nekas nemainās, izņemot to, ka formu fieldi pašam būs jaraksta.

 

No tā var izvairīties? :P

[codez]

No tā var izvairīties? :P

No validācijas izvairīties nevar, bet man šķiet, ka pareizāk ir validāciju rakstīt kontekstā ar kontroleri (kontrolerī pašā vai atsevišķā klasē, tas jau ir gaumes jautājums), kuram nāk request dati, nevis ar modeli. Jo pieprasījumā var būt dati gan vairākiem modeļiem, gan dati, kas nav tieši saistīti ar kādu konkrētu modeli.

[codez]

Tas ir pirmīt gribēju rakstīt, ka dati, kas tieši attiecas uz modeli, ir jāvalidē modelī, bet dati, kas neattiecas uz modeli ir javalidē kontrolera kontekstā.

Piemēram, ja nu pēkšņi max pērkamo itemu skaits ir mainīgs un atkarīgs no citiem parametriem:

$account=Model_account::auth();
$amount=Request::post("amount","int",array("min"=>1,"max"=>$account['maxItemsToBuy']));

 

Kā šādu validāciju būs iespējams veikt ārpus kontrolera konteksta?

Edited March 8, 2013 by codez

[marrtins]

codez, nu man sanāk šāds:

 

try{
    $account->decMoney($item->priceInMoney()*$ammount);
} catch (NepietiekamiBiezs $e) {
    try {
        $account->decItem(Model_item::goldid, $item->priceInGold()*$ammount);
    } catch (NepietiekamiBiezs $e) {
        ej_strādāt_nes_piķi();
    } catch (NavAutotizēts $e) {
        login_pass_auth();
    } finally  {
        crash_ar_lielu_blīkšķi();
    }
} catch (NavAutotizēts $e) {
    login_pass_auth();
} finally  {
    crash_ar_lielu_blīkšķi();
}

 

[nemec]

Bet, ja es nevēlos šos datus glabāt un man viņi nav vajadzīgi?

Cik ir tādu gadījumu? Tavā piemērā, ja pieprasījums ietekmē citus modeļus, tad tas ir nepareizi, jo nevarēsi izsekot datus — modelos kaut ko pieskaita un atskaita. Tā ir plānošanas kļūda.

 

Savukārt, ja ir pieprasījums un nevēlies glabāt datus (piemēram jautājuma nosūtīšana caur lapu), tad var izmantot custom formu validācijai.

 

Piemēram, ja nu pēkšņi max pērkamo itemu skaits ir mainīgs un atkarīgs no citiem parametriem:

 

Kad validē amount, tad tajā metodē pieprasi account datus un pārbaudi pēc parametra 'maxItemsToBy'. Jebkurā gadījumā, tie ir saistīti modeļos un validācija "kaut kur tur" arī jāveic.

 

 

Tavai pieejai ir trūkumi: 1) bez kontroliera nekas nedarbosies, jo modelis nespēs pats "novalidēties", tātad vai nu konsolē, vai nu admin panelī vai vēl kaut kur jāvelk papildus kods/problēmas; 2) īsti arī nesaprotu kā sinhronizē sql ar šo validāciju.

 

Te vienkārši jāmaina domāšana un jāsasaista formas ar modeļiem ļoti cieši.

[codez]

marrtin, bet visus tos catch jau veic front kontroleris un apstrādā tur, tas nav jāraksta katrā kontrolerī, tieši sī iemesla dēļ arī kontroleri sanāk tik īsi. Kamēr, ja kļūdas stāvoklis tiek nodots ar return, viss sanāk daudz komplicētāk.

Frontkontrolerī:

 

 

 

$controlerName=Router::getControllerName();
$controller=new $controlerName();
try{
  $controller->run();
} catch(NavAutorizēts $e){
  Response::redirect('/signin');
} catch(LietotājKļūda $e){
  Response::showError($e->message);
} catch(sistēmasKļūda $e){
  Logger::logSystemError($e);
} finnaly {
  Response::showError('Kaut kas nogāja greizi! Mūsu inženieri jau labo! Ienāc pēc minūtiņas');
}
 

Kamēr kontrolerī, kuru izsauca ir viss bez try un catch - trīs rindiņās.

[codez]

Cik ir tādu gadījumu? Tavā piemērā, ja pieprasījums ietekmē citus modeļus, tad tas ir nepareizi, jo nevarēsi izsekot datus — modelos kaut ko pieskaita un atskaita. Tā ir plānošanas kļūda.

Patiesībā tas būs lielākajā daļā gadījumu. Protams, tur, kur runa ir par naudu un tādām lietām, transakcijas tiks logotas, bet ir kaudze vietu, kur tas nav nepieciešams un pat nav vēlams.

Savukārt, ja ir pieprasījums un nevēlies glabāt datus (piemēram jautājuma nosūtīšana caur lapu), tad var izmantot custom formu validācijai.

Par to es arī runāju. Custom forma. Bet tā forma attieksies uz kontroleri, nevis uz modeli. Tas, ka tā validācija notiek atsevišķā formas klasē, kā jau teicu, ir gaumes jautājums (ja grib testēt validačijas klasi atsevišķi, vai kontroleris ir pietiekami liels, lai validāciju atdalītu pārskatāmības dēļ), bet tā ir un palike validācija kontrolera kontekstā.

Kad validē amount, tad tajā metodē pieprasi account datus un pārbaudi pēc parametra 'maxItemsToBy'. Jebkurā gadījumā, tie ir saistīti modeļos un validācija "kaut kur tur" arī jāveic.

maxamount priekš $amount, cik daudz var pirkt, tiešā veidā nav saistīts ar nevienu no modeļiem un loģiskā veidā nevar tikt validēts nevienā no modeļiem, jo tas ir maksimālais daudzums, ko var pirkt šī kontrolera kontekstā.

maxamount vērtībai konteksts ir kontroleris, jo kā jau minēju, veicot citas darbības, šie $amount izmaiņas daudzumi var būt citi.

Tavai pieejai ir trūkumi: 1) bez kontroliera nekas nedarbosies, jo modelis nespēs pats "novalidēties", tātad vai nu konsolē, vai nu admin panelī vai vēl kaut kur jāvelk papildus kods/problēmas; 2) īsti arī nesaprotu kā sinhronizē sql ar šo validāciju.

Kā jau teicu, šis maxamount priekš $amount neattiecas uz nevienu no modeļiem un pilna modeļa darbībai nav nepieciešam šis maxamount un modeļa pilnu funkcionalitāti var notestēt bez tā.

Maxamount ir nepieciešams tikai pašam kontrolerim, lai ierobežotu, cik daudz itemus ar šo kontrolera actionu varēs vienlaicīgi nopirkt. Pašam modelim (item vai account) neinteresē, cik daudz itemus ļaus pirkt konkrētajā darbībā.

Te vienkārši jāmaina domāšana un jāsasaista formas ar modeļiem ļoti cieši.

Šeit nav runa par formām un modeļiem. Bet gan par to, ka daGrevis izteicās, ka kontrolerī netaisa validāciju. Es šeit gribu parādīt, ka eksistē tādi dati, kas ir jāvalidē, bet nav kontekstā ar nevienu modeli, tāpēc vislabāk tos validēt ir kontrolera kontekstā - ar formu(custom formu, kura nav peisaistīta modelim), vai bez, tas ir cits jautājums.

[marrtins]

codez, bet es joprojām neredzu, kurā vietā Tavā kodā tiek mēģināta cits maksājumu veid pie pirmā fail?

[codez]

codez, bet es joprojām neredzu, kurā vietā Tavā kodā tiek mēģināta cits maksājumu veid pie pirmā fail?

Es īsti nesaprotu, ko tu domā ar citu maksājumu veidu? Manā aprakstītajā piemērā ir money - lietotāja virtuāla nauda, par kuru viņš pērk items. Tālāk es rādīju piemēru, kur var pirkt gan ar virtuālu naudu, gan ar virtuālu zeltu (cits maksājumu veids).

[Kavacky]

Tavs piemērs neparādīja fallbacu uz virtuālo zeltu, ja virtuālā nauda nofeilo.

[codez]

Tavs piemērs neparādīja fallbacu uz virtuālo zeltu, ja virtuālā nauda nofeilo.

 

Sk! Šijā gadījumā, pārķeram turpat kontrolerī:

try{
  $account->decMoney(...);
} catch (NepietiekNauda $e) {
  $account->decItems(...);
}
 

Bet pārējās pārbaudes/pārķeršanas kā rādījā marttins savā piemērā, nav jātaisa, jo tās māk pārķert front kontroleris.

Edited March 8, 2013 by codez

[daGrevis]

> Tas ir pirmīt gribēju rakstīt, ka dati, kas tieši attiecas uz modeli, ir jāvalidē modelī, bet dati, kas neattiecas uz modeli ir javalidē kontrolera kontekstā.

 

Nav svarīgi, kur atrodas kods. Svarīgi, kas to izsauc (lasi, kontroleris vai modelis).

 

Manā gadījumā, ja vajadzētu divas validācijas modelim — būtu divas formas klases, kur, iespējams, viena arī mantotu otru.