[PHP] Formulier generen vanuit tabel (en v.v.)

[Xanland]

Dag mede-GoT'ters,

Op dit moment ben ik al jaren bezig, laten we zeggen - zo rond 2006, met een eigen CMS in de scriptingtaal PHP met een MySQL database.

Nu ik druk bezig ben met adminpagina's zijn er veel formulieren nodig. Denk dan aan dingen voor het aanmaken van een pagina, wijzigen van een gebruiker of een nieuws-item wijzigen. Noem maar op, en je hebt vaak wel een formulier nodig.
Naar aanleiding daarvan heb ik een functie geschreven die bijvoorbeeld een tabel neemt, en gaat kijken naar de velden. Is het bijvoorbeeld een varchar, een int, text of toch een enum. Aan de hand daarvan bouwt hij een formulier op, die ik kan gebruiken via een functie.

Zelf is het wel handig, maar je bent ook even bezig (inmiddels 170 regels lange functie, rest is deels geschreven met een denkvermogen van toen ik 13 was ) en je moet met van alles rekening houden. Wachtwoordvelden kunnen niet zomaar, die moet je dan ook weer aanpassen, of denk aan het afhandelen van errors en dergelijke. Als je het handig wilt doen, moet je hem ook zo schrijven dat je kan inserten, maar ook updaten.

Hoe doen jullie nou zoiets...?

Daarnaast moet de klant uiteraard ook zelf een formulier kunnen maken. Dat kan via 2 manieren, vaak zit zoiets in een texteditor, bijv CKEditor, ingebouwd, maar ook kan het via een, jawel, formulier. Zelf prefereer ik de eerste optie, niet de slimste al zeg ik het zelf, om het lekker simpel voor de klant te houden en het zit er al in. Dan krijg je het probleem van een database, dan moet je zelf weer een tabel gaan maken e.d. Dan zou je dus aan een omgekeerde functie als hierboven kunnen denken, die checkt of de tabel al bestaat en dan iets maken.

Inserten van data gaat dan ofcourse wat makkelijker, aangezien het meeste al bekend is. Zelf heb ik hier nog niet over nagedacht, maar ben wel van plan zoiets te maken. Wederom dan ook hier weer de vraag:

Wat voor controle wil je over zoiets houden...?

[Voor 28% gewijzigd door Xanland op 06-07-2011 00:26]

[RobIII]

Xanland schreef op woensdag 06 juli 2011 @ 00:09:
(inmiddels 170 regels lange functie)

...en daar stopte ik met lezen. Functies van 170 regels lang wijzen op een (zacht uitgedrukt) karig opgezet stukkie software. Verder zie ik, tbh, niet wat je nu van ons verwacht. Zoiets kun je op 1001 manieren aanpakken; er is geen "juiste" manier (maar er zijn wel een heleboel "foute" manieren ).

edit: en verder wat mithras hieronder zegt.

[Voor 29% gewijzigd door RobIII op 06-07-2011 00:30]

[mithras]

Handmatig

Een form is een object welke je zelf definieert aan de hand van de user interface. De modellen die erachter schuil gaan en daarmee hoe ze opgeslagen zijn in de database slaat niet altijd 100% op de user interface.

Uiteraard is het wel mogelijk om de formulieren te populaten met data vanuit de domein models als je bepaalde data wilt wijzigen. Maar de algemene conclusie bij ons is dat wel het zelf bouwen. Op zich gaat dat eenvoudig met Zend_Form. Er bestaat uiteindelijk wel nog een formbuilder die een Zend_Form kan genereren op basis van een Doctrine model, maar wij merken met onze custom webapps dat er te vaak een afwijking zit tussen wat je als systeemarchitect aan modellen opbouwt en wat een UX designer aan formulieren ontwerpt.

Xanland schreef op woensdag 06 juli 2011 @ 00:09:
Zelf is het wel handig, maar je bent ook even bezig (inmiddels 170 regels lange functie) en je moet met van alles rekening houden. Wachtwoordvelden kunnen niet zomaar, die moet je dan ook weer aanpassen, of denk aan het afhandelen van errors en dergelijke. Als je het handig wilt doen, moet je hem ook zo schrijven dat je kan inserten, maar ook updaten.

Wat betreft errors: validatie en filtering van je formulier input zijn in essentie andere zaken dan het formulier zelf. Ik zou ook nooit in je form objecten je validatie chain gaan bouwen, dat kan je beter scheiden in verantwoordelijkheden.

Tot slot: inserten en updaten zijn database gerelateerde zaken en behoren óók niet toe aan een formulier. Of je met form input nu een database mutatie aanmaakt, een email stuurt, het wegschrijft naar een bestand of helemaal niets doet: het is niet meer het pakkie an van een form instance. Ik zou dat ook lekker aan je controllers overlaten

[alienfruit]

RobIII schreef op woensdag 06 juli 2011 @ 00:17:
...en daar stopte ik met lezen. Functies van 170 regels lang wijzen op een (zacht uitgedrukt) karig opgezet stukkie software. Verder zie ik, tbh, niet wat je nu van ons verwacht. Zoiets kun je op 1001 manieren aanpakken; er is geen "juiste" manier (maar er zijn wel een heleboel "foute" manieren ).

Interessante insteek. Ik heb ook meerdere functies van 170 regels. Met name in unit tests. Ik zie het probleem niet echt.

[RobIII]

alienfruit schreef op woensdag 06 juli 2011 @ 08:46:
Met name in unit tests

Unit tests zijn daar nog wellicht een uitzondering op, maar functies van 170 regels horen niet voor te komen (of über-zeldzaam te zijn). Er staat nergens dat een functie max. 30 regels mag zijn ofzo, maar met het kort houden van functies hou je ze overzichtelijk en begrijpelijk. Code die meerdere "pagina's" beslaat is vaak lastig te begrijpen wanneer je op "pagina 3" aan 't lezen bent terwijl variabelen bovenaan de functie gedeclareerd werden om maar iets te noemen. Het duidt ook vaak (niet altijd) op functies die veel meer verantwoordelijkheden hebben dan ze aan de oppervlakte lijken te hebben (of je functies heten CalculateTotalForInvoiceAndUpdateRecordsInDatabaseAndWhileWereAtItWeGenerateThePDFAlso() )

quote: http://book.chinaunix.net...2327201/ch20lev1sec2.html

As a rule of thumb_{(en dus geen harde regel! [red.])}, functions should not exceed one or two screens of text and should have fewer than ten local variables. A function should do one thing and do it well. There is no harm in breaking a function into a series of smaller functions.

Nogmaals; het is geen "harde regel" maar wel een over het algemeen geaccepteerde 'instelling' 170 regels code (met uitzondering van zeldzame gevallen) zijn zelden tot nooit nodig. I.c.m. met de rest van de topicstart en jarenlange ervaring en een gut-feel die meestal juist blijkt te zijn heb ik een aardig idee hoe die functie eruit ziet; in die 170 regels wordt de tabel opgehaald, de velden bekeken voor hun type, wordt over de velden geïtereerd en wordt het formulier gegenereerd met een switch op veldtype om te bepalen welke input element er uitgepoept moet worden.

[Voor 40% gewijzigd door RobIII op 06-07-2011 09:37]

[Anoniem: 96523]

Hoewel een script die automatisch formulieren aanmaakt adhv een database tabel erg mooi is, is het vaak niet praktisch. Er zijn te veel uitzonderingen waar je geen rekening mee kunt houden; met name bij validatie van de input is het onmogelijk om dit te doen, tenzij je dit (op een smerige manier) aangeeft in de kolomnaam.
(wachtwoorden 2x invoeren, textarea of html editor, etc.)

Het word overigens wel veel gebruikt bij prototyping (zoals in CakePHP), maar zoals de naam het al zegt is het alleen om te testen of je database structuur klopt.

Zelf heb ik een FormGenerator (class) waarbij ik zelf aangeef welke velden er getoond en bewerkt moeten worden. Uiteraard zit er wel een controle in om te kijken of de velden ook echt in de tabel voorkomen (alleen in debug mode) of dat ik velden vergeet.

Nu hoef ik alleen maar een stukje code als deze te schrijven voor een formulier:

PHP:

$form = new FormGenerator('users'); // tabelnaam
$form->input('Gebruikersnaam', 'username', true);  // label, kolomnaam, verplicht?
$form->password('Wachtwoord', 'password', true);
$form->render();

[Voutloos]

Anoniem: 96523 schreef op woensdag 06 juli 2011 @ 10:10:
met name bij validatie van de input is het onmogelijk om dit te doen, tenzij je dit (op een smerige manier) aangeeft in de kolomnaam.

Of gewoon Model code hebt.

[Cartman!]

Volgens mij doet Zend_Form wat je wilt, zelf ben ik er niet kapot van maar misschien vind jij het heel handig.

[Y0ur1]

Je kan ook eens naar het Form component kijken van Symfony, deze is ook los te gebruiken.