En hoezo is dat dan wel niet 'veel beter'?

Dit is niet het juiste script. De pagina waarin dit script wordt aangeroepen door middel van een formulier is het script wat we moeten hebben om dit probleem op te kunnen lossen.

Leest niemand andermans reactie? Darsstar had het in het begin al goed met de volgende code:

if( ! empty( $telefoonnummer ) AND ! ctype_digit( $telefoonnummer ) ) {
    
        $error .= '- Je telefoonnummer mag alleen uit cijfers bestaan.'; 
    
    }

In pseudocode staat hier:

ALS het veld telefoonnummer niet leeg is EN het telefoonnummer niet uit alleen maar cijfers bestaat

FOUT

Dit voldoet perfect aan de eis van TS...

Dit kun je heel netjes afhandelen met .htaccess, lijkt me veel verstandiger dan met een lap PHP-code.

Je moet je deny en allow even omdraaien. Eerst deny, dan allow, dat moet het probleem oplossen!

Je kunt heel makkelijk valideren wat een formulier teruggeeft door middel van [func]var_dump[/func].

<?php


var_dump($_POST);


?>

Binnen PHP is het dollarteken een prefix voor een variabele. Alle variabelen beginnen dus met het dollarteken. Dit maakt het dan ook mogelijk om reserved keywords te gebruiken als variabele zoals '$while' en '$if'.

JavaScript kent deze prefix echter niet. In JavaScript hebben variabele geen prefix, en 'helloworld' kan dan ook een goede variabele naam zijn. Echter, het dollarteken mag wel voorkomen in de naam van een variabele binnen JavaScript. '$helloworld', 'hello$world' en zelfs '$' zijn dan ook geldige variabele namen.

jQuery maakt standaard gebruik van de variabele genaamd '$'. Daarom maak je bij jQuery vaak gebruik van het dollarteken. Echter, je kunt ook alle dollarteken vervangen met 'jQuery', wat een alias is op dezelfde variabele (ergens in de code van jQuery staat var $ = jQuery;).

Het vergeten of niet gebruiken van het keyword 'var' is in dit geval ook zeker niet het probleem, variabele mogen namelijk worden gedefinieerd zonder dit keyword.

Jannick: Ik denk dat de functie niet moet worden gekoppeld aan een event (van een HTML element), en niet aan een selector (ofwel HTML element of lijst van HTML elementen) zelf.

http://stackoverflow.com/questions/1661…-variable-names
http://www.w3schools.com/js/js_variables.asp

Een while-loop heeft als enige voordeel dat je code een beetje overzichtelijk blijft. Maar hoe dan ook, dit hoort in één query, anders is je database niet echt geoptimaliseerd...

Eén query en dan je data scheiden is veel sneller, iedere query die je aanroept in je PHP-code kost gewoon tijd, en data binnen PHP scheiden/verwerken is meestal zo snel dat de performance verwaarloosbaar is.

Persoonlijk zou ik dan eerder voor een object georienteerde aanpak als DOM kiezen:

http://www.php.net/manual/en/book.dom.php

Het is niet mogelijk met AJAX verbinding te maken met een externe host. Dit is vanwege security redenen, wat in principe erg logisch is.

Om dit op te lossen moet je vanaf de server (met bijvoorbeeld PHP) de externe host aanroepen, en de server weer aanroepen met AJAX.

Lijkt me geen verstandig plan. Query's uitvoeren in een while-loop is vragen om performance problemen. Mijn query al geprobeerd?

SELECT categorie, COUNT(*) FROM forum_reacties WHERE verwijderd = 1 GROUP BY categorie

De query moet er ongeveer zo uit komen te zien. Probeer hem maar eens, weet niet of hij geheel correct is, maar denk van wel.

In de resultset van deze query komen alle categorieën te staan met het aantal bijbehorende reacties, behalve de categorieën zonder reacties.

Er werd al eerder aangegeven dat dit ook met COUNT kan. De resultset die dan wordt teruggegeven is vele maler kleiner en je hoeft daarnaast in je code niet allerlei onduidelijke lussen te plaatsen.

SELECT COUNT(*) FROM `[users]` WHERE erepunten > EREPUNTEN_GEBRUIKER

Een XSS lek of SQL injection lek zal hiervan niet de oorzaak zijn. De oorzaak in inderdaad eenvoudig weg toegang zijn tot de server, hoe dan ook. Een andere mogelijkheid is een lek wat je de mogelijkheid bied om bijvoorbeeld PHP uit te voeren...

JOIN is maar een van de vele krachtige functionaliteiten van SQL. Belangrijk is dat er verschillende soorten JOIN's bestaan, wat het beste is toe te lichten aan de hand van een voorbeeld:

SELECT * FROM linker [JOIN] rechter ON linker.voorwaarde = rechter.voorwaarde

Als op de plek van [JOIN] staat:
- INNER JOIN: Join alle rijen van linker met alle rijen van rechter waarvoor linker.voorwaarde gelijk is aan rechter.voorwaarde.
- RIGHT OUTER JOIN: Selecteer alle rijen van rechter, en join deze waar mogelijk met linker. Wanneer er geen join wordt gevonden wordt het record uit rechter wel toegevoegd aan het eindresultaat, met NULL waarden voor de kolommen uit linker.
- LEFT OUTER JOIN: Selecteer alle rijen van linker, en join deze waar mogelijk met rechter. Wanneer er geen join wordt gevonden wordt het record uit linker wel toegevoegd aan het eindresultaat, met NULL waarden voor de kolommen uit rechter.

Citaat

Voor een nieuwe pagina moeten twee bestanden aangemaakt worden. Model en view. Één van deze kan een lege klasse bevatten. De ander moet twee functies hebben. Ééntje die alle functies aanroept en uitvoert en een output functie die naar de browser gaat.

Mocht je je aan het MVC-patroon willen houden klopt dit niet. Daarbij, je moet per pagina twee classes definiëren, waaronder de View? Waarom is de View een class?

Ik denk dat het belangrijk is dat je je framework flexibel houdt. Om dat te bereiken moet je in ieder geval een hoge abstractie aanhouden, en zorgen dat het gedrag van je framework aanpasbaar is (zoals ik goed geïmplementeerd vind ik Kohana).

Daarbij is een scheiding tussen weergave, configuratie, data (opslag) en logica naar mijn inzien het alle belangrijkste.

Op de regel waar het omgaat wordt een nieuw object geïnitialiseerd van het type Config. Als deze class niet kan worden gevonden zal het resulteren in een foutmelding.

Config is dus geen functie, en de spatie is ook geen probleem.

Het laatste script wat je poste creëert de class Config. Deze zal je dus moeten runnen. Wanneer je dit doet verschijnt er een formulier waarop je je gegevens moet invullen.

Waarom zou je dit niet gewoon netjes dynamisch berekenen?

<?php


$nodig = 150 + $huidig_level * 120;


?>

Een kleine opmerking: De quotes zijn in de array niet nodig, en het is zelfs beter om ze achterwegen te laten. Daarnaast zijn de dubbele quotes op regel twee ook overbodig, het zou me zelfs niet verbazen als deze ervoor zorgen dat de code niet meer correct werkt...

Het verschil tussen [func]mysql_fetch_object[/func], [func]mysql_fetch_assoc[/func], [func]mysql_fetch_array[/func] en [func]mysql_fetch_row[/func] is in snelheid zo gigantisch klein, dat je je daar totaal niet door moet laten beinvloeden. Er zijn niet voor niets meerdere functies geïntroduceerd, neem de beste voor jouw situatie.

Quotes van php.net:

Citaat

An important thing to note is that using mysql_fetch_assoc() is not significantly slower than using mysql_fetch_row(), while it provides a significant added value.

Citaat

An important thing to note is that using mysql_fetch_array() is not significantly slower than using mysql_fetch_row(), while it provides a significant added value.

Citaat

Speed-wise, the function is identical to mysql_fetch_array(), and almost as quick as mysql_fetch_row() (the difference is insignificant).

Citaat

mysql_fetch_object() is similar to mysql_fetch_array(), with one difference - an object is returned, instead of an array. Indirectly, that means that you can only access the data by the field names, and not by their offsets (numbers are illegal property names).

Object georiënteerd programmeren heeft niet zoveel te maken met de snelheid van je (web)applicatie. Ik las toevallig laatst nog een artikel over de slechte preformance van exceptions in Java. Maar ook al is object georiënteerde (PHP-)code minder snel: Een processor is een stuk goedkoper dan slecht onderhoudbare code onderhouden.

Darsstar: Een main methode schrijven met daarin alle code? Of gewoon alles static maken? :p Nee, je kunt altijd waardeloos programmeren, in welke taal je ook schrijft. Een main-methode komt overigens lang niet in iedere Java applicatie voor.

L.Groot: Wat is een hele class? Een wrapper kan zeker nuttig zijn namelijk.

Ik programmeer in Java en PHP eigenlijk altijd object georiënteerd. Als je 'echt' leert programmeren en kennis maakt met krachtige mogelijkheden die object georienteerd programmeren je biedt, zoals unittesting en dependency injection, zul je niet snel meer procedureel gaan programmeren. Procedurele code schrijf je voor scriptjes, niet voor applicaties.