DIG Digital Corner
Alles wat je altijd al over computers, hardware, software, internet en elektronische gadgets had willen weten, maar niet op Tweakers.net durft te vragen.
Je quote de halve zin, maar ook een notice bij een niet gedefinieerde variabele is echt een oplossing van niets. Of je geeft een exception / error of niet. Nu heb je dus afhankelijk van het niveau van error_reporting onverwachte bij-effecten. Het feit dat je dan weer met een @ operator die notice moet gaan onderdrukken maakt het nog erger.quote:
Het is zoals ik al aangaf het gevolg van het feit dat PHP van scripttaaltje met een brakke globale scope is geėvolueerd tot iets wat op een volwaardige OO taal moet lijken, maar dat neemt niet weg dat het nou niet bepaald een wenselijke oplossing is.
Volkorenbrood: "Geen quotes meer in jullie sigs gaarne."
Natuurlijk heb je helemaal gelijk dat PHP geen doordacht design heeft en in de loop der jaren enorm uit de kluiten is gegroeid, zonder dat dat aanvankelijk voorzien was. Maar ik vind niet dat er wat betreft ongedefinieerde variabelen nou echt zoveel mis is.
Je zegt het zelf al: geef als taal een error of niet. Nou, in het geval van PHP is het antwoord duidelijk: het gebruik van een ongedefinieerde variabele is geen enkel probleem. Dat je er een notice over krijgt, is een poging van PHP om hun gebruikers een beetje op te voeden, dat is alles. Maar daar heeft toch niemand last van verder?
Je zegt het zelf al: geef als taal een error of niet. Nou, in het geval van PHP is het antwoord duidelijk: het gebruik van een ongedefinieerde variabele is geen enkel probleem. Dat je er een notice over krijgt, is een poging van PHP om hun gebruikers een beetje op te voeden, dat is alles. Maar daar heeft toch niemand last van verder?
Van notices hebben mensen wel degelijk last. Zoals ik zeg is dat een bij-effect. Zeker wanneer mensen de code gebruiken in HTML, kunnen de gebruikers het te zien krijgen, wat doorgaans niet wenselijk is. Wanneer je met gecompileerde talen werkt zijn warnings / notices niet zo'n probleem. Prima te hanteren wanneer er bijvoorbeeld deprecated zaken worden gehanteerd. Runtime allerhande notices gaan uitspugen is nooit wenselijk.quote:Op woensdag 18 maart 2015 14:58 schreef Tijn het volgende:
Natuurlijk heb je helemaal gelijk dat PHP geen doordacht design heeft en in de loop der jaren enorm uit de kluiten is gegroeid, zonder dat dat aanvankelijk voorzien was. Maar ik vind niet dat er wat betreft ongedefinieerde variabelen nou echt zoveel mis is.
Je zegt het zelf al: geef als taal een error of niet. Nou, in het geval van PHP is het antwoord duidelijk: het gebruik van een ongedefinieerde variabele is geen enkel probleem. Dat je er een notice over krijgt, is een poging van PHP om hun gebruikers een beetje op te voeden, dat is alles. Maar daar heeft toch niemand last van verder?
Volkorenbrood: "Geen quotes meer in jullie sigs gaarne."
Gebruikers kunnen het alleen te zien krijgen als je display_errors aan hebt staan, wat je sowieso niet moet doen in een productieomgeving. Standaard is PHP niet zo geconfigureerd dat errors (laat staan notices) worden weergegeven, die worden alleen gelogd.
Mooi die discussie met extra informatie die dan naar boven komt drijven. Vaak veel waardevoller dan stackoverflow.
Php heeft dus gewoon een $var autoloader nodig
Het ging hier trouwens om een $_GET return dus ik zet de return waarde wel naar false als deze niet bestaat (want dat zou moeten werken)
Php heeft dus gewoon een $var autoloader nodig
Het ging hier trouwens om een $_GET return dus ik zet de return waarde wel naar false als deze niet bestaat (want dat zou moeten werken)
“Specialization is for insects”.—Robert Heinlein
Andere vraag qua design: Ik heb een database met alleen content, ik wil bij het openen van een pagina alle _GET['key']'s vergelijken met alle tables’ in die database.
tables: 'page', 'item', 'section', deze zet ik in een array ($table). Ik loop over de array en zeg dan
'data' is een class die alle content van de table in een array zet. Wat ik dan heb is een soort table autoloader: kijk of de table relevant is voor deze pagina, table wordt geladen. Is het verstandig om hele tabellen virtueel in php te gooien? Het aantal records blijft erg minimaal. Dan heb ik dus automatisch per table een nieuwe instance van m'n data class waarin ik dan weer take, trim, get, when, unless, etc... methods in kan zetten.
Bijvoorbeeld:
[ Bericht 25% gewijzigd door n8n op 19-03-2015 10:06:16 ]
tables: 'page', 'item', 'section', deze zet ik in een array ($table). Ik loop over de array en zeg dan
| 1 2 3 | <?php ( isset($_GET[$table[$i]) ? $$table[$i] = new data($table[$i]) : false ); ?> |
'data' is een class die alle content van de table in een array zet. Wat ik dan heb is een soort table autoloader: kijk of de table relevant is voor deze pagina, table wordt geladen. Is het verstandig om hele tabellen virtueel in php te gooien? Het aantal records blijft erg minimaal. Dan heb ik dus automatisch per table een nieuwe instance van m'n data class waarin ik dan weer take, trim, get, when, unless, etc... methods in kan zetten.
Bijvoorbeeld:
| 1 2 3 | <?php $page->when('published')->take(-4); // laatste 4 gepubliceerde items van deze pagina ?> |
[ Bericht 25% gewijzigd door n8n op 19-03-2015 10:06:16 ]
“Specialization is for insects”.—Robert Heinlein
Dat kun je toch veel beter in je query afhandelen? Dit lijkt me performance-wise niet bepaald optimaal. En als je tabellen wat groter worden ga je geheid uit je geheugen limiet lopen.
Ik kijk eerst of de table-name (mogelijk met een hard-coded/cached array) een match heeft met de url, als dat waar ik is pak ik de tabel met een query en hang deze aan een nieuwe instance van mn data class. de waarde van de get-key gebruik ik om de query te limiteren voor wat relevant is aan die pagina.quote:Op donderdag 19 maart 2015 10:36 schreef KomtTijd... het volgende:
Dat kun je toch veel beter in je query afhandelen? Dit lijkt me performance-wise niet bepaald optimaal. En als je tabellen wat groter worden ga je geheid uit je geheugen limiet lopen.
dus /?page=home wordt dan iets als: select * from 'page' where key 'home'. Dat valt toch wel mee?
Op die pagina heb ik dan automatisch een $page class waar alle data in staat die ik in de template dan weer kan benaderen/uitspugen met methods: $page->html('title'); // extract and parse title for this page
Heb dat afgekeken van http://getkirby.com, de site wordt ook niet groot (en gaat ook niet bijster veel groeien).
“Specialization is for insects”.—Robert Heinlein
Dat bewijst zonder dat ik weet wat dat is, de noodzaak voor een ORMquote:
Je bent dus min of meer je eigen ORM aan het uitvinden? Daar is op zich niets mis mee nee.
Injecteren? Er gaat niks via deze weg 'omhoog', de data die losgetrokken kan worden is al openbaar. Verder nog hiaten waar ik geen idee van heb? Weet alleen dat ik PDO moet gebruiken en ALLES moet valideren wat omhoog gaat.
“Specialization is for insects”.—Robert Heinlein
Natuurlijk, maar lijkt me relevant dat hij daar even rekening mee houdt.quote:Op donderdag 19 maart 2015 10:56 schreef KomtTijd... het volgende:
[..]
riep daar iemand prepared statements?
Volkorenbrood: "Geen quotes meer in jullie sigs gaarne."
SQL injectie kan met iedere query waar user input in staat. Ook met select queries. Daarom nooit user input direct in je query verwerken.quote:Op donderdag 19 maart 2015 10:57 schreef n8n het volgende:
[..]
Dat bewijst zonder dat ik weet wat dat is, de noodzaak voor een ORM
Injecteren? Er gaat niks via deze weg 'omhoog', de data die losgetrokken kan worden is al openbaar. Verder nog hiaten waar ik geen idee van heb? Weet alleen dat ik PDO moet gebruiken en ALLES moet valideren wat omhoog gaat.
En kijk ook eens naar bestaande ORM libs, zoals doctrine of redbean.
user input zoals een get varible zoals /?page=malafide-code. Dat vang je af met pdo/prepared statements?quote:
[..]
SQL injectie kan met iedere query waar user input in staat. Ook met select queries. Daarom nooit user input direct in je query verwerken.
En kijk ook eens naar bestaande ORM libs, zoals doctrine of redbean.
Nu ik weet wat/dat een orm is zal ik even naar best practice voorbeelden kijken ja. Jammere vind ik wel altijd dat voorbeelden vaak enorm de diepte in gaan met alle mogelijke randvoorwaarden terwijl ik het juist basic wil houden (al is veiligheid uiteraard basic)
“Specialization is for insects”.—Robert Heinlein
Klopt. Enige punt is dat je in jouw geval moet uitkijken voor /?malafide-code=waarde aangezien je ook min of meer dynamische tabelnamen wilt hebben op basis van de naam van request parameters. Gelukkig gebruik je de tabel en niet de request parameter daarvoor, dus dat moet goed gaan, maar het is wel iets waar je mee moet uitkijken. Helemaal omdat tabelnamen niet middels prepared statements in een query kunnen worden gestopt, dus daar ben je zelf verantwoordelijk voor het voorkomen van SQL injection.quote:
[..]
user input zoals een get varible zoals /?page=malafide-code. Dat vang je af met pdo/prepared statements?
Volkorenbrood: "Geen quotes meer in jullie sigs gaarne."
de table names zet ik in een var:quote:Op donderdag 19 maart 2015 11:32 schreef Monolith het volgende:
[..]
Klopt. Enige punt is dat je in jouw geval moet uitkijken voor /?malafide-code=waarde aangezien je ook min of meer dynamische tabelnamen wilt hebben op basis van de naam van request parameters. Gelukkig gebruik je de tabel en niet de request parameter daarvoor, dus dat moet goed gaan, maar het is wel iets waar je mee moet uitkijken. Helemaal omdat tabelnamen niet middels prepared statements in een query kunnen worden gestopt, dus daar ben je zelf verantwoordelijk voor het voorkomen van SQL injection.
| 1 2 3 4 | <?php $tables = "show tables from $db"; //of $tables = ['table1', 'table2']; ?> |
[ Bericht 12% gewijzigd door n8n op 19-03-2015 11:53:19 ]
“Specialization is for insects”.—Robert Heinlein
Code op 40 manieren gerefactored voordat ik bedacht dat je in php de global scope moet definiėren. Aaaaarggh 
“Specialization is for insects”.—Robert Heinlein
Ow perlquote:
[..]
Veel korter dan een ternary operator krijg je een if-then-else statement niet. 'this-when-true' slaat ook niet ergens op. Wat je eigenlijk wilt is een 'default-if-null'-constructie.
Als je dat echt kort wilt, dan maak je er toch gewoon een functie van, zodat je $var = defaultIfNotSet(originalValue, defaultValue) kan hanteren?
| 1 2 3 4 | $foo //= "bar" ; # is hetzelfde als $foo = defined $foo ? $foo : "bar" ; |
In theory there is no difference between theory and practice. In practice there is.
quote:
Al waardeer ik php een stuk beter nu ik redelijk met classes weet om te gaan. Next up: een pdo mysql controller en een simpele autoloader.
“Specialization is for insects”.—Robert Heinlein
quote:
[..]
Veel korter dan een ternary operator krijg je een if-then-else statement niet. 'this-when-true' slaat ook niet ergens op. Wat je eigenlijk wilt is een 'default-if-null'-constructie.
Als je dat echt kort wilt, dan maak je er toch gewoon een functie van, zodat je $var = defaultIfNotSet(originalValue, defaultValue) kan hanteren?
In php 7| 1 | $eenVariabele = $dezeWaardeAlsHijBestaat ?? $andersDit; |
Je kan PHP 7 al uitproberen dan? De meest recente versie die gebruikt kan worden, is bij ons nog steeds PHP 5.6quote:
Op
Dat hoeft toch niet perse? Specs kunnen al lang voor enige release bekend zijn. Maar volgens mij wordt er al best lang gesleuteld aan php7 dus je kunt vast wel ergens een dev build vandaan halen als je zou willen.quote:
[..]
Je kan PHP 7 al uitproberen dan? De meest recente versie die gebruikt kan worden, is bij ons nog steeds PHP 5.6
Yep, maar ik ga wel vanuit dat TwenteFC niet daar al mee loopt te klooien. Want dat PHP 7 is nog vrij buggy en vooral voorbehouden aan ontwikkelaars die contributies doen aan de PHP community.
