[PHP/(My)SQL] voor dummies #104 Waar veiligheid > alles

quote:

Op zaterdag 6 oktober 2012 20:40 schreef Devolution het volgende:
Nee helaas niet, omdat hij in die IF ook nog wat HTML output via een echo. Dit is voor dit probleem echter niet relevant en daarom heb ik dit niet in de code staan

Je kunt ook eerst de update doen, dan controleren hoeveel rijen er aangepast zijn (met mysql_num_rows()) en op basis daarvan je IF doen.

Nee kan ook niet, want hij moet de waarde eerst naar de browser outputten en daarna pas de waarde updaten

De waarde in de cel staat voor een aanval die een vechtpoppetje doet. Zodra dit poppetje de aanval doet moet hiervan een melding op het scherm van de speler komen en vervolgens wordt deze aanval uit de cel verwijderd (leeggemaakt).

quote:

Op woensdag 3 oktober 2012 14:17 schreef Tijn het volgende:

[..]

Ik zat vanochtend nog bij een klant voor een nieuw project die me expliciet vroeg om het niet "te object-georiënteerd" op te zetten

Maar goed, dat komt waarschijnlijk omdat 'ie het zelf ook niet zo goed begrijpt denk ik. Ik zie eigenlijk geen reden om niet gewoon met controllers en models te werken.

Of hij begreep het heel goed en was bang voor overengineering of het second-system effect. Het wordt tijd dat de pragmatiek weer breder gedragen gaat worden in het developmentwezen.

Programming Motherfucker, Do you speak it? :-)

quote:

Op zondag 7 oktober 2012 11:08 schreef rekenwonder het volgende:

[..]

Of hij begreep het heel goed en was bang voor overengineering of het second-system effect.

Het wordt tijd dat de pragmatiek breder gedragen gaat worden in het developmentwezen.

Programming Motherfucker.com, Do you speak it? :-)

Mja, de vrij strakke deadline dwingt sowieso al een bepaalde pragmatiek af

quote:

Op zaterdag 6 oktober 2012 17:11 schreef Devolution het volgende:
Ik heb de rest van de code op de pagina niet genoemd omdat ik niet denk dat daar het probleem in zit.

Misschien dat je daar toch een stukje van kunt posten? Je zegt dat de code zoals je die postte in een nieuw document gewoon werkt, dus wellicht ligt het toch aan de overige code.

Ik heb het eindelijk opgelost. Het had te maken met een AJAX call in de code (die werd aangeroepen via een javascriptcode die weer via een echo geplaatst werd in die IF hierboven) die de bewuste cel aanpaste nadat de update de cel leeggemaakt had. De update werkte dus wel maar daarna veranderde de AJAX call doodleuk de waarde weer in de oude

Ik ben erachter gekomen door de javascriptcode weg te halen, waardoor de pagina het perfect deed. Toen wist ik dus dat het daaraan moest liggen en heb ik de complete javascriptcode (en de resulterende AJAX-call) vervolgens regel voor regel nagelopen en kwam ik achter de fout.

Ik heb hiervoor nog nooit met AJAX calls gewerkt dus vandaar dat ik deze stomme fout gemaakt had haha Maar het werkt nu weer

Enlighten me?

Foutcontrole op de fetch is niet nodig omdat de cellen uit de query altijd bestaan.
Er zijn niet 2 spelernamen in 1 tabel, zie onder*.
Als laatste stonden er quotes omdat daar normaal een php string staat, maar voor testdoeleinden had ik daar even een 1 van gemaakt.

* Elk gevecht krijgt een eigen rij. In die rij staan onder andere de columns movespeler1 en movespeler2. Deze geven aan welke aanval elke speler heeft gekozen in datzelfde gevecht en deze worden geleegd zodra beide spelers deze aanval gezien hebben als animatie. Het is dus niet nodig om deze in aparte tabellen te zetten omdat het slechts de acties weergeeft binnen 1 gevecht.

Ik zit met een denk spelletje in mijn hoofd, zelf probeer ik steeds meer richting jquery en ajax op te denken. Al lukt het niet altijd even goed, maar nu vraag ik me af. ik heb een tabel met X aantal rijen. elke rij wou ik inline kunnen aanpassen (call back richting database). Zodat als een waarde verandert de goede rij aangepast wordt.

Ik zat nu aan 2 varianten te denken,

1. met een save knop aan het einde van de rij. (hoe hij weet dat hij de Rij daarvoor moet hebben weet ik nog niet ) . Tig <form> op een pagina maken leek me niet praktisch en was net een beetje semi ajax idee.

2. onchange javascript dat als een verandering op het input veld is er een javascript activeert, die de resultaten post richitng de server. Dit lijkt me alleen zwaar te zijn, (kan het mis hebben). elke aanpassing een aparte query verstuurd , geen idee in wat voor orde query's gaan maar, mij is geleerd zo min mogelijk query's te gebruiken. kan het helemaal mis hebben.

Onchange() -> functie in jquery pakt de value van het huidige input veld. Stuurt de waarde per $.post in javascript door naar functie in php. en php stuurt het door richting SQL database.

Je bedoelt een "onkeyup"-event van zo'n input text zeker?
Ik zie het wel vaker gebeuren; met zoeksuggesties bijvoorbeeld.
Ja je vuurt dan wel met elke toetsaanslag een $.post() af, maar dat is toch niet zo zwaar?

Of pas na drie aanslagen fetchen, deze in cache opslaan en daar verder in filteren.

quote:

Op maandag 8 oktober 2012 19:42 schreef Scorpie het volgende:
Of pas na drie aanslagen fetchen, deze in cache opslaan en daar verder in filteren.

jij gaat voor de bullshitbingo?

Wie heeft er ervaring met Propel en verglijkbare ORM oplossingen in PHP. Is zoiets aan te raden om op te pakken voor wat hobbyprojectjes, of maak ik het me dan juist weer veels te moeilijk? En wat zou een tussenoplossing zijn? Het andere einde is nl. zelf e.a. aan classes schrijven voor PDO/MySQL, dat voelt alleen een beetje als het wiel op nieuwe uitvinden. Ik doe dat al op mijn werk dus om dat thuis nog eens na te gaan doen is mij een beetje te gortig.

quote:

Op maandag 8 oktober 2012 20:04 schreef GlowMouse het volgende:

[..]

jij gaat voor de bullshitbingo?

Nee lekker alles in het Nederlands uitspreken, dat zet zoden aan de dijk

'Na 3 aanslaguh de resultaten ophaluh en dan lokaal bijhouduh en dan daarin gaan zoekuh'.

quote:

Op maandag 8 oktober 2012 20:12 schreef Scorpie het volgende:

[..]

Nee lekker alles in het Nederlands uitspreken, dat zet zoden aan de dijk

'Na 3 aanslaguh de resultaten ophaluh en dan lokaal bijhouduh en dan daarin gaan zoekuh'.

Je strooide met termen zonder specifiek aan te geven waar dat gebeurde. Fetchen is in php-land sowieso iets vreemds als je het over user-input hebt. Het was voor mij onbegrijpelijk wat je met je post bedoelde.

Heeft iemand hier ervaring met cURL? Ik heb een loginscript, maar ik krijg geen output. Waarschijnlijk heeft het te maken met een cookie.txt file waar naartoe geschreven moet kunnen worden. Ik weet alleen niet hoe.

quote:

Op maandag 8 oktober 2012 20:24 schreef GlowMouse het volgende:

[..]

Je strooide met termen zonder specifiek aan te geven waar dat gebeurde. Fetchen is in php-land sowieso iets vreemds als je het over user-input hebt. Het was voor mij onbegrijpelijk wat je met je post bedoelde.

Data fetchen is jou vreemd? De relatie met een input field kon je ook niet leggen? User-input is wel een normale term ? Dit soort termen worden dagelijks gebezigd zonder dat er iemand is die niet snapt waar het over gaat, zeker de gemiddelde devver weet precies wat dit inhoud. Daarnaast is de door mij geposte manier een beproefde methode voor een live search veld.

quote:

Op zondag 7 oktober 2012 18:50 schreef Devolution het volgende:
Foutcontrole op de fetch is niet nodig omdat de cellen uit de query altijd bestaan.

Dan nog kun je zonder foutafhandeling in de problemen komen. Bijvoorbeeld als de tabel wordt aangepast en je de code niet overal bijwerkt. Of als het id niet bestaat, of de verbinding met de database moeilijk doet. Als mysql_query (een functie die je eigenlijk niet meer moet gebruiken) geen resultaat oplevert, gaat mysql_fetch ook mis.

Over het algemeen vang ik functies altijd af, bijna alle functies kunnen false terug geven als er iets misgaat. Als je dat meteen afvangt kun je dat meteen vastleggen, ipv dat je telefoontjes van klanten krijgt over foreaches die misgaan wegens missende data etc. (en eigenlijk vind ik dat je altijd moet checken of je wel een array/object naar je foreach stuurt, of iedere andere functie die een bepaalde iets verwacht.) Dan moet je namelijk helemaal terug gaan kijken waar dat ook al weer was, ipv dat je die informatie al hebt. En daarnaast is het voor de gebruiker meestal prettiger een foutmelding te zien die zij kunnen begrijpen, ipv een of andere php foutmelding.

Het woord altijd vind ik zo gevaarlijk in de ICT, "ja maar dat zal nooit gebeuren", "dat komt niet voor", "daar hoeven we geen rekening mee te maken", "die input/output is altijd goed"

tegenwoordig leer je het tijdens je opleiding om overal rekening mee (proberen) te houden en (proberen) zo veel mogelijk op te vangen (ik toch )

quote:

Op maandag 8 oktober 2012 19:09 schreef cablegunmaster het volgende:
2. onchange javascript dat als een verandering op het input veld is er een javascript activeert, die de resultaten post richitng de server. Dit lijkt me alleen zwaar te zijn, (kan het mis hebben). elke aanpassing een aparte query verstuurd , geen idee in wat voor orde query's gaan maar, mij is geleerd zo min mogelijk query's te gebruiken. kan het helemaal mis hebben.

Onchange() -> functie in jquery pakt de value van het huidige input veld. Stuurt de waarde per $.post in javascript door naar functie in php. en php stuurt het door richting SQL database.

quote:

Op maandag 8 oktober 2012 19:42 schreef Scorpie het volgende:
Of pas na drie aanslagen fetchen, deze in cache opslaan en daar verder in filteren.

Ik doe zoiets meestal met een timeout, dus dit idee:
Dan stuurt hij max. elke 3 seconden iets naar je server.