Laravel programmētāji

[Mr.Key]

rindas, kurās selekti + multiselekti, kas visi tiek dinamiski pievienoti vai noņemti (lietotājs var pievienot filtra nosacījumus ar jquery clone/remove).

Piemēram, ja ir selekts type un tam piesaistīts multiselekts subtypes:

 

?type[]=1&subtype[]=A&subtype[]=B&subtype[]=|&type[]=2&subtype[]=A&subtype[]=C&subtype[]=Z&subtype[]=|&...

 

Ar šo secību izeju cauri un pie katra subtype[] == "|" (hidden elements aiz katra multiselekta) zinu, ka multiselekta elements beidzas un ka nākošie subtype[] ir jau nākošais multiselekta elements.

 

Tas ļauj iztikt bez JavaScript iesaistes elementu nosaukumu veidošanā.

[jurchiks]

>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?

Edited June 19, 2016 by jurchiks

[F3llony]

Kaut kāda stipri dīvaina struktūra Tev tur.

[
    {
        type: 1,
        subtypes: [
            1,2,3,4
        ]
    }
]

type[i]['type'] = 1;
type[i]['subtypes'] = [1,2,3,4];

Kaut kā tā nebūtu loģiskāk? Un JS nemaz nevajag iejaukt. I ir DOM type pozīcija.

[jurchiks]

Varētu jau vismaz šādi:

?type[]=1&subtypes[1][]=A&subtypes[1][]=B

&type[]=2&subtypes[2][]=A&subtypes[2][]=C&subtypes[2][]=Z

...

[Mr.Key]

Kā dabūt to [1] un [2]? Ar javascript baigi čakarīgi, ne?

 

Ieskatam (šis iet kā POST, nevis caur URL GET, bet vairāk doma ir par nenoteikta izmēra divdimensiju masīviem):

 

Lapā ir viena vai vairākas šādas tabulas.

Katru tabulu var pievienot vai noņemt. Tabulas pievienošana notiek ar jQuery clone noklonējot tabulu, atstājot tikai 1x1 šūnu un notīrot vērtības.

Katru tabulu var pabīdīt uz augšu/leju.

Katrai tabulai ir papildus dati (selekti, kuros norāda, kas tur ir tajā tabulā, komercijas gadījumā tās protams ir kaut kādas preces).

Katrā tabulā var pievienot jaunas tukšas vai dzēst rindas, kolonnas. Tas notiek ar jquery clone() vai remove() un nometot vērtības.

Katru rindu, kolonnu var bīdīt pa labi/kreisi, uz augšu/leju, saglabājot saturu.

Tabulas rindu priekšā ir tekstiņš un lauki, kolonnu augšā ir selekti. Respektīvi, ir elementi pa Xn, Ym un elementi XnYm, kur n un m mainās.

 

Tabulas cell ir magic fīčas, kuras šeit nav redzamas, bet kur nospiežot podziņu, šūnas izskats mainās vai arī parādās dažādi papildus elementi (tiek saģenerēti ar jquery, tad hide/show vai kaut kas tamlīdzīgs, jau vairs neatceros). Kad šī magic fīča tiek ieslēgta, protams, saglabājas iespēja visu bīdīt, pievienot vai noņemt.

 

Lietotājs darbojas pa šīm tabuliņām, savada visu vajadzīgo, tad kaut kādā brīdī to visu saglabā. Saglabājoties, protams, dati tiek saglabāti atbilstošā secībā, tā, kā tas redzams uz ekrāna.

 

Ar JavaScript baigais čakars tur sanāktu uzturēt indeksus. Ar iepriekš minēto principu es vienkārši detektēju, kurā brīdī ienākošajos datos mainās šūnai XY mainās X vai XY, vai ir sākusies jauna tabula. PHP neatbalsta elementus 'name[][]', jo ienākošie dati vienkārši ir html elementu secībā.

 

Daudz kas notiek ar jQuery selektoriem $('input[name="element[]"]'), neizmantojot idus vai klases. Tad nu no tādas 1x1 tabuliņas lietotājs var saspaidīt kaut vai 100 tabulas, katru ar cik vajag šūnām. funkcionalitāti nodrošina dažpadsmit jQuery eventi. Kad viss tiek submitots, dati ienāk vienkārši attiecīgā secībā un HTTP POST gadījumā vienkārši tiek padoti breaki, kas PHP pusē strādā tā, ka cikliņš saprot, kurā brīdī mainās x, y.

 

 

[jurchiks]

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'] ?: [];

}

Edited June 19, 2016 by jurchiks

[Mr.Key]

Kaut kāda stipri dīvaina struktūra Tev tur.

[
    {
        type: 1,
        subtypes: [
            1,2,3,4
        ]
    }
]

type[i]['type'] = 1;
type[i]['subtypes'] = [1,2,3,4];

Kaut kā tā nebūtu loģiskāk? Un JS nemaz nevajag iejaukt. I ir DOM type pozīcija.

Varbūt ne visu saprotu, bet kā HTMLā tiek menedžēts tas ?

 

Vienkāršāk sakot, ja tev ir lauku grupas, kuras veido viens select un viens multiselect, kā tu iesūtītu datus? Kādi lauku nosaukumi? Ko PHP dara?

 

1) [select] [multiselect] 

...

N) [select] [multiselect]

[jurchiks]

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[]">).

[Mr.Key]

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[]">).

Tas nozīmē, ja jāģenerē abās pusēs, pirmo reizi - izvadot formu, otro reizi - ar JS reaģējot uz lietotāja veiktajām izmaiņām.

 

Manā gadījumā viss notiek bez , un jquery metodes būtība sastāv vienrindēm "$(this).closest('tr').before(clone.clone());", "$(this).closest('tr').remove();", un eventi, protams, tiek definēti ar delegate principu, kas nozīmē, ka visas podziņas strādās, izpildoties iepriekšrakstītajai clone().

[jurchiks]

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

[F3llony]

Jap, i naksies ģenerēt. Taču, Tev i vērtībai nav nozīmes, so i vertība var būt jeb kas unikāls - i vertība Tev nepieciešama lai vienkārši solidi grupētu client/server pusē, ne kam citam. So, i varbūt kaut kāds i++ counteris, kas kaut kur mētājas un incrementējas katru reizi, kad paceļas jauns elements.

Edited June 19, 2016 by F3llony

[Mr.Key]

Skaidrs, domāju, ka tie ir divi atšķirīgi principi ar saviem +/- un atkarīgs no situācijas. Taču ceru, ka izskaidroju, kādēļ tā secība ir svarīga.

 

Jurchiks, tas parsings ir tikai pie datu saņemšanas, kad parsings šā vai tā ir nepieciešams. Turklāt, ja dati ir secīgi, tad indekss jau ir - tas ir datu elementa kārtas numurs. Neko papildus tur vairs nevajag. Tas ir tāds pats i, kā tad, ja to būvētu ar skriptu. Nav skaidrs, kādēļ Laravel un Illuminate uzbāžas ar savu iejaukšanos.

    /**
     * Normalizes a query string.
     *
     * It builds a normalized query string, where keys/value pairs are alphabetized,
     * have consistent escaping and unneeded delimiters are removed.
     *
     * @param string $qs Query string
     *
     * @return string A normalized query string for the Request
     */
    public static function normalizeQueryString($qs) {}

Nu malacītis, paldies!

 

P.S. Lieki piebilst, ka ar riteni neizbraucu, jo nācās guuglēt teju vai katru soli un līst metožu definīcijās, lai saprastu, vai tur ārā nāks kolekcija, masīvs, vai būs associatīva vai objektu fetchošana, utt. Tā tā popularitāte googlē rodas...

Edited June 19, 2016 by Mr.Key

[jurchiks]

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?

[Mr.Key]

Viņš to varētu arī nedarīt un būtu ļoti labi. Velk uz tādu kā wordpresu, kur paši ziniet, kas notiek ar datiem.

Edited June 20, 2016 by Mr.Key

[jurchiks]

Nu, tāds tas Laravels ir.