Archívum - Júl 8, 2005 - Fórum téma
SessionID-k adatbázisba mentés során SQL hiba mysql_affected_rows() miatt
Van egy ilyen Sessions tábla frissítő kódom (az SQL rétegben a függvények megfelelnek a mysql hasonló nevű függvényeivel, a $db class működik rendese, abban nincs hiba):
Normális esetben semmi gond nincs ezzel az eljárással, csak akkor van gond, ha egy másodpercen bellül kétszer frissítem az oldalt (pl. véletlen duplaclick), ugyanis ekkor SQL hibát jelez. Kis kutakodás után a php manualban megtaláltam a hiba okát:
Kis keresgélés után ráakadtam a mysql_info() függvényre. Azzal ugyan le tudom kérdezni azt, hogy hány sor felel meg a feltételnek és hány módosult, csak nem tartom túl jó ötletnek egy stringből kibányászni számadatot.
■ // SESSID konstans értelemszerűen a session id
$db->sql_query('UPDATE sessions SET ... last='.time().' WHERE id=\''.SESSID.'\' LIMIT 1');
if ($db->sql_affected_rows() == 0) {
$db->sql_query('INSERT INTO sessions (...) VALUES (...)');
}
$db->sql_query('UPDATE sessions SET ... last='.time().' WHERE id=\''.SESSID.'\' LIMIT 1');
if ($db->sql_affected_rows() == 0) {
$db->sql_query('INSERT INTO sessions (...) VALUES (...)');
}
Normális esetben semmi gond nincs ezzel az eljárással, csak akkor van gond, ha egy másodpercen bellül kétszer frissítem az oldalt (pl. véletlen duplaclick), ugyanis ekkor SQL hibát jelez. Kis kutakodás után a php manualban megtaláltam a hiba okát:
Ha UPDATE-tel használod, a MySQL nem fogja azokat a sorokat frissíteni, ahol a sor régi és új értéke megegyezik. Így nem kizárt, hogy a mysql_affected_rows() függvény nem pont az egyező sorok számát adja vissza, hanem csak a ténylegesen megváltoztatott sorok számát.
Kis keresgélés után ráakadtam a mysql_info() függvényre. Azzal ugyan le tudom kérdezni azt, hogy hány sor felel meg a feltételnek és hány módosult, csak nem tartom túl jó ötletnek egy stringből kibányászni számadatot.
xml és xhtml viszonya?
Üdv Mindenkinek!
Egy html4.0-ból csak akkor lehet xhtml1.0 ha xml irányzat szerint kódolunk, vagy a xhtml1.0 Transitional.dtd esetében eltekinthetünk az xml-től, és elegendő a html tag-ek jelölőszerpük szerinti használata?
Ha ezen témakörben valaki tudna dobni egy (magyar nyelvű)tutorial linket azt szívesen venném
■ Egy html4.0-ból csak akkor lehet xhtml1.0 ha xml irányzat szerint kódolunk, vagy a xhtml1.0 Transitional.dtd esetében eltekinthetünk az xml-től, és elegendő a html tag-ek jelölőszerpük szerinti használata?
Ha ezen témakörben valaki tudna dobni egy (magyar nyelvű)tutorial linket azt szívesen venném
AJAX-hoz ötletek
Sziasztok!
Az utóbbi időben eléggé előtérbe került az AJAX technika, ezért a keretrendszerbe foglalt megoldása foglalkoztat mostanság.
Elolvasva, tesztelgetve ezeket a megoldásokat, próbálunk egy keretet adni neki, ami több helyen is felhasználhatóvá tenné.
Megkülönböztettünk különböző feladatokat, amit a keretrendszernek meg kell oldania:
- adatellenőrzés (például regisztrációkor a kívánt azonosító foglalt-e már, vagy például a jelszó mérete, bonyolultsága megfelel-e az elvárásoknak): ha kilépsz a form elemből (onBlur indítja az eseményeket), egy xmlhttprequest segítségével megkérdezed a szervertől, hogy ez az adat megfelel-e, a válasz egyszerűsítve igen vagy nem, az eredményről még az előtt tájékoztatod a felhasználót, mielőtt megnyomná a submitot
- folyamatos adatlekérés (például chat rendszerek esetében): folyamatosan kommunikálni kell a szerverrel, volt-e újabb adat, amit meg lehetne jeleníteni, és persze új adatokat meg is jeleníted
http://www.modernmethod.com/sajax/sajax-0.11/php/example_wall.php
- adatbeírás (például amikor egy szűrés eredményét táblázatba foglalod, és a táblázat elemein úgy módosítasz, hogy ne kelljen minden adatot elküldeni, hanem csak amit megváltoztattál): a felhasználó adatmódosítása után elküldöd az adatot a szerverre, ellenőrzöd, hogy volt-e joga írni, beírod az adatot, majd visszaadod azt. Itt tovább lehet bővíteni a dolgokat, mondjuk párhuzamos bevitel figyelése, ha megváltoztatta más az adatokat, akkor erről értesíted a felhasználót. (Ennek persze lehet egy egyszerűbb változata, amikor például egy rendelés fejlécét karbantartod.)
http://www.logitica.com/dynatab/dynatab.php
A fenti problémákra az utóbbi idő blogmarkjaiban lehetett példákat látni (a linkek is onnan vannak), csak mindegyikre külön-külön, és nem egységbe foglalva.
Ha ezeken a feladatokon kívül van még ötletetek, hogy milyen komminukációra kell felkészíteni egy keretrendszert, azt örömmel fogadjuk.
Az utóbbi időben eléggé előtérbe került az AJAX technika, ezért a keretrendszerbe foglalt megoldása foglalkoztat mostanság.
Elolvasva, tesztelgetve ezeket a megoldásokat, próbálunk egy keretet adni neki, ami több helyen is felhasználhatóvá tenné.
Megkülönböztettünk különböző feladatokat, amit a keretrendszernek meg kell oldania:
- adatellenőrzés (például regisztrációkor a kívánt azonosító foglalt-e már, vagy például a jelszó mérete, bonyolultsága megfelel-e az elvárásoknak): ha kilépsz a form elemből (onBlur indítja az eseményeket), egy xmlhttprequest segítségével megkérdezed a szervertől, hogy ez az adat megfelel-e, a válasz egyszerűsítve igen vagy nem, az eredményről még az előtt tájékoztatod a felhasználót, mielőtt megnyomná a submitot
- folyamatos adatlekérés (például chat rendszerek esetében): folyamatosan kommunikálni kell a szerverrel, volt-e újabb adat, amit meg lehetne jeleníteni, és persze új adatokat meg is jeleníted
http://www.modernmethod.com/sajax/sajax-0.11/php/example_wall.php
- adatbeírás (például amikor egy szűrés eredményét táblázatba foglalod, és a táblázat elemein úgy módosítasz, hogy ne kelljen minden adatot elküldeni, hanem csak amit megváltoztattál): a felhasználó adatmódosítása után elküldöd az adatot a szerverre, ellenőrzöd, hogy volt-e joga írni, beírod az adatot, majd visszaadod azt. Itt tovább lehet bővíteni a dolgokat, mondjuk párhuzamos bevitel figyelése, ha megváltoztatta más az adatokat, akkor erről értesíted a felhasználót. (Ennek persze lehet egy egyszerűbb változata, amikor például egy rendelés fejlécét karbantartod.)
http://www.logitica.com/dynatab/dynatab.php
A fenti problémákra az utóbbi idő blogmarkjaiban lehetett példákat látni (a linkek is onnan vannak), csak mindegyikre külön-külön, és nem egységbe foglalva.
Ha ezeken a feladatokon kívül van még ötletetek, hogy milyen komminukációra kell felkészíteni egy keretrendszert, azt örömmel fogadjuk.
