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

quote:

Op vrijdag 5 oktober 2012 21:39 schreef wipes66 het volgende:

[..]

dus globals maken de boel eerder dirty

Globals zijn evil. En dat is een understatement.

quote:

Op vrijdag 5 oktober 2012 22:15 schreef robin007bond het volgende:

[..]

http://popcornphp.com/

?

Mja, laatse versie: 0.6 beta. Klinkt niet echt alsof het volwassen is

quote:

Op vrijdag 5 oktober 2012 22:30 schreef Tijn het volgende:
Mja, laatse versie: 0.6 beta. Klinkt niet echt alsof het volwassen is

Een forum met 7 topics en 11 posts duidt ook niet echt op een levendige community.

quote:

Op vrijdag 5 oktober 2012 23:48 schreef Scorpie het volgende:
Licht is het wel.

Dat is onderstaand framework ook:

quote:

Op vrijdag 5 oktober 2012 20:30 schreef Farenji het volgende:

[..]

CodeIgniter vind ik meer een verzameling libraries dan een framework. Veel van de libs zijn nogal simplistisch, vaak niet meer dan wat convenience wrappers die soms maar weinig voordeel opleveren, zoals die gare "active record" class, die alleen maar extra complexiteit toevoegt zonder dat je er veel gemak voor terugkrijgt.

Wat voor complexiteit voegt active record toe?

In de praktijk komt het niet zo belachelijk veel voor, maar een simpele manier om database-interactie's te doen, ongeacht de database, is best praktisch. Een conversie van MySQL naar PostgreSQL is dan een eitje om maar wat te noemen.

quote:

Op zaterdag 6 oktober 2012 02:58 schreef Boze_Appel het volgende:

[..]

Wat voor complexiteit voegt active record toe?

Ik vind dit:


complexer dan gewoon kale sql:

In ieder geval makkelijker te tikken.
(het voorbeeld heb ik uit de documentatie, het is natuurlijk een debiele query)

Wat ik in active record ook heel erg mis is inter table relaties - die moet je alsnog helemaal zelf doen, incl de joins. In de modellen van cakephp worden die automatisch gelegd (hasOne, hasMany, belongsTo) aan de hand van je database schema en hoef je er bijna niet meer over na te denken. De benodigde joins worden onderwater gewoon gegenereerd en je kan de data van gerelateerde tabellen benaderen zonder extra moeite.

quote:

In de praktijk komt het niet zo belachelijk veel voor, maar een simpele manier om database-interactie's te doen, ongeacht de database, is best praktisch. Een conversie van MySQL naar PostgreSQL is dan een eitje om maar wat te noemen.

Daar heb je helemaal gelijk in. Dat is wat mij betreft ook de enige reden waarom je active record zou willen gebruiken.

Ik heb de volgende code op een pagina staan waar boven deze code nog meer code staat, maar eronder niets meer:

De UPDATE regel wordt niet uitgevoerd in die code. Zodra ik die regel boven de regel plaats waar het SQL-resultaat gefetched wordt werkt het wel. Als ik deze code in een nieuw php-document plaats met geen andere code, werkt ie wel. De code zelf lijkt dus wel goed te zijn. Maar waarom werkt ie niet als ik die regel onder de fetch plaats op die pagina? Ik snap er echt geen zak van waarom het niet werkt. In elke andere situatie die ik heb kunnen bedenken UPDATE ie de cel gewoon, BEHALVE op die ene pagina als ik de UPDATE regel daar onder de fetch plaats. Heeft iemand enig idee waardoor dit kan?
Ik heb de rest van de code op de pagina niet genoemd omdat ik niet denk dat daar het probleem in zit. Dit denk ik omdat de UPDATE query wél gewoon werkt als ik die boven de fetch plaats. Heeft iemand énig idee? Ik ben hier al dagen mee bezig, heb van alles geprobeerd maar het wil verdomme maar niet werken..

Plaats je dan de update query buiten de if boven de code? Wat krijg je terug als je $move echo't?

Ik dacht eerst ook dat het daaraan lag, maar als ik de UPDATE query slechts boven de IF plaats dan werkt het nog steeds niet. Ik moet de query echt boven de fetch plaatsen om het te laten werken. $move geeft de daadwerkelijke waarde (A3) gewoon terug, dus dat klopt ook gewoon..

Je kunt die IF ook als een WHERE in het UPDATE-statement verwerken:


Dan kun je die fetch en de IF gewoon weglaten.

quote:

Op zaterdag 6 oktober 2012 18:06 schreef Arcee het volgende:
Je kunt die IF ook als een WHERE in het UPDATE-statement verwerken:
[ code verwijderd ]

Dan kun je die fetch en de IF gewoon weglaten.

en heb je gelijk ondersteuning voor concurrency

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

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?

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.