Interface ''werknemers'' onderhouden
Ik kan een overzicht geven van de inhoud (index.php), Ik kan een item toevoegen (add.php), wijzigen (edit.php) en verwijderen (delete.php).
Nu moet ik een interface bouwen, waarbij wij de tabel werknemers mee kunnen onderhouden.
Ik heb al een werknemerstabel aangemaakt:
De werknemerstabel ziet er als volgt uit:
ID numeriek a/i primaire sleutel
Naam varchar 50
Adres varchar 50
Postcode varchar 6 (of 7)
Plaats varchar 50
Telefoon varchar 10
Functie varchar 25
Nu is het de bedoeling dat ik een of meerdere php bestanden maak waarmee ik deze tabel kan onderhouden. Zou iemand mij hier mee kunnen helpen? Het mag ook allemaal in een tabel, dat maakt me niks uit.
Met vriendelijke groet,
Maar wat versta je hier dan onder onderhouden?
- Ariën - op 28/01/2016 11:31:37:
je geeft zelf al aan dat je een overzicht kan geven, een werknemer kan wijzigen, aanpassen en verwijderen.
Maar wat versta je hier dan onder onderhouden?
Maar wat versta je hier dan onder onderhouden?
Hiermee bedoel ik dat ik een php bestand van werknemers kan zien, dat ik een overzicht heb van de naam van de werknemer, adres, eigenlijk zoals ik hierboven in de werknemerstabel heb aangegeven.
de add.php/delete.php dient voor het toevoegen of verwijderen van kopjes aan het menu op de website.
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
<?php
if(isset($_GET['actie'])) {
switch($_GET['actie']) {
case "add":
// voeg hier je werknemer toe, bereikbaar onder werknemers.php?actie=add
break;
case "edit":
// wijzig hier je werknemer, bereikbaar onder bijv. werknemers.php?actie=edit&id=42
// controleer ook op het bestaan van $_GET['id'] met isset().
break;
case "delete":
// verwijder hier je werknemer, bereikbaar onder bijv. werknemers.php?actie=delete&id=42
// controleer ook op het bestaan van $_GET['id'] met isset(). Bij sterke voorkeur in de database markeren als 'verwijderd' (0 of 1).
break;
}
} else {
// toon hier je lijst, die is dan bereikbaar via werknemers.php
}
?>
if(isset($_GET['actie'])) {
switch($_GET['actie']) {
case "add":
// voeg hier je werknemer toe, bereikbaar onder werknemers.php?actie=add
break;
case "edit":
// wijzig hier je werknemer, bereikbaar onder bijv. werknemers.php?actie=edit&id=42
// controleer ook op het bestaan van $_GET['id'] met isset().
break;
case "delete":
// verwijder hier je werknemer, bereikbaar onder bijv. werknemers.php?actie=delete&id=42
// controleer ook op het bestaan van $_GET['id'] met isset(). Bij sterke voorkeur in de database markeren als 'verwijderd' (0 of 1).
break;
}
} else {
// toon hier je lijst, die is dan bereikbaar via werknemers.php
}
?>
Gewijzigd op 28/01/2016 12:06:21 door - Ariën -
Hier kan OOP uitkomst bieden door een sjabloon te maken voor pagina-opbouw en een soortement van "routing" voor je acties. Vervolgens maak je een class Medewerkers die extend van dit sjabloon zodat je geen dingen dubbel doet.
Een werknemers-script kan snel best lang worden, ik weet niet of een (super lang) switch-statement dan echt zo fijn werkt :/. Het leest toch een stuk fijner als je dit compartimenteert in aparte methoden volgens eerdergenoemd sjabloon. EDIT: zodat dit programmatisch ook echt aparte onderdelen omvat, in tegenstelling tot een switch-statement, wat toch één (spaghetti?)sliert is.
Gewijzigd op 28/01/2016 12:44:51 door Thomas van den Heuvel
Daarom leg ik de lat niet te hoog. Met termen zoal routing, OOP, class en extenden, vrees ik mensen hier bang te zullen maken. Tenzij duidelijk is op welk niveau van PHP ze zitten.
Misschien handig om hier voortaan even rekening mee te houden. Het is hier PHPhulp en geen PHP-Pro-Hulp. ;-)
Gewijzigd op 28/01/2016 13:42:16 door - Ariën -
Ik gooi mensen zeker niet (zomaar) in het diepe, maar ben tegelijkertijd van mening dat je mensen niet (eindeloos) in het peuterbad moet houden.
Of een topicstarter de (zwem)les bij kan benen zal nog moeten blijken, je kunt dan altijd nog besluiten om gas terug te nemen.
Daarbij, als ik een voorbeeld geef als hier om wordt gevraagd, dan hoeft men deze initieel niet per definitie volledig te kunnen doorgronden, men moet enkel een zeker gevoel hebben hoe deze werkt en hoe je deze verder kunt gebruiken.
Om een auto te kunnen besturen hoef je ook niet te weten hoe een verbrandingsmotor werkt, als je uitlegt wat het stuur, de pedalen en versnellingsbak doen ben je al een heel eind.
Ik heb een déjà vu, hier hebben we het al eens eerder over gehad (alleen is het waarschijnlijk onmogelijk om dit terug te vinden met de huidige zoekfunctionaliteit).
Ik houd hier zeker rekening mee, en verwacht tegelijkertijd dat vragenstellers ook mondig genoeg zijn om aan te geven wanneer ze (en wat) ze (dan) iets niet begrijpen. Ik doe alleen op voorhand geen aannames over het niveau, maar doe het, naar mijn huidige kennis en kunde, beste voorstel wat ik kan verzinnen.
Zie het in ieder geval niet als een sneer naar jouw toe.
Tot zover mijn mening verder waar ik blij blijf.
Gewijzigd op 28/01/2016 15:14:30 door - Ariën -
Het fijnste zou zijn, om alles in een php bestand te plaatsen zodat ik een simpel scherm krijg waar ik dus werknemers kan toevoegen en eventuele credentials aan te passen, zoals ik die heb aangemaakt in de werknemerstabel.
Ik weet niet of dit mogelijk is, of dat scripting zoals hier boven daar de makkelijkste manier voor is. Ik snap dat ik later iets moeilijker moet gaan denken, maar voor nu doe ik het graag op de simpelste manier.
Dit is niet eens een discussie meer want je blijft hangen in je aannames over:
- wat ik bedoel
- wat het niveau van de topicstarter is
- wat te moeilijk of te makkelijk zou zijn voor wie dan ook, zonder ook maar één regel code te hebben gezien
Tenzij je weet hoe ik "routing" wil toepassen kun je niet claimen dat dit te moeilijk zou zijn. Hetzelfde geldt voor OOP, dit kent vele verschillende moeilijkheidsniveaus.
Het lijkt mij ook de verkeerde instelling om mee te geven aan beginners: al opgeven voordat je uberhaupt iets geprobeerd hebt.
Als de topicstarter het heeft over "(gebruikers)interface" en een database-tabel die redeljk hout snijdt (behalve wellicht het ontbreken van een e-mailadres) dan denk ik niet dat deze gillend wegrent als ik het heb over "routing". Ik durf te wedden dat deze tot op zekere hoogte wel kan doorgronden wat deze abstracte term in zou kunnen houden, en dat is al genoeg om een begin te maken.
Gewijzigd op 28/01/2016 15:23:03 door Thomas van den Heuvel
Je moet dan zelf de lay-out schrijven waarin je dan de gebruikers kan beheren.
Maar bereid je vast voor op het herschrijven van deze code op het moment dat blijkt dat het moeilijk zoniet onmogelijk wordt om deze te onderhouden/te wijzigen doordat weinig aandacht is besteed aan het ontwerp van de opzet.
Sommige mensen vinden het nu eenmaal fijn om meteen te gaan rennen als iemand een commando blaft, maar ik denk liever na voordat ik begin te lopen, in plaats van mij halverwege te realiseren dat ik toch de verkeerde kant op aan het rennen ben / gestuurd ben.
Geert Janssen op 28/01/2016 11:23:09:
Dit type interface noemen we een CRUD (Create, Read, Update and Delete). Je hebt namelijk al een create (C), read (R) en delete (D), maar moet nu nog de update (U) toevoegen. Ik kan een overzicht geven van de inhoud (index.php), Ik kan een item toevoegen (add.php), wijzigen (edit.php) en verwijderen (delete.php).
Nu moet ik een interface bouwen, waarbij wij de tabel werknemers mee kunnen onderhouden. […] Nu is het de bedoeling dat ik een of meerdere php bestanden maak waarmee ik deze tabel kan onderhouden.
Nu moet ik een interface bouwen, waarbij wij de tabel werknemers mee kunnen onderhouden. […] Nu is het de bedoeling dat ik een of meerdere php bestanden maak waarmee ik deze tabel kan onderhouden.
Dit systeem kun je zonder veel moeite OOP bouwen, dat ben ik wel met Thomas eens. Daarbij kun je echter tevens de aanpak van Ariën volgen, want de CRUD wordt eenvoudigweg dé vier standaardmethoden van het model (M) in een MVC-structuur (model-view-controller). Waar je taken nu delegeert aan aparte bestanden (zoals add.php), kun je alles via één controller dirigeren. En waar je overzichten toont via index.php, gebruik je tot slot een of meerdere views.
Ariën en Thomas lijken het haast fundamenteel oneens, maar ik zie hier eigenlijk vooral overeenkomsten. ;)
Maar dit is het beginnersforum, dus je mag hier blijkbaar niet verwachten dat mensen hun verstand (proberen te) gebruiken.
En MVC, dat is al helemáál een brug te ver hiero. Beter om een switch-statement te gebruiken. Als je dan ergens een foutje maakt, breekt mogelijk meteen alle functionaliteit. Word je ook gedwongen om dit meteen weer op te lossen toch? Hieromheen fluf je dan nog wat HTML als syntactic sugar om het toch het voorkomen van een valide HTML-document te geven. En wat nou als je halverwege de uitdraai van een HTML-document bent in een verwerkstap, als je iemand dan toch wil redirecten zet je toch output buffering aan? Ik bedoel, waarom zou je je uberhaupt nog verdiepen in hoe iets werkt als je gewoon alles in één keer onder het tapijt kunt vegen nietwaar?
Je zou je ook moeten laten beperken in je keuze door het (vermeende) niveau van de vragensteller en niet denken in termen van structurele(re) oplossingen of
Je geeft bijvoorbeeld aan om een werknemer toe te voegen, hoe begin ik daar aan? Ik snap dat voor jullie een hele lay-out schrijven te veel werk is, of niet mogelijk is zonder de rest van de source.
Maar ik kan het maar beter vragen denk ik zo!
Lijkt me beter dat je aan de tabel het veld datum uit dienst & reden uit dienst toevoegt eventueel met een link naar het personeelsdossier.
De reden is dat je als werkgever wettelijk 10 jaar verplicht bent om de informatie op te slaan i.v.m. de wwz.
Het is doenlijk, alleen heb je goed na te denken hoe of je het geheel opzet, crud & mvc zijn niet nodig, hou het alleen zo simpel mogelijk & ja ik ben ook een fan van de Unix filosofie, liever iets dat slechts 1 ding iets kan dan veel dingen die niets kunnen......
Gewijzigd op 29/01/2016 06:34:31 door Yoop Overmaat
Code (php)
1
2
3
2
3
<?php
// Bij sterke voorkeur in de database markeren als 'verwijderd' (0 of 1).
?>
// Bij sterke voorkeur in de database markeren als 'verwijderd' (0 of 1).
?>
Dit is vaker een goede strategie, omdat je dan altijd informatie terug kunt halen.