Ahoj Mirku, procházel jsem ten Interní kalendář MKC, provedl jsem tam pár změn, jejich popis posílám níže. Plus ještě bych prosím tě potřeboval upravit věci červeně níže. Tzn. informace černě si prosím jen projdi, to jsou věci, které jsem již upravil. A informace červeně prosím potřebuji upravit od tebe. Díky moc. T.

 

Nastavení uživatele:

if(strlen($heslo)>=6 or strlen($heslo_kontrola)>=6) {

v souboru /web/interkal/_scripts/_nastaveni.php

není optimální, neboť pokud uživatel vyplní např. 2 znaky, tak to uloží, myslí si, že je heslo změněné, ale není.

 

Současně ten princip přesměrování na chyby v /web/interkal/_scripts/_nastaveni.php nefunguje. Musí tam být za přesměrováním (za location()) uvedeno exit;, jinak ten skript běží dál a přesměruje se to jinam. Bez exit; to funguje jen za předpokladu, že další přesměrování je schované v nějaké podmínce, která není platná. Napří.

 

if($chyba==0){

location(….)

}else{

location(…nekam jinam….)

}

 

ale takto to nefunguje (takto se to přesměruje "někam jinam"):

if($chyba==0){

location(….)

}

location(…nekam jinam….)

 

a je potřeba tam přidat to exit, takto:

if($chyba==0){

location(….);

exit;

}

location(…nekam jinam….)

 

 

A ještě k tomuto - osobně si myslím, že toto větvení podmínek před vložením akce , resp. testování, zda je vše vyplněno správně formou větvení několika if…else, je podle mě méně vhodné řešení. Lepší je dle mého názoru přidat několik podmínek nahoru, testovat zkrátka jestli tam není chyba a pokud ano, tak přiřadit číslo chyby do proměnné $chyba. A až dole pak přidat podmínku if($chyba>0) { … přesměruj na chybovou hlášku… }else { …. ulož záznam … }. Jde o to, že když se rozhodneme přidat ještě nějakou podmínku, tak to bude komplikované a musíme posouvat všechny větvě.

Mrkni se např. na řádky 10 - 13 ve skriptu /web/interkal/_scripts/_poptavka_odeslat.php , zde je to řešeno správně. A pokud se zde rozhodnu, že přidám nějakou podmínku, stačí přidat jeden řádek, nemusím nic posouvat a měnit.

Nyní jsem totiž přidával podmínku do formuláře pro vkládání akce (test datumu začátku akce, viz pár odstavců níže) a nebylo to úplně jednoduché.

 

 

 

Vkládání akce na webu

podmínka strlen($poradatel)<6 není optimální. Dovedu si představit situaci, kdy někdo vyplní jen své příjmení, nebo vyplní název firmy, který má 5 znaků. A pak mu to nefunguje. Vypíše se mu hláška "Vyplňte povinné údaje" a vyplněné údaje se z formulář se vymažou. Upravil jsem to tedy na strlen($poradatel)<1 , tyto podmínky je potřeba nastavovat co nejvíce benevoletně, aby uživatel mohl vyplnit i krátké jméno atd. - je potřeba zvažovat všechny možnosti, které uživatel vyplní.

 

Pokud jsem uživatel 2, tak se mi po uložení akce vypíše hláška "

Děkujeme za vložení nové akce. Akce se začne v kalendáři zobrazovat po odsouhlasení administrátorem.", akce je ale rovnou odsouhlasena.

 

Toto je dost zvláštní způsob:

$cas_do=explode("-", $akce[cas_do]);

           $cas_do_hodiny=explode(" ", $cas_do[2]);

           $cas_do=$cas_do[1]."/".$cas_do_hodiny[0]."/".$cas_do[0];

je to takové nelogické a na první pohled to vypadá jako překlep. Správný způsob by byl (to jen pro info) takový, že nejprve oddělíš datum a čas a poté oddělíš hodiny/minuty/vteřiny a den/měsíc/rok:

$datumCasPole=explode(" ", $akce[cas_do]);

           $hodinyPole=explode(":", $datumCasPole[1]);

$datumPole=explode("-", $datumCasPole[0]);

           $datum_do=$datumPole[1]."/".$datumPole[2]."/".$datumPole[0];

současně v tom vidím ještě dvě věci - vše se jmenuje cas (i sloupec s datem začátku akce se jmenuje cas) a je to matoucí. Chápu, že to máš ošetřené a že je to funkční a že teoreticky na názvu proměnných, sloupců atd. nezáleží, protože by to fungovalo i např. takto: $jakykolivNazevPromenneTrebaKamion=explode(" ", $cas_do[2]);, ale ve skutečnosti na tom záleží, protože když s tím pak bude dělat další programátor (třeba já), nebo když se k tomu skriptu vrátíš za pár let, tak už to bude matoucí a bude náročnější se v tom zorientovat. Je potřeba používat správnou logiku.

Toto nemusíme nyní již upravovat. Ale mysli na to prosím v budoucnu.

Jednu věc ale upravit musíme. A to je formát datumu ve formuláři pro vkládání a editaci akce. Je potřeba, aby to bylo v tom formuláři ve formátu dd.mm.rrrr , např. 24.12.2020. Mělo by to jít nastavit jednoduše přes parametr dateFormat, viz https://stackoverflow.com/questions/1328025/jquery-ui-datepicker-change-date-format . Bude samozřejmě nutné upravit i ty funkce pro načtení jednotlivých dat a sestavení datumu pro mysql..

Formát "12/24/2020" je děsně matoucí. Z pohledu UX je to špatně. Představ si situaci, kdy uživatel zadá datum zítra, tedy 12.listopadu, tak se mu po kliknutí na kalendář vypíše "11/12/2020", což ho zmate, bude si myslet, že se překlikl a vybral datum 11.prosince. Je potřeba nad tím přemýšlet jako uživatel a snažit se při testování vžít do kůže běžného uživatele.

 

Pokud vkládá akci uživatel 3, měl by mít možnost zadat maximálně jeden rok dopředu. V kalendáři mu jde vyprat maximálně rok dopředu, pokud to ale ručně přepíše např. na rok 2023, tak se to bez problému uloží. Což je problém. Stačí to ošetřit jednoduchou podmínkou pro porovnání počtu dnů do startu akce s počtem dnů v $maxDate. Počet dnů do startu akce načteš takto: list($datumAkceZa)=mysql_fetch_row(mysql_query("select DATEDIFF('".$cas_od."', now())")); . Vím, že jsme možná říkali, že bude stačit to omezení v kalendáři, ale nakonec jsem změnil názor.

 

Pozor prosím na jiné názvy sloupců v databázi a jiné názvy inputů ve formuláři. Vím, že to na funkčnost nemá vliv. Ale je potřeba udržovat identickou logiku, viz např. <input type="text" value="<?=$akce[misto_konani]?>" name="misto" id="misto" required> . Toto je tam vícekrát, např. jednou ce něco jmenuje "cenik" a jednou "vstupne" atd. atd. . Vím, že to máš ošetřené a funguje ti to správné. Mně, jako dalšímu programátorovi, to ale způsobí problém, protože to neočekávám (a abych to očekával, musel bych si projít úplně celý kód). Když pak dělám nějaká vylepšení, např. nyní připravuji skript pro načtení dat ze session (viz odstavec níže), tak narazím na chybu. Plus práce, která by mi zabrala 5 minut mi zabere třikrát tolik. Snaž se prosím udržovat vždy stejnou logiku. Vím, že to né vždy jde, ale pokud to jde, je to potřeba.

 

To, že se uživateli při chybně vyplněném formuláři vypíše chybová hláška a smaže celý obsah formuláře není optimální z pohledu UX. To smazání obsahu každého děsně naštve. Částečně jsem to pořešil funkcemi ulozPostData a vymazPostData. Mrkni na ně + na /web/interkal/_incl/_pridat-akci.php řádek 108-127. Toto ten problém řeší (uloží to data odeslaná přes POST do SESSION a po úspěšeném uložení to ty SESSIONs zase smaže. Neumí to označit checkboxy Typ akce a Cílová skupina, na to již nyní nemám prostor a navíc bude nutné toto stejně trochu předělat, viz odstavec níže.

 

Bude nutné předělat způsob ukládání typů akcí a cílové skupiny k akcím. Takto to nemůže fungovat a bude to dělat problémy. Podmínka if(strpos($akce[typ_akce], $arTypy[id]) !== false) { není dostačující. Představ si situaci, kdy klient zadá do RS další typy akcí (a k tomu 100% dojde). A vznikne tam nový typ, který bude mít ID 10, 11, 12 atd.. Pokud uživatel vybere typ akce Výstava (tedy ID 1), tak se mu pak při editaci akce označí i typ akce 10, 11, 12, ty totiž všechny splňují podmínku  if(strpos($akce[typ_akce], $arTypy[id])  . Toto se správně řeší přes vlastní extra db tabulku např. akce_typy_prirazeni. Nyní to ale na vlastní db tabulku předělávat nebudeme (již na to není čas ani budget). A tuto chybu ošetříme jiným způsobem, který popisuji níže.
Dá se to obejít tak, že ty jednotlivé Idčka obalíš najakým znakem, např závorkami. Místo dat "1,4,7" budeš tedy do sloupce smartdb_akce.typ_akce ukládat toto: "(1),(4),(7)" a podmínka pro označení checkboxu se upraví takto:

if(strpos($akce[typ_akce], "(".$arTypy[id].")") !== false) { . Pak to bude fungovat.

V RS rovnou pak prosím uprav i toto (na Cílová skupina): https://bit.ly/2IgCDCH .

 

 

 

Typ akce RS:

https://www.ukazkawebu.cz/interkal/rsys/index.php?menu=akce-typ

Řazení v RS je vždy potřeba nastavit stejné, jako je nastavené na webu. Tedy v tomto případě dle priority sestupně.

Nám to připadá takto naprosto ok, ale pro běžného uživatele (našeho klienta) je to matoucí (má problém pochopit i ten princip priorit, který používáme a když se mu to pak v RS řadí jinak, je z toho obvykle zmatený - pokud se nejedná o někoho mladého či o někoho, kdo z počítačem pracuje denně). To samé platí pro Cílové skupiny, zde jsem to také upravil.

 

 

 

RS - akce:

Řazení bylo správné (dle data začátku akce apod.), nakonec jsem to ale změnil na řazení dle ID desc, pokud bude totiž admin odsouhlasovat akce, bude to mít takto jednodušší.

Do Kratšího názvu jsem přidal maxlength (je to potřeba, jinak admin vloží akci a pak bude mít název oříznutý, takto tomu můžeme předejít, z pohledu UX je to potřeba).

 

 

Registrace - mail:

Do registrace jsem přidal $obsah.="<p>Jméno: ".$cele_jmeno."<br>Telefon: ".$telefon."<br>E-mail: ".$email."<br>Editace a odsouhlasení zde: <a href='".$root."/rsys/index.php?menu=uzivatele&q=&novy=1&e=".$newid."'>".$root."/rsys/index.php?menu=uzivatele&q=&novy=1&e=".$newid."</a></p>";

, pokud totiž přijde adminovi mail ve stylu "Byl zaregistrován nový uživatel", je to sice ok a dostačující, ale ten jeden řádek zvýší pro admina úroveň UX o 100%. může totiž rovnou kliknout a odsouhlasit ho.

Zanechte nám na sebe kontakt

(ozveme se během 24 hodin)

© 1996-2020 Smartim, s.r.o.

Facebook Google+ Twitter IN
zavřít

Kontaktujte nás

Vymyslíme pro Vás efektivní řešení..