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

[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ā.

 

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.

Jā, tieši tas arī ir svarīgi (izsauc == kontekstā) un nevaru saprast kā modelis var izsaukt kaut ko, kas uz viņu neattiecas.

Edited March 8, 2013 by codez

[daGrevis]

Pag, ja tas attiecas uz modeli — lai arī modelis to izsauc. Ja tas attiecas uz kontroleri, lai arī kontroleris to izsauc.

 

Tas, ko izsauc — abas lietas ir formas.

[codez]

Tas, ko izsauc — abas lietas ir formas.

 

Tātad validācija tomēr var notikt kontrolerī, tas ir izmantojot formu?

Tas, ka validācijas definīcija ir rakstīta citā klasē, kas atrodas citā vietā, tad kā jau minēju ir gaumes jautājums.

Ja man būs vienkārš kontroleris, kuram javalidē viens parametrs min/max robežās, es viņam netaisīšu atsevišķu formu, bet novalidēšu turpat kontrolerī.

[F3llony]

Kas par *****?!!!11 Kas tās par sēnēm šajā topikā? Jūs maz paši izlasījāt, ko esat sadrukājuši? Jo īpaši ar eksepšaniem steitu forvardējošais codez?  

 

3 lapas noturējos, bet nu man jāsāk domāt, vai pilsoņiem kāds maksā par to, lai izgudrotu jaunu stulbumu? Tur piemēram kļūdas/steitu un anomālis handlējošus front-kontrolierus un vēl sazin ko tik vēl ne. Nu bļin taču tik pat labi var jau arī uztaisīt front-front kontrolieri, kas uzsāk cli front-kontrolieri, kas noforko sevi un izpilda kontrolieri. Tā varēs bļ steitu padot arī starp N procesiem. Tas jau nekas, ka realitātē tā ir sajātas arhitektūras problēma. Fine. Im done. My life is a lie.

 

 

P.s normālā gadījumā formas validē modelis pēc datu tipiem, garumiem, etc etc un custom norādītām rulēm. Kontrolieris kontrolē datu plūsmu starp modeli un skatu. Ar datu apstrādi kontrolieris nenodarbojas. Diemžēl ne vienmēr sanāk tā, kā gribētos... :(

Edited March 8, 2013 by F3llony

[codez]

F3llonny, pieauguši cilvēki savu viedokli aizstāv ar to kā ir jādara pareizi. Ja tev ir savs variants kā pareizi jādara, tad lūdzu studijā.

 

P.S. Es pēc sava stila esmu veidojies lielas aplikācijas un nekādu sarežģījumu nav bijis - kods ir vienkāršs un saprotams, kļūdas, izmantotjot šo metodi, nerodas. Tieši pretēji, dažreiz automātiski notiek lietas pareizi kā tam jānotiek, pat speciāli to neparedzot.

Edited March 8, 2013 by codez

[daGrevis]

> Tātad validācija tomēr var notikt kontrolerī, tas ir izmantojot formu?

 

Formas kodu, jebšu validāciju, parasti izsauc tieši kontroleris. Ja tā ir modeļa loģika, to tad var izsaukt arī modelis.

 

> Tas, ka validācijas definīcija ir rakstīta citā klasē, kas atrodas citā vietā, tad kā jau minēju ir gaumes jautājums.

 

Jap. Jau teicu, ka man nepatīk daudz koda iekš kontrolera.

 

> Ja man būs vienkārš kontroleris, kuram javalidē viens parametrs min/max robežās, es viņam netaisīšu atsevišķu formu, bet novalidēšu turpat kontrolerī.

 

Es arī. Tikai problēma ir tur, ka kods strauji, straugi aug un vairs nav tik mazs.

 

Tad arī rodas šis kas šāds...  https://github.com/daGrevis/daGrevis.lv/blob/master/dagrevis_lv/blog/views.py#L36

 

> My life is a lie.

 

_Cake is a lie._

[F3llony]

ChainOR/TreeOR

 

 

Also, aizmirsu piebilst, ka FC ir pilnīgi nospļauties uz kontrolieriem by default. FC dzīves mērķis ir nodot kontroli attiecīgam kontrolierim, ko identificē rūteris. Kontroliera bāze vienmēr pati definē savas kļūdas un veidus, kā tos risināt, tā pat, kā FC neapstrādā routēšanas problēmas, konfiga problēmas, resursu problēmas un visu citu pārējo. 

 

Breakdown no Mārtiņa piemēra - 

 

 

<?php
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();
}
 

1. Nav autorizēts apstrādā kontroliera bāze (konstrukts, mains, whatever). Tā ir katra kontroliera specifiska darīšana - kāda autentifikācija, kapēc, kad un kam. 

2. if($account->balance() < $item->price){ $this->redirect('nav_naudas_output'); }else{$account->transact($item); $this->redirect('success');}

3. ???

 

Crash ar lielu blīkšķi handlē globāls kļūdu menedžeris, whatever kind of. Viss. Mans kontrolieris satur vienu rindiņu. Check-mate. 

 

Savus mistiskos supererrorus un nereālos piemērus paturi. Dzīvē tā nenotiek. 

[codez]

F3llony,
nepiekrītu pilnīgi nekam, ko tu rakstīji.
 

Also, aizmirsu piebilst, ka FC ir pilnīgi nospļauties uz kontrolieriem by default. FC dzīves mērķis ir nodot kontroli attiecīgam kontrolierim, ko identificē rūteris. Kontroliera bāze vienmēr pati definē savas kļūdas un veidus, kā tos risināt, tā pat, kā FC neapstrādā routēšanas problēmas, konfiga problēmas, resursu problēmas un visu citu pārējo.

Tur jau tā lieta, ka tagad ir runa nevis par kļūdām, kuras rodas kontrolerī, bet gan par kļūdām, kuras rodas modeļos (nav autentificējies, nepietiek nauda, utml.).

Breakdown no Mārtiņa piemēra -

Kāpēc Mārtiņa?

1. Nav autorizēts apstrādā kontroliera bāze (konstrukts, mains, whatever). Tā ir katra kontroliera specifiska darīšana - kāda autentifikācija, kapēc, kad un kam.

Kāpēc katram kontrolerim tas ir jāraksta, kur DRY princips?
Vieglāk ir izveidot account modelī funkciju, kura atgrieš autorizētā lietāja kontu, ja lietotājs nav autorizējies, tad attiecīgi izmetam eksepšanu un parādam kļūdas ziņojumu. Ja tas ir ajax request, tad to smuki pārķer ajax kontroleris un noformē ajax pieprasījumam saprotamā formā, ja tas nav ajax request, tad front kontroleris nodod vadību cita kontrolera (error mesidža kontrolera) ziņā.

2. if($account->balance() < $item->price){ $this->redirect('nav_naudas_output'); }else{$account->transact($item); $this->redirect('success');}
3. ??? 
Crash ar lielu blīkšķi handlē globāls kļūdu menedžeris, whatever kind of. Viss. Mans kontrolieris satur vienu rindiņu. Check-mate. 
Savus mistiskos supererrorus un nereālos piemērus paturi. Dzīvē tā nenotiek.

1. Tu nepārbaudīji vai lietotājs ir autorizējies;
2. Tu nepārbaudīji vai inventorijā ir vietas;
3. Tu nepaņemi datus no post datiem un nevalidēji;
Bet, ja mēs paliekam pie plikas tās konkrētās darbības, tad manā gadījumā tavu kodu aizvieto ar:

$account->transact($itemid, $amount);

ja nepietiks naudas, Ajax bāzes kontroleris pārķers eksepšanu un parādīs kļūdas ziņojumu,

ja nepietiks vietas inventorijā, tad tas pats,
ja viss būs kārtībā, turpināsies izpilde.
Kuram ir vienkāršāk?

[F3llony]

DRY? Kāpēc tu domā, ka es kaut ko grasos rakstīt N reizes? Kam domāta klašu paplašināšana? Tu tacu zini, ka klases var paplašināt bezgalīgi? Un tādā veidā sakombinēt funkcionalitāti kā vien ienāk prātā? tur ajax izvade ar auth, bez auth, tokeniem, http auth, raw html ar auth, bez auth, sso, oauth, whatever? 

 

1. Es pārbaudīju. E.g kontrolieris pārbaudīja. E.g. kontroliera bāzes klase, kas pārbauda vai lietotājs autentificējies konstruktā/mainā. Kad nepieciešama autentifikācija bāzes klase kontrollierim to izdara. Tad, kad vajag. Ne visu laiku.

2. Es negrasos aprakstīt katru tava iedomātā piemēra keisu. Ja tu nesaprati principu no visa manis rakstītā, piedod, es nespēju to nostulbot līdz vēl vienkāršākam piemēram.

3. ??? Kā tieši tu gribēji lai es viņus paņemu? No priekšas vai aizmugures? Pēdejais gan nav gluži mans stils....

 

Par ajax - tas pats - paplašini ajax kontroliera klasi un ļauj tai nohendlot visu. Vajag izvadi XML? No problem. Vēlies atbalstīt 100 citu izvades opciju? No problem. Tam nav vajadzīgs hogot FC ar liekām muļķībām. 

 

Par kļūdām modeļos - tam domāts kontrolieris - lai kontrolētu komponenšu un komunikācijas stāvokli. Tas nav jādara FC. Lūk, direct state no modeļa uz izpildītāja kontrolieri - tava iedomātā problēma ar steitu ķēdi atrisināta. 

 

Bet man anyway prieks, ka zini, kas ir DRY. Cerams drīzumā apgūsi arī decoupling, spaghetti code, golden hammer, dependency hell un visus pārējos jaukos principus un (anti)patternus, kurus tu esi pamanījies piemirst. Jo es ļoti skaļi smiešos, kad tavs izcili modulārais frontkontrolieris būs savas 5k rindas garš monstrs, kas ķer visus fakin keisus no katra kontroliera kas vien ir sistēmā. 

 

/tc

[nemec]

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ā.

Labi, biju sapratis, ka maxamount ir pieglabāts lietotāja modeļos un no tā atkarīgs.

[daGrevis]

Codez un F3llony, varēsiet arī par šo te padiskutēt mītapā! :)

[codez]

Jo es ļoti skaļi smiešos, kad tavs izcili modulārais frontkontrolieris būs savas 5k rindas garš monstrs, kas ķer visus fakin keisus no katra kontroliera kas vien ir sistēmā. 

Diemžēl tu vēljoprojām neesi parādījis, kā būtu tavuprāt darīt labāk.

Bet, fronkontroleris atbild par to, kuru kontroleri izsaukt. Tad nu lūk, ka izsaucot kādu kontroleri, parādās kļūdu ziņojums un pieprasījums ir jāpadod cita kontrolera (kļūdu ziņojumu attēlojošā) ziņā, tad tieši tas ir front kontrolera kompetencē. Tā ka no loģiskas arhitektūras viedokļa viss kārtībā

 

Codez un F3llony, varēsiet arī par šo te padiskutēt mītapā! :)

Tā kā nedzīvoju galvaspilsētā, slinkums uz turieni vilkties, tā jau noteikti aizietu un padiskutētu.

[Mr.Key]

Code Complete iesaka izmantot return, jo tad kods veidojas pārskatāmāks - ir uzreiz redzams, kur kods "iziet". Savukārt ifi un konstrukcijas, lai iziešana no funkcijas tikai tās beigās, ir grūtāk uztverami.

 

Pats sākotnēji biju skolots, ka labā prakse ir ļaut kodam iziet no funkcijas (metodes, procedūras, programmas, ...) normālā veidā, t.i., aizejot līdz tās beigām un ka sliktā prakse ir ja no funkcijas iziet pa tiešo. Tomēr, kā redzams, pieejas un viedokļi atšķiras un šobrīd uzskats ir pretējs.

 

function kautkas($parametrs)
{
    $error = null;
    if ($parametrs == NEDER) {
        $error = true;
    }
    // ...
    if (!$error) {
        // ...
    }
    // ...
}

 

vs.

function kautkas($parametrs)
{
    if ($parametrs == NEDER) {
        return;
    }
    // ...
}

Edited March 9, 2013 by Mr.Key

[Mr.Key]

Atsevišķs AJAX kontrollieris? Kontrolieris var būt viens un tas pats, AJAX gadījumā datus atgriež AJAX formātā, ne AJAX gadījumā parastajā formātā. Man, piemēram, patīk ZF risinājums, kurā iespējams ieslēgt konteksta slēdzi, kas, konstatējot, ka pieprasījums ir AJAX (pēc header), skatam piešķirtos datus atgriež AJAX formātā, attiecīgi, izslēdzot layout un view. Vienu un to pašu action metodi var izmantot nemaz nemainot to (metodi), jo konteksta "ķeršanu" ieslēdz kontroliera modeļa init() metodē. Lūk, DRY! Pielietojums: attēlo lapas sākotnējo ielādi ar view, un, ja klients atbalsta JS, HTML piedāvā lapas atjaunošanu (vai pāršķirstīšanu, utml.) ar AJAX, saites downgreidojas uz HTML saitēm, ja JS nav. Attiecīgi, bez JS viss notiks tāpat, tikai ar pilnu lapas pārlādēšanu. Tā kā klienti bez JS šobrīd nav aktuāli (laikam), tad reālākais lietojums ir tāds, lai Google varētu indeksēt visas lapas, nevis tikai pirmo.

 

Account modelī funkcija, kas pārbauda, vai accounts ir autorizējies? Tas varētu būt novecojis variants. Kā jau teikts, autorizācija ir kontroliera atbildība, autorizēties var daudzos dažādos veidos.

 

Exceptions derētu lietot izņēmumsituācijām, nevis ļoti atbilstošām pārbaudēm. Cik zinu, Exceptions mētāšana nav efektīvs veids pārbaužu veikšanai gan no programmas izpildes viedokļa, gan no koda uzturēšanas (saprotamības) viedokļa. Vēl arī jautājums par tranzakcijām - pārbaudot konta atlikumu, tajā sekundes daļā, kad tiek veikts pirkums, tas var izmainīties. Kā to risināt, kurā brīdī iesākt tranzakciju un kā izvairīties no deadlock?

 

Kontrolieri ir dažādi, tipiski web FW satur FrontController un ActionController, vēl arī nodala fat models/thin controllers vs. thin models/fat controllers - divas dažādas pieejas. Primāri daudz ko nosaka FW izvēle. Ja izvēlas gatavu FW ar labu arhitektūru, atliek vienkārši tai sekot. Ja ir vēlme ieciklēties uz savu FW un ignorēt jomas attīstību turbo tempos, var jau darīt arī tā...

Edited March 9, 2013 by Mr.Key

[Battery]

Viena lieta, kas man īsti nav skaidra:

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

Tas ir kaut kāds anti-patterns ar exceptioniem vadīt flowu.