Formulář se před zpracováním znovu vytváří, co když se vytvoří jinak?

Dík za odpověď nicméně problém není tak jednoduchý, samozřejmě pojmenovávám checkboxy pomocí id, ale to je právě ten problém, uživatelé si stěžují, že jak blbci vždy zaškrtávají půl hodiny seznam 100 checkboxů, a z toho se jich zpracuje třeba jen 50, takže nakonec mi vyčítají, že mi nafakturují 15 min. za každého zaměstnance několikrát denně.

Jinak token a různé další zamykání je nereálné, ani vypršení, opět by nastal problém, že skoro každý požadavek by byl neplatný, protože na stejném gridu pracuje současně třeba 10 lidí, mi nevadí, že si něco budou přepisovat, ona operace smazání není ta o kterou se perou, ale jde právě o to zaškrtávání ceckboxů nebo vyplnování 100× nějakého inputu. Představte si např. editable datagrid, kde 10 zaměstnanců opravuje 100tisíc položek, jejich úkolem je přepsat všechny, takže upravují v datagridu jeden sloupeček. Tím, ale jak postupně upravují tím se mění formulář pod rukama a tak se z těch všech změn zapíše jen zlomek, to že by nastala situace, že řádek 105 někdo upravil a hned za ním ho upravil někdo jiný, to by mi nevadilo, ale jak to řešit prakticky?

Bez Nette formulářů ani žádná taková kontrola nikdy neexistovala, a tak jste zpracovávali pouze POST a tohle nebyl problém.

jj tak nějak to chci udělat také, nemáš někde ukázku?

Jenom to zkusim doplnit malou uvahou. Mejme datagrid s nekolika polozkama. Jsou tam checkboxy pojmenovane vzhledem k id (treba produktu, to je fuk). A ted jednotlive situace:

• zasktnu si prvni check box a chci to smazat. Uz to ale udelal nekdo predemnou. Neni problem, pri vytvareni formulare se prvni radek nevytvori, probehne kontrola a odeslana hodnota se zahodi, ale v tuhle chvili uz je to jedno.
• edituju jednu z hodnot, ale mezi tim uz ji nekdo smazal. Problem…jedine rozumne reseni je editovanou polozku uzamkout pro exkluzivni pristup, aby mi ji nikdo jiny pod rukama nemenil.
• edituju jednu z hodnot, ale mezi tim uz ji nekdo dalsi editoval a ja mu to prepisu. Problem…opet to resi asi jenom zamykani pristupu k dane polozce v case, kdy ja ji edituju, aby to nikdo dalsi v tu chvili nemohl udelat.

Takze asi tak:-)

2. uzamknout od zacatku editace (cili od zobrazeni editacniho formulare pro danou polozku) az po jeji ukonceni (cili zavolani obsluzneho handleru a zpracovani dat).
3. to je sice asi pravda, ale je to vsechno strasne zbytecne slozite, prekombinovane a nespolehlive. Proste kdyz chci editovat nejakou polozku, tak pri zobrazovani editacniho formulare si otestuju, jestli je polozka odemcena a pokud ano, tak si ji zamknu (musi na to nekde byt nejaky sloupecek v db nebo tak neco). No a kdyz pak ten form zpracovavam, tak tu polozku zase odemknu. Neni to zase tak obtizne (ackoliv to ma, jako vsechno, svoje uskali) a pritom to resi snad vsechny tady napsane problemy.

@arron: A když jeden uživatel půjde na oběd se zobrazeným formulářem tak půl hodiny nepůjdou hodnoty změnit … ? Tak s tímhle by se toho moc neudělalo =)

uzamknout od zacatku editace (cili od zobrazeni editacniho formulare pro danou polozku) az po jeji ukonceni (cili zavolani obsluzneho handleru a zpracovani dat).

A budes mat deadlock ani nevies ako :). Co ak userovi co nieco edituje padne PC, dany zaznam ostane v locku a smola.

vyprseni zamku

A vies nejak rozumne kvantifikovat cas, ktory treba na editaciu jedneho zaznamu? Aby si nenastavil expiration na kratko, ale zase ani dlho.

Nepujdou menit hodnoty u toho jednoho zaznamu. To mi neprijde tak hrozne.

Ak vravis, ze sa to tam tak hekticky meni pod rukami tak to nebude len jeden zaznam ale vela zaznamov, kde by deadlock mohol nastat.

Mna co napada ako riesenie je, ze kazdemu riadku DB das este napr last_access field, ktory bude timestamp s on update current timestamp a pri potvrdeni editacie od usera, skontrolujes ci sa zaznam zmenil v DB alebo nie (samozrejme predtym si musis niekam ten povodny cas – pri prvom requeste o editaciu – ulozit, napr session). Je to sice dotaz na DB naviac ale myslim si ze to celkom riesis co chces, nie?

Sory ale diskuse je trochu jinde než můj problém, zkusme fakta:

1. máme editable datagrid / tedy editujeme název, zda je řádek v akci, skladem, atd. atd. chceme to hromadně, prostě je to nutné!
2. locky apod. nemožné, současné pracuje na gridu 10lidí
3. ten grid, má různé filtry a hlavně řazení!

modelová situace:

mám seznam a jsem na páté stránce, seřazeno podle názvu

jenomže než odešlu všech svých 100 změn které jsem v názvech udělal, někdo jiný už upravil stránku číslo 1, tudíž po odeslání gridu/formuláře už se mi neuloží ani jedna změna, a na uživatele pouze vyskočí jiná sestava dat a bohužel se ani nedozví, že jeho změny se neuložili, což je možná lepší, kdyby se to dozvěděl asi by mi prohodil dlažební kostkou okno u auta

@mcmatak

Kus gridu (v továrničce formu) na opětovné sestavení formuláře …

if($form->isSubmitted()) {
	if(isset($form->httpData[self::EDITABLE_ROWS_CONTAINER])) {
		$rowsData = $form->httpData[self::EDITABLE_ROWS_CONTAINER];
		foreach($rowsData as $rowName => $row) {
			$rowContainer = $rowsContainer->addContainer($rowName);
			$this->createEditableRow($rowContainer, null, false, $row); // tohle volání vytvoří řádek podle zadání
 		}
	}
}

Jestli záznam existuje, nebo už se s ním stalo úplně něco jiného musíš řešit v modelu. (S tím souvisí diskuze výše)

Editoval Foowie (16. 10. 2010 12:15)

snad jen pro upřesnění, abychom byly všichni v obraze

<?php
strana 5. seřazena podle name

id           name              cena          skladem
15           Vrtačka 51         100           ANO selectbox editovatelný
16           Vrtačka 52         100           ANO selectbox editovatelný
17           Vrtačka 53         100           ANO selectbox editovatelný

ještě než tyto změny odešlu, tak jiný uživatel smazal Vrtačka 49

tedy formulář se před zpracováním změn sestaví takto

id           name              cena          skladem
15           Vrtačka 52         100           NE již editovaná hodnota
16           Vrtačka 53         100           ANO již editovaná hodnota
17           Vrtačka 54         100           ANO již editovaná hodnota   (úplně nový prvek ve formu nebyl)
?>

prvek vrtačka 51 se vůbec neupraví! před zpracováním vůbec není součástí formuláře!

Editoval mcmatak (16. 10. 2010 13:38)

nechci nic říkat, ale mně se to zdá celé neějak špatně navržené.

• jestli je něco skladem nebo ne, by se mělo hlídat podle počtu kusů na skladě a ne to zadávat ANO/NE. K těm buď počet přidávám nebo ubírám. Ubrat nemůžu, pokud je odebírané množství větší, než je počet kusů na skladě, pak nabídne systém pouze počet kusů, které jsou při zpracování k dispozici a položku sám nastaví, že už není skladem
• jestli mi nějaká položka do skladu přibude, tak by mě to taky nemělo zajímat, protože jsem ji původně neměl v úmyslu ani editovat.
• pokud někdo položku smaže a já na ní něco edituji (což mi přijde, že pravá ruka neví, co dělá levá), tak by se logicky update vůbec něml provést, protože položka byla odtraněna a tedy už na ní není, co měnit, když ji nějaká vyšší autorita zrušila. Zjistím podle ID.

Jestli je to tak, že nějaký operátor kouká na nějaký online seznam a ten nějak libovolbě edituje, tak by se měly položky té tabulky obnovovat v nějakem intervalu přes nějaký AJAX dotaz, aby operátor měl jakžtakž aktuální obraz DB.

Myslim, ze se tu snazime naznacit, ze Tebou navrzene (a zjevne i implementovane) reseni ani neni uplne optimalni, coz se asi i v praxi ukazuje:-)

Jestli jsem to uplne spravne pochopil, tak jde o to, ze kdyz si vygeneruju formular treba pro patou stranku a nekdo smaze neco, co je o stranku (ci vice) driv, tak pri odesilani toho formulare uz pata stranka vypada jinak, takze se proste vygeneruje jiny form…

Ok, takze je potreba generovat uz ten formular nejak jinak a to tak, aby na tech strankach pred tim nebyl vubec zavisly. Coz by se dalo udelat treba tak, ze pri tom generovani bych si ulozil (do session) idecka zaznamu, ktere tam jsou. Pri odeslani bych se podival, jestli mam neco takoveho ulozeneho, a kdyz ano, tak bych vygeneroval formular na zaklade tehle dat. Tim se kazda stranka stane nezavisla na ostatnich a mel by se ten problem vyresit, protoze i kdyz nekdo nektery z tech zaznamu smaze, tak to nevadi, protoze ta data se proste zahodi, coz u smazaneho zaznamu neni az tak kriticke ne?

Jine reseni by asi bylo, aby se editacni formular vytvarel zvlast pro kazdou polozku a tim by mohl cely tento problem odpadnout. Dal by se pak generovat urcite i pres ajax a i ajaxove odesilat, coz by resilo uzivatelsky komfort (a dalo by se tam IMHO pouzivat i to zamykani zaznamu, coz je technika bezne pouzivana ve vicevlaknovem programovani, kde se resi stejne problemy exkluzivniho pristupu).

Editoval arron (17. 10. 2010 1:54)

Dle meho nazoru, pokud je ve formulari nejaka chyba a neni mozne ho zpracovat, tak to uzivateli prece muze byt skoro jedno, jestli kouka na aktualni aktualni informace nebo ne. Dulezite je, aby videl to, co pred chvili editoval a videl, ze jsou tam nejake chyby. To co je okolo, tim se nejspis bude zabyvat az ve chvili, kdy se formular odesle v poradku a v tu chvili uz se mu daji predhodit aktualni data. Co se tyka invalidace te session…mno…rozhodne je potreba ji invalidovat na konci uspesneho submitu (ve chvili, kdy je jasne, ze to vsechno probehlo tak jak melo). No a pak me napada, ze je potreba vymyslet nejaky elegantni zpusob, jak ji invalidovat ve chvili, kdy se uzivatel rozhodne ten formular vubec nesubmitnout a prejit treba na dalsi stranku. Myslim (ale ted to nemam fakt nicim podlozene), ze by se melo nechat zjistit, jestli se ma zpracovavat nejaky handle a podle toho se treba uz ve startupu rozhodnout a pripadne ta data v session smazat vcas.

Ad. oddelene formulare: Vzdyt to, ze jsou ty formulare oddelene, tak to jeste neznamena, ze nemuzou vypadat stejne jako ted ne? Akorat se nebudou submitovat vsechna data najednou, ale postupne (ajax). Ale je pravda, ze to bude asi slozitejsi…

1. mozna si posilat nejaky token v hidden fieldu?
2. no co se tyka tech dat, tak by se ta stranka prece zrekonstruovala cela (vcetne dat okolo, jestli jsem to opravdu spravne pochopil), takze by to mohlo projit:-)
3. musel by tam byt nejaky buttonek no. Pak uz by to bylo v pohode, protoze by se odesilal vzdycky jenom jeden zaznam a vytvareni toho formu by bylo v pohode…to je vlastne ta hlavni vyhoda, ze jo.

1. token to resi tak, ze kdyz zjistis, ze prisel, tak vis, ze jsi odeslal nejaky formular a ze ta data nesmis invalidovat (jedine po uspesnem submitu). Kdyz ten token neprijde, tak k zadnemu submitu nedoslo a ta data uz jsou stara (protoze uzivatel pravdepodobne presel na jinou stranku nebo proste udelal cokoliv jineho nez odeslani formulare)
2. tak nevim kolik tech mist je, podle meho jenom ta tovarnicka toho formulare, je to jeden if a kdyz, tak se to da vytahnout do nejake metody a dokonce mozna to dat primo do modelu (to uz ale zalezi na konkretni implementaci), takze az takovy problem v tom nevidim:-)

1. no hodis nejaky ten token do hidden fieldu toho formulare a kdyz se ten formular odesle, tak se ten token objevi bud v postu a nebo v getu. Kdyz se tam ten token neobjevi, tak uzivatel formular neodeslal, cili asi kliknul na neco jineho. Ale taky hodne zalezi jak mas ten grid udelany…
2. Tak netreba uchovavat vsechna data. Myslim, ze staci uschovat jenom pole prislusnych idcek a z nich uz neni problem ta data vytahnout z databaze.

1. uz to asi lip vysvetlit nedokazu:-)
2. V cem je to tak slozite?

No a to je prave ono…pokud se ten form neodesle, tak se pri dalsi pozadavku nikde zadny token neobjevi a ja vim, ze uzivalel ten form neodeslal, tzn. dalsi form musim vytvorit s aktualnich dat, takze ty co mam ulozene nekde v session muzu zahodit.

Je tu na mě moc textu, takže se ztrácim, ale: nemůže to bejt live? Ajaxový? Ve chvíli kdy někdo někde něco smaže, tak se z datagridu ztratí? a prostě není? řekněme timer na 200ms, který prochází znova db a prvky, který už tam nejsou skryje, vyhodí, zničí a prvky se změnou změní? Pokud na tom dělá 10 lidí je to eště oukej ne? Zátěž na serveru zas taková nebude…

1. jednak za pul hodiny vygenerujes uctyhodny balicek dat, odhadem na jednoho cloveka to bude 1.5mb dat minimálně, což nevím jestli se mi líbí v session
2. ono opět možnost editovat form jen do půl hodiny, je dost problém, to není moc user friendly, jednoduše tuhle možnost bych asi uzavřel, ať zbytečně nerozvíjíme flame, což už stejně je
3. samozřejmě by se data dala odesílat spolu s formem, ale je taky otázka co vše chceme/můžeme ukázat uživateli ze střev systému, serializace a deserializace dat je zase další api navíc / no přijde mi to jako moc potíží na běžný problém

@karmiq bohuzial websockets je v tomto vlakne OT, lebo:

1. podporuju to iba najmodernejsie browsery (vypadava vsetko pod FF-4, O-10.7, IE9, Safari 5)
2. neurobis to s PHPckom – aplikacia musi bezat ako daemon (nonstop)

Myslim, ze bod 2. si @mcmatak nemoze dovolit, znamenalo by to uplne zahodit PHP/Nette.

Editoval srigi (19. 10. 2010 16:52)

1. obavam se ze to neni ta spravna cesta, app by měla být přístupná, jinak je to řešení spousty problémů navíc
2. nj

mám obecný datagrid, joinuje tabulky, vytváří různé vazby, subgridy a zanoření editačních prvků, tohle všechno je problematické rekonstruovat na základě nějakého idečka, těch dat je potřeba hodně, navíc je to celé hodně dynamické, takže zachytit stav v nějakém okamžiku je prostě problém, no nic, obávám se, že jediné řešení je zpracovávat rovnou post, čemuž jsem se chtěl zásadně vyhnout :(

nějak se to protahuje a je tady spousty balastu, nejraději bych to smazal a zeptal se znovu, ale to bych znovu musel vysvětlovat ty samé věci

pokusím se být co nejvíce konkretní

1. ano souhlasím sestavit formulář znovu na základě odeslaného, ale co když tam bude chyba jak o tom spravím uživatele? k tomu, aby mohl ve formuláři opravit chyby potřebuje kontext a ten vzít kde
2. jinak představ si úplně obecnou komponentu datagrid, která prostě zobrazuje na základě XY filtrů, na základě XY řazení nějaká data z dtb, jen stěží dokáži složit podobný dotaz na základě 100× ideček

ale tak to už je problém jiný, šlo mi jen o to jestli tohle někdo řeší lépe než já, výsledkem je to sestavit na základě něčeho znovu / nebo prostě zpracovat holý post no

já vím je to vlákno dlouhé na čtení no, smažme ho :) asi tady nic nevymyslíme

nejde o formulář, jde o to, že potřebuješ nabídnout uživateli možnost změny, když něco zapsal chybně, takže ten input potřebuji zasadit do nějakého kontextu, tzn. do řádku gridu, potřebuji rekonstruovat řádek gridu, název produktu, cenu, atd. aby si uvědomil u čeho to opravoval, s tím se asi váše odeslat komplet grid v hidden polích, další řešení