jurchiks

Tu tur kaut kur neesi aizmirsis $i++?

Nu, tāds tas Laravels ir.

Tagad tev ir jāciklē cauri visiem GET/POST parametriem un jāmeklē tas | simbols, pēc kura jāgrupē subitems. Tā ir tā liekā parsēšana. Ko tas Laravel normalaizeris reāli ar taviem datiem izdara? Kaut ko būtiski maina?

Bet tavā gadījumā tev ir jāveic lieks parsings.

Vai nu javaskriptā, vai PHP, bet kaut kur tas ir jāģenerē, ne no kurienes tas neradīsies (izņemot primitīvus <input name="field[]">).

Uhh... <input type="text" name="subtypes[1][]" value="whatever" /> Tu taču tikko teici, ka tu ar JavaScript tur neko nedari. Anyway, es vispār taisītu tā, lai rezultātā dati būtu: types[0][id]=1&types[0][subtypes][]=X&types[0][subtypes][]=Y ... Rezultātā PHP nebūtu nekāda sviesta, vnk: foreach ($_POST['types'] as $type) { $id = $type['id']; $subtypes = $type['subtypes'] ?: []; }

Varētu jau vismaz šādi: ?type[]=1&subtypes[1][]=A&subtypes[1][]=B &type[]=2&subtypes[2][]=A&subtypes[2][]=C&subtypes[2][]=Z ...

>Tas ļauj iztikt bez JavaScript iesaistes elementu nosaukumu veidošanā. Bet vai nebūtu vieglāk/labāk tomēr paņemt palīgā JavaScript?

Kaut kā nebiju piefiksējis, ka Prinful tik daudz ko drukā...

Kāda saistība drukas produktiem un e-veikaliem?

drukas kļūda - pareizi ir https://www.codecademy.com/ Vēl var piemest klāt Pluralsight/Codeschool + https://developer.mozilla.org/en/docs/Web.

Vai tiešām draugiem.lv taisa woocommerce veikalus?

Labi, bet tas attiecas tikai uz manu pirmo teikumu. Bagus un neparedzētas (lasīt: nevēlamas) situācijas tas nekādīgi neizslēdz.

Jebkura sistēma ir tikai tik laba, cik labs ir tās radītājs. Ja radītājs kaut ko nav paredzējis vai pielaidis kļūdu... Tad tikai radītājs pats vai viņa aizvietotājs spēs to labot, ne sistēma pati. Vismaz tuvākajā paredzamajā laikā.

Izņemot tevi un F3llony.

Tas tā nebija domāts, ka tikai 0.5h max.

Jāapskatās.

>labiem developeriem vienmēr pieejami labi darbi Muļķības. Ne visiem labajiem developeriem ir plašs paziņu loks, kuri visi pastāvīgi piedāvā darbu.

Tipa tas darbs, kuru pakaļ met, vienmēr ir labs, ja?

Oi, kruts uzbrauciens. Nedēļas laikā labu darbu neatradīsi, ja vien baigi neveicas. Un kurš nu kuru par vāvuli būtu nosaucis... Pot calling the kettle black.

Tev vispār nevajadzētu neko veidot.

Latvijā vērtē zemāk. Tādu kantori nodedzināt.

Ir prikoli, bet ne tik neintuitīvi.

Vajadzēja uzreiz savu rezultātu arī iedot. Bet vispār, skumji, ka JS ir tik daudz tizlu un neintuitīvu quirku (piemēŗam, ka [] + [] = empty string; PHP/Python/Ruby u.c. valodas atgriež jaunu, tukšu masīvu). Faktiski, ja tu gribi būt hardcore JS skripteris, tad tev jāmāk atpazīt kaudzi huiņas, kuras citās valodās nav. Jautri.

Biju piemirsis par funkcionālajiem, domāju tikai unit testus. Bet lieliem, veciem projektiem ar aizvēsturisku HTML struktūru (few classes/IDs) arī tā būtu būtiska problēma. Bet nu tādos gadījumos tas jau nav atkarīgs no manis, un zinot tos projektus, esmu pārliecināts, ka projektu vadītāji būtu automātiski pateikuši "netērē laiku liekām lietām, ar to lai nodarbojas testētājs" (tas, kurš manuāli kliko 15x cauri formām, un citādāk nemāk). Es labi saprotu, kas ir testi un kā tos rakstīt, bet man personīgi vai nu pēc tādiem nav bijis nepieciešamības (jo es rakstu vienkāršu kodu, kurā man viss tāpat ir saprotams), vai nav bijis iespējas tos ieviest. >"Tik pat labi, tas "otrs" esi Tu, labojot kodu citā vietā, un radot problēmas citur." Savos privātajos projektos es to gandrīz vienmēr pamanu uzreiz, jo, kā jau esmu vairākkārt minējis, es visas izmaiņas pārlasu vairākas reizes, kamēr pilnībā saprotu visu, ko esmu izdarījis, pirms kommitoju (7 reizes nomēri...). Ļoti retos gadījumos, kad baigi steidzos vai esmu baigi ar kaut ko aizrāvies, gadās, ka nepārlasu, un tās ir praktiski vienīgās reizes, kad pieļauju kļūdas. Bet arī tad es tās ātri pamanu un izlaboju, jo vēlāk pārlasu iepriekš veiktās izmaiņas. BET. Mēs kārtējo reizi ejam offtopikā. Varētu jau vienreiz mūžā piebremzēt.