Citaat

mijn fout, ben net wakker vandaar...

Al was je al een week wakker, denk niet dat dat enige invloed heeft als je het gewoon niet begrijpt. Je zit constant gewoon een regel code klakkeloos te kopiëren en geeft ons dan het resultaat. Ik en zeker ook andere CP leden staan er best voor open je te helpen, maar dan moet je zelf wel wat meer initiatief tonen.

[func]mysql_fetch_assoc[/func] retourneert een array, en deze kun je niet zomaar naar het scherm schrijven. Je zou de goede waarde uit de array moeten pakken met de volgende syntax:

<?php


echo $array['key'];


?>

Om er achter te komen wat de key is die je moet gebruiken, kun je met [func]var_dump[/func] de inhoud van de array bekijken.

Voor de rest: Kauw het nu alsjeblieft niet voor...

Je kunt deze berekening ook gewoon gelijk door MySQL laten uitvoeren, dat is sneller en logischer:

http://dev.mysql.com/doc/refman/5.0…ml#function_avg

Patrick:

Citaat

A select_expr can be given an alias using AS alias_name. The alias is used as the expression's column name and can be used in GROUP BY, ORDER BY, or HAVING clauses. For example:

PHP

SELECT CONCAT(last_name,', ',first_name) AS full_name
  FROM mytable ORDER BY full_name;

http://dev.mysql.com/doc/refman/5.0/en/select.html

Jackie: De query was niets mis mee. Het ligt gewoon aan de limit van een BIGINT veld.

Het datatype van een kolom kun je wijzigen met ALTER TABLE:

ALTER TABLE <tabelnaam> CHANGE <kolomnaam> <kolomnaam> BIGINT UNSIGNED

Je laatste error komt doordat Lars de backtics uit je query heeft gehaald. Opzich niets mis mee, echter door de rechte haken in de tabelnaam is de tabelnaam eigenlijk niet valide, en werkt de qeury dus ook niet.

Voor meer informatie over mijn oplossing zie trouwens:
http://dev.mysql.com/doc/refman/5.0/en/numeric-types.html

Dit komt doordat 9.223.381.903.771.219.968 de maximale waarde is van een signed integer van 64 bit lang. Dit is dus de maximale waarde van een SIGNED BIGINT in een (MySQL) database. Je kunt deze waarde nog verdubbelen door van je velden UNSIGNED BIGINT's te maken, hierdoor wordt de maximale waarde 18446744073709551616 (2^64).

Zend ben ik persoonlijk ook echt geen fan van. Zoals al wordt gezegd is het een gigantisch framework, een een standaard installatie is dan ook gruwelijk sloom.

Code Igniter was in de tijd dat ik me nog in PHP frameworks verdiepte zwaar verouderd. Volgens mij heeft Code Igniter inmiddels wel de overstap gemaakt naar PHP 5, dus dat zou een hele verbetering maken.

Kohana heb ik een tijdje mee gewerkt, en moet zeggen: Prettig framework om mee te werken. Denk wel een framework wat meer is voor de mensen die graag doorhebben wat er gebeurd, en geen angst hebben om eens het belangrijkste regeltje code van het framework naar wens aan te passen.

CakePHP heb ik mensen lovend over horen praten. Een cookbook en bakery is natuurlijk ook wel vet!

Yii klinkt ook als een serieuze kandidaat. Volgens mij is dit framework nog niet zo lang op de markt, maar ziet er veel belovend uit.
http://www.yiiframework.com/

Lijkt erop dat mijn reactie niet helemaal goed ontvangen is...

Iets proberen te leren is goed, maar een goede programmeur wordt je nooit als je je niet afvraagt waarom je eigenlijk iets wilt. Ik kan je best uitleggen hoe je met een if-structuurtje alles bij elkaar in kunt plakken, dat is zo spannend niet. Veel interessanter is het om een goede architectuur in je code je hebben. Het idee achter deze wijzigingen van jou is een verbeterde architectuur, dan mag ik toch aangeven dat ik denk dat het geen goed idee is?

Waarom wil je dit? Het is toch echt niet overzichtelijker om één bestand te hebben van 300 regels dan drie van 100 regels?

Of zie ik hier nu iets over het hoofd?

Citaat

Ook vind ik de globals zeer lelijk gebruik hiervoor dan ook de defines.

Zou je kunnen toelichten wat je hier mee bedoeld? Ik snap je niet helemaal.

Citaat

Je kan trouwens ook te veel commentaar geven maar ook te weinig, ik zie dat je bij de functions in dit geval helemaal geen commentaar geeft en bij variabelen weer te veel.
Misschien kan je dit ook korter en simpeler houden?

Eens. Een goed stuk script moet eigenlijk zelfs zo duidelijk zijn dat commentaar overbodig is. Een script waar je doorheen bladert met het idee:

Hmm.. Ja.. Duidelijk.. Hmm.. Duidelijk.. Ahh, saai...

Als het zo duidelijk is dat het niet meer interessant is om door te lezen, dan doe je het goed! :p

Niet alles wat hier wordt gezegd is waar.

Er bestaan verschillende databases, zoals MySQL, PostGreSQL, Oracle en MSSQL, al deze databases zijn relationele databases. Met deze databases kan worden gecommuniceerd via SQL, de databases voldoen ongeveer (eigenlijk nooit helemaal) aan de SQL standaard (http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt).

De database is de eerste laag, en de laag die hier bovenop komt is dus SQL. Om deze SQL naar de database te sturen komt er nog een laag bij bovenop. Dit is de interessante laag: Hier kan worden gekozen tussen mysql_*, MySQLi en PDO.

mysql_* is een library die lang is gebruikt binnen PHP om met een MySQL database te communiceren. Echter, deze library is verouderd, en zijn opvolger is MySQLi.

MySQLi is dus op zichzelf GEEN database. Maar netzoals mysql_* een manier om met een MySQL database te communiceren. Nieuwe functies van MySQL worden wel door MySQLi ondersteund maar niet door mysql_*.

PDO is een library die ook met databases kan communiceren. Echter, PDO kan met veel meer databases communiceren zolang er een PDO driver voor die database is geïnstalleerd op de server waar jou PHP scripts op draaien. Dit is ook meteen het voordeel van PDO: Het houdt het simpel om van database te verwisselen.

L.Groot: PDO is inderdaad alleen beschikbaar in een OO versie. MySQL(i) kent zowel procedurele functions al een OO interface.

Echter, PDO kan dus nooit MySQLi ondersteunen. MySQLi is een extension in PHP om een database mee te benaderen netzoals PDO, en PDO kan enkel verschillende databases ondersteunen.

Gebruiker die deze berichten verzond is verbannen. Wil even benadrukken dat het niet de bedoeling is dat hier topics over worden gemaakt. Ook PB berichten kun je reporten.

Citaat van Shaggie

cron second bestaat niet

Hoezo zou zoiets niet kunnen bestaan? Als je een programmaatje schrijft dat iedere seconde een scriptje aanroept heb je een 'cron second'. Echter, functioneel is het niet te noemen.

@iSilverStar: Volgens jou is dat veiliger? Ten eerste zat er in het script van Lars geen beveiligingsfout, en daarnaast heeft niemand wat aan jou volgens mij. Geef aan waarom je dat denkt, dan kunnen we er iets mee.

Wat betreft de constante heb je me verkeerd begrepen. Constante gebruik je als waarden voor een variabele. De waarde van een constante is daarmee ook bijna altijd een integer, dat werkt het makkelijkst. Deze constante gebruik je vervolgens om de variabele tegen te vergelijken of een waarde toe te kennen.

Voorbeeld wat op jouw script staat is bijvoorbeeld de left, center en right mogelijkheid voor de uitlijning van de tekst.

<?php


define("ALIGN_CENTER", 1);
define("ALIGN_RIGHT", 2);
define("ALIGN_LEFT", 3);


$alignment = ALIGN_CENTER;


if($alignment == ALIGN_LEFT) {
  ...
} else if($alignment == ALIGN_RIGHT) {
  ...
} else {
  ...
}


?>

Constante worden overigens altijd geheel in HOOFDLETTERS geschreven. Zo is het meteen duidelijk dat het om een constante gaat.

Hopelijk is het duidelijk wat ik hiermee bedoel.

Crons zijn bedoeld voor taken die in een bepaalde tijds structuur moeten worden uitgevoerd, niet voor dit soort taken.

Eigenlijk heb ik twee vragen:
- Wanneer wordt de rankvordering verhoogd?
- Wanneer is het van belang dat de rank geupdate is?

Mooi dat mijn bijdrage nuttig is geweest!

Nog enkele tips:
1. Zet de functies onderaan het script. Goede functies hebben een duidelijke naam en parameterlijst, waardoor je niet meer hoeft te lezen wat ze doen om te weten wat ze doen. En aangezien we van boven naar beneden lezen, is het dan praktischer ze onderaan neer te zetten.
2. Maak geen functies met parameterlijsten van meer dan 3 tot 4 parameters tenzij het echt nodig is. Zulke grote parameterlijsten maken de functie onduidelijk, zie tip 1.
3. Zorg dat functies slechts één ding doen, en dat de naam van de functie dat zo goed mogelijk beschrijft. De tijd van functienamen van maximaal 16 tekens is allang voorbij. Zie wederom tip 1.
4. Vermijd strings voor instelling. Hiervoor zijn constante uitgevonden.
5. Als je het echt goed wilt doen, ga OOP!

Hopelijk heb je hier nog iets aan.

Nieuwe reactie samengevoegd met originele reactie op 30.12.10 17:22:40:
Ps. Ik zal het script in de library zetten, maar wacht dit topic nog even af.

Ik heb voor jou laatste wijziging ook in je script gewijzigd. Maar samen komen we wel tot een perfecte versie! Dit is mijn huidige versie:

<?php


$image_height = 200;
$image_width = 200;
$border_size = 20;


$procent = (isset($_GET['procent'])) ? round($_GET['procent'], 2) : 0;


if($procent >= 0 && $procent <= 100){
    // Maak de afbeelding
	$afbeelding = imagecreate($image_width, $image_height);


    // Definiër de kleuren
    $achtergrond = imagecolorallocate($afbeelding, 0, 125, 0);
    $voorkantkleur = imagecolorallocate($afbeelding, 0, 255, 0);
    $tekstkleur = imagecolorallocate($afbeelding, 0, 0, 0);
    $grootte = round($procent/100 * ($image_width - $border_size));


    // Teken het vierkant op basis van de gegeven procenten
    imagefilledrectangle($afbeelding, $border_size, $border_size, $grootte + $border_size, $image_height - $border_size, $voorkantkleur);


	// Voeg de tekst toe aan de afbeelding
	imageStringCentered($afbeelding, $procent . ' %', $tekstkleur);


    // Schrijf het bestand naar de browser
    header('Content-Type: image/png');
    imagepng($afbeelding);
    imagedestroy($afbeelding);


} else {
    echo '<font face="arial">Roep deze pagina zo aan: <a href="gd.php?procent=25">gd.php?procent=25</a> waar procent=25 staat tot 25%.</a>Het getal moet tussen de 0 en 100 liggen.';
}


function imageStringCentered($image, $string, $color) {
	$padding_left = (imagesx($image) - 8 * strlen($string)) / 2;
	$padding_top = (imagesy($image) - 16) / 2;
    imagestring($image, 4, $padding_left, $padding_top, $string, $color);
}


?>

Wat ik heb gedaan:
- Het cijfers met decimalen probleem opgelost, zoals jij dus achteraf ook al had gedaan.
- Een aantal variabele geïntroduceerd. Deze maken het mogelijk makkelijk het script aan te passen zonder eerst te moeten zoeken hoe dat te doen. Daarnaast lossen ze het probleem op van 'magic numbers', die je eigenlijk altijd moet voorkomen.
- Een function geïntroduceerd, zodoende blijft het script leesbaarder, en daarnaast is de functie ook los goed bruikbaar.
- Voorkomen dat het niet opgeven van $_GET['procent'] problemen oplevert.

Dingen die discutabel zijn:
- Het script is in het Nederlands geschreven, ik ben van mening dat je altijd in het Engels moet programmeren.
- De if-else constructie zal in productie doelloos zijn.

Ik hoor graag wat je van deze versie vind.

Inderdaad een leuk scriptje. Maar voordat ik hem aan de library toevoeg: Waarom mag dit wel:

http://grootscripting.nl/gd.php?procent=100.9

En mag dit niet?:

http://grootscripting.nl/gd.php?procent=0

Je kunt dit doen met PHP, maar dat wil ik je niet aanraden.

Wanneer je dit doet met PHP moet je webserver alle images inladen (via HTTP, als ze extern staan), en daarna resizen. Dit kost veel tijd, en je pagina's zullen sloom gaan laden.

Een andere mogelijkheid is de afbeeldingen laten resizen door JavaScript. De afbeeldingen worden toch ingeladen door de browser, en met javascript zou je ze dan kunnen resizen.

Citaat van Tsk

mysqli is beter

Ik ben erg onder de indruk van je onderbouwing...

Er zijn eigenlijk twee belangrijke verschillen tussen MySQLi en PDO. Ten eerste is het met MySQLi mogelijk procedureel te werken in plaats van object georiënteerd. Normaal gesproken wil je hier geen gebruik van maken (tenslotte gooi je dan alleen maar voordelen weg), maar het is wel een feature.

Het belangrijkste verschil zit hem in de ondersteuning van databases. MySQLi is een extension die geschreven is voor alleen de mysql-database. PDO daarin tegen is een extension die meerdere database (drivers) ondersteund. Wanneer je applicatie dus is gebouwd met PDO en je gebruikt een MySQL database, kun je die database makkelijk emigreren naar een PostGreSQL database, mits je geen MySQL specifieke functies gebruikt.

Samengevat: Wanneer je een applicatie schrijft die altijd gebruik zal maken en blijven maken van MySQL zal ik kiezen voor de MySQLi extension, wanneer je de mogelijkheid om van database te switchen open wilt laten zal ik zeker gaan voor de PDO extension.