Datum uit Database omzetten in Dagnaam

[Anoniem: 913409]

Goedenavond,

ik probeer een website in elkaar te zetten waar de personen een datum invoeren wanneer een ander een afspraak heeft. Dit invoeren lukt wel d.m.v. invoeren via een invoerformulier in de database die er als volgt uitziet.
Afbeelding database


De uitvoer van de opgevraagde gegevens uit deze database is als volgt:
Afbeelding Registratiekaart
Dit ziet er prima uit alleen 1 ding krijg ik niet gedaan. Dat de datum niet als datum weergeven wordt, maar als dagnaam. 01-01-2017 wordt uitgelezen als Zondag bijvoorbeeld.
Script voor de uitvoer is als volgt:

code:

<?php
      mysql_connect("localhost", "-------------", "---------------");
      mysql_select_db("-----------");

      $result = mysql_query("SELECT * FROM registratiekaart WHERE id = '" . $_GET['id'] . "'")
                                        or die(mysql_error());
    
     echo "<table>";
        while($data = mysql_fetch_assoc($result)) {
            echo "<tr>";
                     echo "<th colspan='8'> Paraafkaart werken in de studiewerkruimte </th>";
            echo "</tr>";
            echo "<tr>";
                     echo "<th colspan='8'>" . $data["voornaam"] . " " . $data["tussenvoegsel"] . " " . $data["achternaam"] . "</th>";
            echo "</tr>";
            echo "<tr>";
                     echo "<td> datum </td>";
                     echo "<td> lesuur </td>";
                     echo "<td> paraaf </td>";
                     echo "<td colspan='5'> opmerkingen </td>";
            echo "</tr>";
            echo "<tr>";
                     echo "<td>" . $data["datum1"] . "</td>";
                     echo "<td>" . $data["lesuur1"] . "</td>";
                     echo "<td> </td>";
                     echo "<td> </td>";
            echo "</tr>";
            echo "<tr>";
                     echo "<td>" . $data["datum2"] . "</td>";
                     echo "<td>" . $data["lesuur2"] . "</td>";
                     echo "<td> </td>";
                     echo "<td> </td>";
            echo "</tr>";
            echo "<tr>";
                     echo "<td>" . $data["datum3"] . "</td>";
                     echo "<td>" . $data["lesuur3"] . "</td>";
                     echo "<td> </td>";
                     echo "<td> </td>";
                     
            echo "</tr>";
            echo "<tr>";
                     echo "<td>" . $data["datum4"] . "</td>";
                     echo "<td>" . $data["lesuur4"] . "</td>";
                     echo "<td> </td>";
                     echo "<td> </td>";
            echo "</tr>";
            echo "<tr>";
                     echo "<td>" . $data["datum5"] . "</td>";
                     echo "<td>" . $data["lesuur5"] . "</td>";
                     echo "<td> </td>";
                     echo "<td> </td>";
            echo "</tr>";
        }
      echo "</table>";
     
?>

Mijn vraag is dus of iemand dit kan veranderen zodat de dagnaam weergeven wordt. Dank u alvast.
...

[Teknix1982]

Ik zou is zoeken op php date format.

[Creepy]

Of iemand je code kan veranderen? Zo werkt het hier net niet Misschien goed om het Algemeen beleid waarmee je zojuist akkoord bent gegaan nog even door te lezen, met name de quickstart.

Zowel PHP als MySQL hebben allebei functies om een datum om te kunnen zetten. Met een beetje google werk zou je die zelf wel moeten kunnen vinden lijkt me.

edit: oh. Teknix spoilt al een klein beetje zie ik.

[ Voor 18% gewijzigd door Creepy op 24-04-2017 20:09 ]

[Anoniem: 913409]

Ha, is niet de bedoeling dat iemand mijn script aanpast, wat ik wel typte inderdaad, maar wil graag wat tips. Als ik dit namelijk afrond dan heb ik mijn eindproject voldoende afgerond dus ben er druk mee bezig om dit gedaan te krijgen. Heb wat zitten kijken en heb nu dit:
Dit als echo weergeven:

code:

<?php
echo "<td>" . date_format($date["datum1"], 'Y-m-d '). "</td>";
?>

i.p.v.

code:

<?php
echo "<td>" . $data["datum1"] . "</td>";
?>

Nu wordt de datum helemaal niet weergeven. Is het gewoon een wit vlak. Dat is ook niet de bedoeling.

[ Voor 3% gewijzigd door Anoniem: 913409 op 24-04-2017 21:05 ]

[sypie]

Zet je code even tussen Code tags:

[code ] code [ /code ]

(maar dan zonder de spaties er in)

[ Voor 20% gewijzigd door sypie op 24-04-2017 21:02 ]

[Anoniem: 913409]

Gedaan, dank u voor de tip.

Hopelijk heeft iemand een antwoord hierop.

[Orion84]

Ten eerste mis je een haakje sluiten, maar bovenal: zoek zelf eens uit hoe die date format functie werkt. Zoals @Creepy ook al aangaf is het hier geen afhaalchinees. Zeker bij een schoolopdracht mag je wel wat meer eigen inzet tonen.

[Anoniem: 420461]

En let even goed op - je hebt het de ene keer over $date["datum1"], en de andere keer over $data["datum1"]

[ShitHappens]

Anoniem: 913409 schreef op maandag 24 april 2017 @ 20:34:

code:

<?php
echo "<td>" . date_format($date["datum1"], 'Y-m-d '). "</td>";
?>

i.p.v.

code:

<?php
echo "<td>" . $data["datum1"] . "</td>";
?>

Nu wordt de datum helemaal niet weergeven. Is het gewoon een wit vlak. Dat is ook niet de bedoeling.

Dat gaat sowieso al niet, die date_format() functie verwacht echt een DateTime binnen te krijgen, geen String die toevallig op een datum lijkt.
Persoonlijk zou ik er voor kiezen om te beginnen met dat veld al in MySQL het goede datatype mee te geven. Dan kun je met DATE_FORMAT() in je query deze al naar 't goeie formaat laten casten, of later in PHP naar het gewenste formaat.

Afhankelijk van of er nog bonuspunten te krijgen zijn, kun je ook nog eens kijken naar database normalisatie en SQL injection.

Succes!

[ Voor 12% gewijzigd door ShitHappens op 24-04-2017 21:21 ]

[ACM]

ShitHappens schreef op maandag 24 april 2017 @ 21:21:
Afhankelijk van of er nog bonuspunten te krijgen zijn, kun je ook nog eens kijken naar database normalisatie en SQL injection.

En Cross Site Scripting

[Spinal]

Tip: de mysql_* functies zijn sinds PHP 5.5 deprecated en in PHP 7 verwijderd. Die zou je niet meer moeten gebruiken. Gebruik in plaats daarvan MySQLi of PDO!

[Bigs]

Als je deze code werkelijk gaat gebruiken om persoonsgevens te verwerken in een productieomgeving wil ik je echt even wijzen op de Meldplicht datalekken. Daar ga je met deze code namelijk vroeg of laat wel mee te maken krijgen.

Verder zie http://php.net/manual/en/function.setlocale.php en http://php.net/strftime

[GrooV]

Bigs schreef op dinsdag 25 april 2017 @ 09:19:
Als je deze code werkelijk gaat gebruiken om persoonsgevens te verwerken in een productieomgeving wil ik je echt even wijzen op de Meldplicht datalekken. Daar ga je met deze code namelijk vroeg of laat wel mee te maken krijgen.

Verder zie http://php.net/manual/en/function.setlocale.php en http://php.net/strftime

Hoezo wat kan er misgaan met:

code:

 $result = mysql_query("SELECT * FROM registratiekaart WHERE id = '" . $_GET['id'] . "'")
                                        or die(mysql_error());

Must read tip voor TS: Zorg dat je prepared statements and parameterized queries gebruikt, nu ben je zo lek als een mandje. Zie: http://stackoverflow.com/a/60496/253440 en nog meer leesvoer: https://www.owasp.org/index.php/SQL_Injection

Erg kwalijk dat er bij je studie hier niet op gehamerd wordt

[ Voor 3% gewijzigd door GrooV op 25-04-2017 10:01 ]

[Bigs]

GrooV schreef op dinsdag 25 april 2017 @ 10:00:
[...]

Erg kwalijk dat er bij je studie hier niet op gehamerd wordt

Ik sprak een keer een derdejaars MBO'er die bij z'n docent had nagevraagd hoe het zat met zaken als SQL injection en of ze daar geen rekening mee moesten houden. Antwoord was: ja dat komt volgend jaar aan bod leer het gewoon gelijk goed aan..

[Ofyles2]

Zijn die docenten eigenlijk bevoegd om zich met ICT bezig te houden?

[RGAT]

Ofyles2 schreef op dinsdag 25 april 2017 @ 21:10:
Zijn die docenten eigenlijk bevoegd om zich met ICT bezig te houden?

Goede MBO docenten zijn extreem zeldzaam, de meeste hebben geen kennis, geen interesse of geen uitstraling/connectie met de leerlingen helaas...
Er zijn er wel een paar goede, die je direct hadden laten nablijven voor:

code:

$result = mysql_query("SELECT * FROM registratiekaart WHERE id = '" . $_GET['id'] . "'")

TS: Volg een goede (of een paar, kan nooit kwaad ) PHP/MySQL tutorial, dit gaat je code, begrip ervan en veiligheid enorm helpen. Het script zoals je het nu wilt schrijven is een ramp voor beveiliging...

Anyway: hier staat alles wat je moet weten om timestamps om te vormen, geweldige van PHP is o.a. die website welke een vrij goede documentatie heeft samen met voorbeelden van de community.

[RiDo78]

Anoniem: 913409 schreef op maandag 24 april 2017 @ 20:34:
Ha, is niet de bedoeling dat iemand mijn script aanpast, wat ik wel typte inderdaad, maar wil graag wat tips. Als ik dit namelijk afrond dan heb ik mijn eindproject voldoende afgerond dus ben er druk mee bezig om dit gedaan te krijgen.

Wacht even . . . Niet om te trollen hoor, maar ik begrijp gewoon niet dat jouw code als voldoende voor een eindproject kan worden beoordeeld. Maar wat RGAT al aangaf, goede docenten zijn moeilijk te vinden. En de kwaliteit van code die sommige (toekomstige) collega's durven te produceren is soms tenenkrommend slecht. Als die collega's dan ook nog eens luidkeels verkondingen: 'Als het werkt, dan werkt het', dan snappen ze volgens mij niet waar ze mee bezig zijn.

Vandaar dat ik je graag een paar verbeterpuntjes mee wil geven. Enerzijds voor een hoger cijfer, anderzijds... je kunt het maar beter in 1x goed leren.

• Het is al meer malen in het topic aangehaald en ik kan er niet omheen om het te herhalen. Pas die query aan! Om even naar een ziekenhuisanalogie te gaan, behandel alle 'vreemde' data (Dus $_GET, $_POST, $_REQUEST, enz.) als ZEER besmettelijk. En behandel je database als een zieke patient zonder immuumsysteem. Dus als je 'iets' met vreemde data richting de database doet, ontsmet het dan. En omdat het besmettelijk is, doe je dat het liefst zo snel mogelijk. Dus als $_GET['id'] altijd een cijfer zou moeten zijn, waarom die dan niet eerst testen met is_numeric()?
• Ik ga er vanuit dat het voor de opdracht niet van belang is hoe de uiteindelijke HTML code er uit komt te zien. Mocht dat wel zo zijn, dan heb je nog wat te doen. Deze code komt er namelijk uit als 1 lange onafgebroken regel.
• Hoewel de enkele en dubbele quote hetzelfde lijken te doen, zijn ze wezelijk anders. De enkele quotes zijn voor strings waar PHP zich niet druk over hoeft te maken. PHP verwacht daar geen bijzonderheden in, behalve een ge-escapete enkele quote. Dubbelle quotes daarintegen vertellen PHP dat de string bijzonderheden bevat. Zoals inline variabelen (die jij gelukkig niet gebruikt) of opmaaktekens (\n, \r, \t, enz.). PHP gaat die strings analyseren, wat extra inspanning kost. Tuurlijk, tegenwoordig zijn de CPU's zo snel dat je je daar niet druk meer over hoeft te maken, maar waarom zou je niet? Bovendien vind ik bij sommige lange strings ook erg makkelijk dat ik in 1 oogopslag kan zien dat er geen bijzonderheden in zitten.
• Waarom gebruik je eigenlijk de procedurele methode en niet de object georienteerde? De huidige generatie talen zijn allemaal object georienteerd. En het levert naar mijn mening ook betere code op.
• Het is niet echt fout, maar waarom gebruik je echo in plaats van print? Ze doen beide hetzelfde natuurlijk, maar als je andere talen leert dan zul je zien dat echo vaak in scripting-talen terug komt en print vaker in de 'volledige' talen. Bovendien heb je van print nog andere varianten zoals printf of sprintf. De code wordt naar mijn mening ook mooier als je consequent blijft. Dus als je een printf nodig hebt, dan moet er geen echo in de buurt staan.
• En nu ik het dan toch over echo/print heb, persoonlijk gebruik ik die het liefst zo min mogelijk. Ik plak liever de teksten aan elkaar zoals: $text = 'abc'; $text .= 'def'; of met heredoc/nowdoc. Het voordeel daarvan is dat je er later ook iets anders mee kunt doen. Bijvoorbeeld door een sanitizer halen (htmltidy bijvoorbeeld), naar disk schrijven of er een email van maken.
• Even over je HTML... Voor het gemak ga ik er vanuit dat je de opmaak via CSS doet. Maar het gebruik van een lege cel zoals met <td> </td> leid tot onvoorspelbaar gedrag. Als je een tabel met 3d border tekent, dan zullen sommige browsers die cel niet tekenen. Beter forceer je er een spatie in met  .
• Tot slot de database. Was die gegeven? Of heb je die zelf ontworpen? Ik vind hem namelijk vrij plat. Hoewel hij doet wat hij moet doen, mag je de database aan gaan passen als je een zesde regel nodig hebt.

[Olaf van der Spek]

RGAT schreef op dinsdag 25 april 2017 @ 21:23:
TS: Volg een goede (of een paar, kan nooit kwaad ) PHP/MySQL tutorial, dit gaat je code, begrip ervan en veiligheid enorm helpen. Het script zoals je het nu wilt schrijven is een ramp voor beveiliging...

Stap af van PHP en kijk eens naar Python

RiDo78 schreef op dinsdag 25 april 2017 @ 23:16:
• Het is niet echt fout, maar waarom gebruik je echo in plaats van print? Ze doen beide hetzelfde natuurlijk,

Maar print returned 1..
En print ondersteunt maar één argument.

[ Voor 29% gewijzigd door Olaf van der Spek op 28-04-2017 16:44 ]

[xleeuwx]

Olaf van der Spek schreef op vrijdag 28 april 2017 @ 16:39:
[...]

Stap af van PHP en kijk eens naar Python

Inderdaad ik denk ook dat nu overstappen naar een andere programmeertaal hem heel snel verder gaat helpen...

[eric.1]

Olaf van der Spek schreef op vrijdag 28 april 2017 @ 16:39:
[...]

Stap af van PHP en kijk eens naar Python

Dan ben ik toch wel benieuwd naar je argumenten!
(Niet cynisch bedoeld)

[ShitHappens]

Olaf van der Spek schreef op vrijdag 28 april 2017 @ 16:39:
[...]
Stap af van PHP en kijk eens naar Python

Dit ziet eruit als een schoolopdracht en dus hele dikke kans dat PHP een vereiste is/als enige behandeld is.

[DJMaze]

Olaf van der Spek schreef op vrijdag 28 april 2017 @ 16:39:
Stap af van PHP en kijk eens naar Python

Of: A+, A++, A#, B, C, C++, C#, D, E, F, G, J, K, L, P#, Q, R, S, T, ETCETERA

[Olaf van der Spek]

eric.1 schreef op vrijdag 28 april 2017 @ 16:54:
[...]


Dan ben ik toch wel benieuwd naar je argumenten!
(Niet cynisch bedoeld)

Goede interfaces zijn makkelijk te gebruiken en moeilijk te misbruiken. PHP interfaces zijn het tegenovergestelde.

PHP:

mysql_query("SELECT * FROM registratiekaart WHERE id = '" . $_GET['id'] . "'")
                                        or die(mysql_error());

PHP:

db_query("SELECT * FROM registratiekaart WHERE id = ?", $_GET['id']);

Een van de twee is veilig, een van de twee is makkelijk te gebruiken en een van de twee is standaard beschikbaar in PHP..

[ Voor 3% gewijzigd door Olaf van der Spek op 30-04-2017 10:37 ]

[eric.1]

Olaf van der Spek schreef op zondag 30 april 2017 @ 10:36:
[...]

Goede interfaces zijn makkelijk te gebruiken en moeilijk te misbruiken. PHP interfaces zijn het tegenovergestelde.

PHP:

mysql_query("SELECT * FROM registratiekaart WHERE id = '" . $_GET['id'] . "'")
                                        or die(mysql_error());

PHP:

db_query("SELECT * FROM registratiekaart WHERE id = ?", $_GET['id']);

Een van de twee is veilig, een van de twee is makkelijk te gebruiken en een van de twee is standaard beschikbaar in PHP..

Ik zie niet zozeer waarom Python uit jouw voorbeeld zoveel beter is?

Uiteindelijk gaat het niet (zo zeer) om de gebruikte taal, maar de manier waarop je het gebruikt.

Of je nu PHP of Python gebruikt (of welke andere (script-)taal dan ook), je zal meer moeten doen dan alleen denken aan de te maken query;
1. Gebruik geen outdated/uitgefaseerde functies;
2. Zorg voor Iteratieve input validatie;
3. Maak gebruik can Prepare-statements;
4. Zorg voor Error-afhandeling;
5. Denk na over het gebruik van credentials en de plaatsing daarvan;

Als je (in ieder geval) dit niet doet zal geen enkele taal goed en veilig te gebruiken zijn .

[RiDo78]

eric.1 schreef op zondag 30 april 2017 @ 10:59:
[...]

Ik zie niet zozeer waarom Python uit jouw voorbeeld zoveel beter is?

Uiteindelijk gaat het niet (zo zeer) om de gebruikte taal, maar de manier waarop je het gebruikt.

Of je nu PHP of Python gebruikt (of welke andere (script-)taal dan ook), je zal meer moeten doen dan alleen denken aan de te maken query;
1. Gebruik geen outdated/uitgefaseerde functies;
2. Zorg voor Iteratieve input validatie;
3. Maak gebruik can Prepare-statements;
4. Zorg voor Error-afhandeling;
5. Denk na over het gebruik van credentials en de plaatsing daarvan;

Als je (in ieder geval) dit niet doet zal geen enkele taal goed en veilig te gebruiken zijn .

Helemaal mee eens. Bij het programmeren zit de fout doorgaans tussen beeldscherm en rugleuning.

[RGAT]

Olaf van der Spek schreef op zondag 30 april 2017 @ 10:36:
[...]

Goede interfaces zijn makkelijk te gebruiken en moeilijk te misbruiken. PHP interfaces zijn het tegenovergestelde.

PHP:

mysql_query("SELECT * FROM registratiekaart WHERE id = '" . $_GET['id'] . "'")
                                        or die(mysql_error());

PHP:

db_query("SELECT * FROM registratiekaart WHERE id = ?", $_GET['id']);

Een van de twee is veilig, een van de twee is makkelijk te gebruiken en een van de twee is standaard beschikbaar in PHP..

Tja je vergelijkt met een PHP functie welke al jaren vervangen is voor MySQLi en PDO en zelfs niet meer in PHP (7) zit en hier wordt gebruikt op exact de verkeerde manier...
Verder zien de functies er identiek uit behalve dat PHP ook een error handler heeft hier....

[Olaf van der Spek]

RGAT schreef op zondag 30 april 2017 @ 18:43:
Tja je vergelijkt met een PHP functie welke al jaren vervangen is voor MySQLi en PDO en zelfs niet meer in PHP (7) zit en hier wordt gebruikt op exact de verkeerde manier...

Voor mysqli_query() en PDO::query() geldt toch precies hetzelfde?

Verder zien de functies er identiek uit behalve dat PHP ook een error handler heeft hier....

Ik begrijp niet wat je bedoelt.

[Merethil]

Olaf van der Spek schreef op zondag 30 april 2017 @ 19:11:

[...]

Ik begrijp niet wat je bedoelt.

Dat er een "or die(error)" in zit. Iets wat heel handig is tijdens debuggen en daarna nooit meer voorbij mag komen maar er per ongeluk toch vaak in blijft staan als de persoon in kwestie niet zoveel ervaring heeft.

[NMe]

Olaf van der Spek schreef op zondag 30 april 2017 @ 10:36:
Een van de twee is veilig, een van de twee is makkelijk te gebruiken en een van de twee is standaard beschikbaar in PHP..

Er zijn ook voldoende functies die wél veilig zijn standaard beschikbaar in PHP, en het is niet alsof andere talen niet de mogelijkheid tot SQL-injectie bieden aan mensen die niet weten wat ze doen...

Jouw advies om van PHP af te stappen en Python te gaan gebruiken is sowieso hetzelfde als tegen een timmerman zeggen dat hij die hamer moet laten vallen en in het vervolg een schroevendraaier moet nemen. Dat is prima advies als hij inderdaad een schroef moet vastdraaien maar het maakt 't verdomd ineffectief als je een keer een spijker in een plank wil slaan. Je advies is dan ook totaal niet serieus te nemen zonder onderbouwing, en het beetje onderbouwing dát je geeft rammelt zoals ik in mijn eerste alinea al aantoon...

[Olaf van der Spek]

NMe schreef op zondag 30 april 2017 @ 19:39:
Er zijn ook voldoende functies die wél veilig zijn standaard beschikbaar in PHP,

Goede interfaces zijn makkelijk te gebruiken en moeilijk te misbruiken. PHP interfaces zijn het tegenovergestelde.

mysqli.prepare is niet makkelijk te gebruiken.
Op http://php.net/manual/en/mysqli.query.php zie ik ook geen waarschuwing dat je deze functie eigenlijk niet direct moet gebruiken.

en het is niet alsof andere talen niet de mogelijkheid tot SQL-injectie bieden aan mensen die niet weten wat ze doen...

Natuurlijk kun je het fout doen maar zoals je ziet is het in Python al heel veel makkelijker om het goed te doen.

Merethil schreef op zondag 30 april 2017 @ 19:33:
Dat er een "or die(error)" in zit.

Ah, zo. Ze zien er inderdaad vrijwel identiek uit, maar zoals gezegd is maar één van de twee veilig.

[ Voor 21% gewijzigd door Olaf van der Spek op 30-04-2017 20:01 ]

[NMe]

Olaf van der Spek schreef op zondag 30 april 2017 @ 19:59:
[...]

[...]

mysqli.prepare is niet makkelijk te gebruiken.

Da's subjectief maar zelfs als je dat voor waar aan wil nemen zijn er nog steeds zat alternatieven.

Op http://php.net/manual/en/mysqli.query.php zie ik ook geen waarschuwing dat je deze functie eigenlijk niet direct moet gebruiken.

Omdat er niks mis is met die functie als je een statische query wil doen. Er staat ook nergens op die pagina dat je strings met gebruikersinput aan elkaar moet plakken.

Natuurlijk kun je het fout doen maar zoals je ziet is het in Python al heel veel makkelijker om het goed te doen.

String concatenation is in beide talen even makkelijk.

[ACM]

NMe schreef op zondag 30 april 2017 @ 20:27:
Omdat er niks mis is met die functie als je een statische query wil doen. Er staat ook nergens op die pagina dat je strings met gebruikersinput aan elkaar moet plakken.

Dit zijn natuurlijk ook gewoon valide prepare-calls:

PHP:

mysqli_prepare('SELECT * FROM tabel WHERE veld = 15');
mysqli_prepare('SELECT * FROM tabel WHERE veld = ' . $_GET['waarde']);

Wat betreft prepared statements heb ik altijd geleerd dat dat met name bedoeld is/was ivm performance; en dan vooral om te voorkomen dat het parsen (en samenstellen van execution plan, etc) van een query steeds herhaald moet worden. Door dat te scheiden is het sneller om de query herhaald uit te voeren, maar als je die query maar 1x uitvoert introduceer je juist extra overhead.

Bij netjes gebruiken van prepared statements is het uiteraard wel lastiger om sql-injection te krijgen, maar dan moet het dus wel netjes gebeuren (zie voorgaande voorbeelden). Bovendien zijn er scenario's waar het concept prepared statements gewoon niet zo geschikt voor is. Denk aan queries die on-the-fly worden samengesteld en dus een variabel aantal parameters hebben of queries met een IN-statement waar een willekeurige lijst in mag komen.

Verder moet ik zeggen dat ik PHP's variant erg magicky vind. De bind_param methode koppel je via een referentie-constructie (net zoiets als de &) aan een variabele. Dat maakt het trouwens ook lastiger om het samenstellen en uitvoeren van queries los te trekken (als je dat zou willen), want je moet dan alsnog achteraf die parameters precies goed binden.

Ik zou het logischer vinden als je domweg de execute-methode met een reeks parameters kan aanroepen en ben dan ook blij dat Spring deze syntax biedt (Java zelf maakt het ongeveer net zo lastig als php, maar dan zonder de magic):

Java:

this.jdbcTemplate.update(
        "insert into t_actor (first_name, last_name) values (?, ?)",
        "Leonor", "Watling");

[ Voor 4% gewijzigd door ACM op 30-04-2017 22:04 ]

[BLACKfm]

Ik zou haast zeggen dat het makkelijker is een 'dagnaam' in de database als een extra tabel toe te voegen bij het invoeren van de gegevens dan dat het uitlezen (en omrekenen daarvan) weer in de code te moeten verwerken.

Maar ik ben dan ook maar een huis-tuin-en-keuken prutser , dus ik ga liever voor de easy way in.
_{(en ben nu denk ik behoorlijk aan het vloeken in deze kerk}

[ShitHappens]

Aan de andere kant is 't weer slecht databaseontwerp om zaken op te gaan slaan die ook berekend kunnen worden op basis van andere data Om dan nog maar te zwijgen over problemen die je gaat krijgen als je meerdere talen/landen wilt gaan ondersteunen (ander datumformaat etc), of de dagnaam toch weer niet gewenst is en DD-MM getoond moet gaan worden.
Daarom is 't algemeen gangbaar om een datum daadwerkelijk als datum op te slaan in de DB (DateTime of hoe je DB het ook wilt noemen), en dan pas op weergavelaag die te manipuleren naar wens.

[NMe]

BLACKfm schreef op zondag 30 april 2017 @ 22:43:
Ik zou haast zeggen dat het makkelijker is een 'dagnaam' in de database als een extra tabel toe te voegen bij het invoeren van de gegevens dan dat het uitlezen (en omrekenen daarvan) weer in de code te moeten verwerken.

Maar ik ben dan ook maar een huis-tuin-en-keuken prutser , dus ik ga liever voor de easy way in.
_{(en ben nu denk ik behoorlijk aan het vloeken in deze kerk}

Dat ben je inderdaad. Naast het al genoemde strftime kent PHP net als veel andere talen ook een Intl-library die je dit soort dingen uit handen neemt.

[ Voor 4% gewijzigd door NMe op 01-05-2017 00:08 ]

[DJMaze]

Olaf van der Spek schreef op zondag 30 april 2017 @ 19:59:
Ah, zo. Ze zien er inderdaad vrijwel identiek uit, maar zoals gezegd is maar één van de twee veilig.

Hoe weet je dat zo zeker? Is er bewijs voor?
YouTube: Assumption is the mother of all fuck-ups HD

Het woord "evangelist" was volgens mij ooit bestemd voor gelovigen van een godsdienst die overal ter wereld mensen wilden bekeren.
Vroeger hete dat kruistochten en nu extremisten en terroristen.

Ben jij nu een programmeertaal evangelist of extremist?
Ik dacht namelijk dat de vorige antwoorden op jouw tekst duidelijk waren.

[ Voor 5% gewijzigd door DJMaze op 01-05-2017 00:11 ]

[Olaf van der Spek]

NMe schreef op zondag 30 april 2017 @ 20:27:
[...]

Da's subjectief

Is dat zo? Mijn interface (db_query()) heb ik al gegeven, misschien kun je jouw makkelijke interface ook even uitschrijven dan kunnen we de twee, objectief, vergelijken.

maar zelfs als je dat voor waar aan wil nemen zijn er nog steeds zat alternatieven.

Zoals? PDO is ook niet echt makkelijk dacht ik.

DJMaze schreef op maandag 1 mei 2017 @ 00:09:
Hoe weet je dat zo zeker?

Hoe weet ik wat zeker? Dat een van de twee onveilig is? Dat de ander wel veilig is?

Ben jij nu een programmeertaal evangelist of extremist?

Gaan we op de man spelen?

Ik dacht namelijk dat de vorige antwoorden op jouw tekst duidelijk waren.

Verkeerd gedacht.

[ Voor 32% gewijzigd door Olaf van der Spek op 01-05-2017 09:49 ]

[DJMaze]

Olaf van der Spek schreef op maandag 1 mei 2017 @ 09:47:
Gaan we op de man spelen?
Verkeerd gedacht.

Ik speel het niet op de man, het moet stof tot nadenken zijn.

Een leerling krijgt PHP op school.
Door hem negatief te benaderen (op welke manier dan ook), maakt hem niet enthousiast om door te gaan met zijn opleiding.
Ook al weten wij allemaal dat het nooit goed genoeg is en leraren "dom".
Als je zo graag wil dat men Python leert moet je zelf maar leraar worden en de negativiteit zelf incasseren.

Zo niet, kan je hem beter de juiste richting opsturen in de taal die hij leert i.p.v. hem iets compleets nieuws te leren waar hij op school niks aan heeft.

Ik heb een opleiding motorvoertuigentechniek gedaan en leerde programmeren in Basic. En hebben auto's nu bergen aan electronica die niet in Basic zijn. Tja, wat nu dan?
Doorleren en autodidact, zorg dus voor die basis.

[NMe]

DJMaze schreef op maandag 1 mei 2017 @ 10:01:
[...]

Een leerling krijgt PHP op school.

Zelfs dat is het issue niet. Ja, PHP heeft flaws. Het doet ook een aantal dingen goed. Het advies om Python te gebruiken is zonder verdere context gewoon niet serieus te nemen, zie mijn gereedschapsvoorbeeld hierboven. Niet alleen voor studenten, maar ook wat betreft de werkplek. Wat als Python niet beschikbaar is? Wat als het een project voor een klant is die wil dat het in PHP gemaakt wordt zodat in-house developers er ook mee overweg kunnen? Wat als het een eis is dat het project op een zo breed mogelijk publiek moet aansluiten? Wat als je PHP dermate van binnen en van buiten kent dat geen van de valkuilen nog echt een issue is?

PHP is niet objectief slechter dan Python. Andersom ook niet. Elke taal heeft zijn eigen toepassingen en daarom bestaansrecht.

[Olaf van der Spek]

DJMaze schreef op maandag 1 mei 2017 @ 10:01:
Een leerling krijgt PHP op school.

Ik wist niet dat dit een schoolsituatie was. Kijken naar andere talen en de beste taal voor de job kiezen is niet verkeerd toch? Maar ok, wellicht was het niet de beste suggestie.

NMe schreef op maandag 1 mei 2017 @ 10:53:
[...]

Olaf van der Spek schreef op maandag 1 mei 2017 @ 09:47:
Is dat zo? Mijn interface (db_query()) heb ik al gegeven, misschien kun je jouw makkelijke interface ook even uitschrijven dan kunnen we de twee, objectief, vergelijken.

NMe schreef op maandag 1 mei 2017 @ 10:53:
PHP is niet objectief slechter dan Python. Andersom ook niet. Elke taal heeft zijn eigen toepassingen en daarom bestaansrecht.

Ik denk niet dat dat waar is. Er zijn zeker talen die in alle opzichten slechter zijn dan een andere taal en dan heb je IMO geen bestaansrecht meer.

[ Voor 59% gewijzigd door Olaf van der Spek op 07-05-2017 12:09 ]

[NMe]

Ook die opmerking kan ik zonder onderbouwing niet serieus nemen.

[Olaf van der Spek]

NMe schreef op zondag 7 mei 2017 @ 19:27:
[...]

Olaf van der Spek schreef op maandag 1 mei 2017 @ 09:47:
Is dat zo? Mijn interface (db_query()) heb ik al gegeven, misschien kun je jouw makkelijke interface ook even uitschrijven dan kunnen we de twee, objectief, vergelijken.

[ Voor 7% gewijzigd door Olaf van der Spek op 08-05-2017 09:22 ]

[servies]

Olaf van der Spek schreef op zondag 7 mei 2017 @ 12:05:
[...]

Ik wist niet dat dit een schoolsituatie was.

4e reactie in topic...

Kijken naar andere talen en de beste taal voor de job kiezen is niet verkeerd toch? Maar ok, wellicht was het niet de beste suggestie.

Dat klopt tot op zekere hoogte en hoe je dat bepaalt is nog een 2e vraag...
Maar daarbij blijft nog de vraag wat we liever hebben wat ze op de scholen gaan doen:
Van alle talen een klein beetje leren en daardoor niet toekomen aan het idee/concept achter programmeren/software engineering of één taal relatief veel gebruiken en daardoor wel toekomen aan de achtergrond...

Ik denk niet dat dat waar is. Er zijn zeker talen die in alle opzichten slechter zijn dan een andere taal en dan heb je IMO geen bestaansrecht meer.

Pruts amateur(s) dat je/jullie bent/zijn:
Er is maar een echte programmeertaal en dat is 'C', de rest is alleen maar een slap aftreksel...
* servies trekt zijn asbest pak aan...

En natuurlijk is die laatste regel onzin, maar het is net zo'n onzin om te denken dat er talen zijn die in alle opzichten slechter zijn dan een andere taal... Het is heel simpel, als zo'n taal nog steeds gebruikt wordt dan heeft die taal blijkbaar bestaansrecht... Al was het maar omdat je anders tientallen manjaren kwijt bent aan het her/omschrijven van een applicatie...

[NMe]

Olaf van der Spek schreef op maandag 8 mei 2017 @ 09:22:
[...]

[...]

Je wil een hele taal afschrijven op een functie die je niet handig vindt werken. Een functie die vrijwel géén van de developers in de taal ooit zelf zal aanroepen omdat ze ofwel Doctrine, ofwel Eloquent ofwel een andere (al dan niet zelfgemaakte) laag/ORM ertussen hebben zitten. Dit is onderhand net zoiets als C en C++ afschrijven omdat al dat gedereference van pointers wel heel erg makkelijk is om fout te doen, waarbij we maar vergeten dat vrijwel alle grote gamebedrijven nog steeds met C++ werken en vrijwel elk apparaat dat je koopt wel een stukje embedded software in C draait.

[Olaf van der Spek]

NMe schreef op maandag 8 mei 2017 @ 11:19:
Je wil een hele taal afschrijven op een functie die je niet handig vindt werken.

Er schort wel (veel) meer aan PHP.

Een functie die vrijwel géén van de developers in de taal ooit zelf zal aanroepen

Is Jaap geen developer in de taal of valt ie in de vrijwel geen categorie?

omdat ze ofwel Doctrine, ofwel Eloquent ofwel een andere (al dan niet zelfgemaakte) laag/ORM ertussen hebben zitten.

Volgens mij ben je de eerste die over ORM begint, terwijl ik mysqli en PDO al een paar keer voorbij heb zien komen. Dus je raadt Jaap aan een ORM te gebruiken?

Dit is onderhand net zoiets als C en C++ afschrijven omdat al dat gedereference van pointers wel heel erg makkelijk is om fout te doen, waarbij we maar vergeten dat vrijwel alle grote gamebedrijven nog steeds met C++ werken en vrijwel elk apparaat dat je koopt wel een stukje embedded software in C draait.

Is C dan ook niet al vrijwel afgeschreven? Als er niks beters beschikbaar is (of je een bestaande codebase hebt) begrijp ik het nog. Ggamebedrijven kiezen volgens mij vooral voor C++, niet voor C.

[ Voor 3% gewijzigd door Olaf van der Spek op 09-05-2017 18:03 ]

[Knorretje-]

Sorry dat ik jullie discussie verstoor, maar ik zou dit eens proberen. De datum staat zo te zien als plain text (varchar bvb) in je database ipv als datetime.

code:

$time = strtotime($data["datumX"]);
echo date('Y-m-d',$time);

[Anoniem: 420461]

totoberg123 schreef op vrijdag 19 mei 2017 @ 00:56:
Sorry dat ik jullie discussie verstoor, maar ik zou dit eens proberen.

Dat heeft 'ie al - hij wil de dag van de week weergeven, maar zoeken op de date-functie is blijkbaar te veel werk.

[Anoniem: 923859]

werving hoort hier niet

[ Voor 104% gewijzigd door Creepy op 19-05-2017 23:00 ]

[Marco1994]

Gebruik dan ook de quote knop niet...

[ Voor 96% gewijzigd door Creepy op 19-05-2017 23:01 ]

[Harrie_]

Wat een discussie weer bij zo'n simpel stukje code

code:

<?php

$datum1 = "22-05-2017"; // je trekt kennelijk strings ipv dates uit je DB

$dagnummer = date("N", strtotime($datum1)); // ipv $datum1 kun je hier dus ook
                                               rechtstreeks je sql result in mikken

$dagnaam = array(
    'Zondag',
    'Maandag',
    'Dinsdag',
    'Woensdag',
    'Donderdag',
    'Vrijdag',
    'Zaterdag',
);

echo $dagnaam[$dagnummer];

?>

En dan krijg je dit:

code:

Maandag

[RiDo78]

McLatey schreef op maandag 22 mei 2017 @ 17:13:
Wat een discussie weer bij zo'n simpel stukje code

Die discussie ging over het veilig schrijven van code. Niet hoe je een datum omzet in een dagnaam. Noem het offtopic, noem het opvoeding. Feit is dat er teveel onveilige code de wereld in wordt geschopt. Maar je hebt gelijk, een werkbaar antwoord is lastig te vinden.

code:

<?php

$datum1 = "22-05-2017"; // je trekt kennelijk strings ipv dates uit je DB

$dagnummer = date("N", strtotime($datum1)); // ipv $datum1 kun je hier dus ook
                                               rechtstreeks je sql result in mikken

$dagnaam = array(
    'Zondag',
    'Maandag',
    'Dinsdag',
    'Woensdag',
    'Donderdag',
    'Vrijdag',
    'Zaterdag',
);

echo $dagnaam[$dagnummer];

?>

En dan krijg je dit:

code:

Maandag

Wat heet simpel?

code:

setlocale(LC_TIME, 'nl_NL');
print(strftime('%A', strtotime('22-05-2017')));

geeft

code:

maandag

[Harrie_]

RiDo78 schreef op maandag 22 mei 2017 @ 18:31:
[...]
Een zeer klein stukje code wat exact doet wat TS vraagt
[...]

Heel netjes, ik had het bewust wat 'uitgebreider' gehouden met een array; denk dat dat iets meer tot de verbeelding spreekt voor beginnende TS