inleiding
Zo'n twee weken spookt er een plan door mijn hoofd. De mensen met wie ik het idee besproken heb, hebben me voor gek verklaard, maar ik denk dat het idee te verwezelijken is.
Welke programmeur baalt er niet als een stekker van om voor relatief eenvoudige projecten iedere keer dezelfde handelingen te verrichten. Ik heb zelf een aftreksel van het MVC framework Mojavi gemaakt voor PHP 4 (Model, View, Controller, FilterCain die de ExecutionFilter aanroept, User profielen voor het opslaan van temporary data). Kortom heel lichtgewicht. Het framework regelt alleen dingen voor je, voor de rest niet.
Ik merk gewoon dat ik voor bepaalde dingen constant hetzelfde doe; copieer Model classes, wijzig wat namen, pas wat parameters aan, copieer een view, wijzig de bestandsnaam en classnamen, verander wat parameters, kopieer een view template en pas die wat aan en klaar is Kees; je nieuwe action werkt. Hier word ik dus moe van. Het uitdenken en opzetten van een architectuur is vele malen leuker dan het implementeren ervan.
Het idee
Toen kwam het idee in mij op: waarom niet een programma schrijven die een architectuur specificatie inleest en zelf de Object Georienteerde PHP code genereert? Toen ik dit aan een aantal mensen vertelde, lachten ze me uit. Ik denk alleen dat het best haalbaar is in situaties waar je vaak een statische layout heb: de beheerkant van het systeem.
Doel van dit topic
Ik wil hier een discussie starten over dit idee. Ik vraag me af hoe anderen hier tegen aan kijken. Zien jullie mogelijkheden? Hebben jullie ideeen? Kennen jullie dit idee al vanuit de praktijk?
Toen ik wat vooronderzoek ging doen op Google kwam ik op een site uit die al enigsinds aan code generatie doet. Alleen wordt het een grote spaghetti code die niet mooi OOP gestructureerd is. Aangezien software niet alles kan, maar wel 80% (er zijn immers altijd uitzonderingen) is OOP haast een must.
Mijn gedachtengangen
OOP is een must zoals hiervoor al gezegd is. Ik wil een specificatie maken waarin ik de database structuur kan beschrijven inclusief de onderliggende relaties. Of ik gebruik wil maken van OR mapping mbv Propel is nog niet duidelijk en eigen ook maar een invulling van het systeem.
Wanneer je database structuur duidelijk is wil je je Actions en Modules gaan beschrijven. Dit is de meest ingewikkelde stap. Elke situatie is immers anders en in sommige gevallen wil je andere Views dan in andere gevallen.
vb. Stel je het een eenvoudig probleem: categorien, nieuwsberichten, reacties. Voor het toevoegen van nieuwsberichten kunnen er een aantal dingen aan de hand zijn. Als eerste is het van belang dat de cardinaliteit van je categorien bekend is; in sommige gevallen heb je slechts een handjevol categorien en kan je bij het toevoegen van je nieuwsbericht een dropdown gebruiken. In andere gevallen is je categorie structuur dusdanig complex dat je eerst moet navigeren naar de categorie, waarna je er een bericht in kan plaatsen.
Je moet dus verschillende soorten Views hebben en kunnen gebruiken. Het beschrijven van je architectuur zal in XML gebeuren en ik heb een eerst idee gemaakt voor een opzet.
Dit model is alles behalve perfect. Het is ook een eerste opzet en ik ben er van overtuigd dat er problemen zullen optreden. Het idee is dus dat dit bestand geparsed worden en dat aan de hand hiervan alle PHP code gegenereerd wordt als Base classes;
Bevat alle gegenereerde code:
class BaseOverviewProductAction {}
Extension waarin je de uitzonderingen kan programmeren:
class OverviewProductAction extends BaseOverviewProductAction {}
Schiet mij maar lek...
Zo'n twee weken spookt er een plan door mijn hoofd. De mensen met wie ik het idee besproken heb, hebben me voor gek verklaard, maar ik denk dat het idee te verwezelijken is.
Welke programmeur baalt er niet als een stekker van om voor relatief eenvoudige projecten iedere keer dezelfde handelingen te verrichten. Ik heb zelf een aftreksel van het MVC framework Mojavi gemaakt voor PHP 4 (Model, View, Controller, FilterCain die de ExecutionFilter aanroept, User profielen voor het opslaan van temporary data). Kortom heel lichtgewicht. Het framework regelt alleen dingen voor je, voor de rest niet.
Ik merk gewoon dat ik voor bepaalde dingen constant hetzelfde doe; copieer Model classes, wijzig wat namen, pas wat parameters aan, copieer een view, wijzig de bestandsnaam en classnamen, verander wat parameters, kopieer een view template en pas die wat aan en klaar is Kees; je nieuwe action werkt. Hier word ik dus moe van. Het uitdenken en opzetten van een architectuur is vele malen leuker dan het implementeren ervan.
Het idee
Toen kwam het idee in mij op: waarom niet een programma schrijven die een architectuur specificatie inleest en zelf de Object Georienteerde PHP code genereert? Toen ik dit aan een aantal mensen vertelde, lachten ze me uit. Ik denk alleen dat het best haalbaar is in situaties waar je vaak een statische layout heb: de beheerkant van het systeem.
Doel van dit topic
Ik wil hier een discussie starten over dit idee. Ik vraag me af hoe anderen hier tegen aan kijken. Zien jullie mogelijkheden? Hebben jullie ideeen? Kennen jullie dit idee al vanuit de praktijk?
Toen ik wat vooronderzoek ging doen op Google kwam ik op een site uit die al enigsinds aan code generatie doet. Alleen wordt het een grote spaghetti code die niet mooi OOP gestructureerd is. Aangezien software niet alles kan, maar wel 80% (er zijn immers altijd uitzonderingen) is OOP haast een must.
Mijn gedachtengangen
OOP is een must zoals hiervoor al gezegd is. Ik wil een specificatie maken waarin ik de database structuur kan beschrijven inclusief de onderliggende relaties. Of ik gebruik wil maken van OR mapping mbv Propel is nog niet duidelijk en eigen ook maar een invulling van het systeem.
Wanneer je database structuur duidelijk is wil je je Actions en Modules gaan beschrijven. Dit is de meest ingewikkelde stap. Elke situatie is immers anders en in sommige gevallen wil je andere Views dan in andere gevallen.
vb. Stel je het een eenvoudig probleem: categorien, nieuwsberichten, reacties. Voor het toevoegen van nieuwsberichten kunnen er een aantal dingen aan de hand zijn. Als eerste is het van belang dat de cardinaliteit van je categorien bekend is; in sommige gevallen heb je slechts een handjevol categorien en kan je bij het toevoegen van je nieuwsbericht een dropdown gebruiken. In andere gevallen is je categorie structuur dusdanig complex dat je eerst moet navigeren naar de categorie, waarna je er een bericht in kan plaatsen.
Je moet dus verschillende soorten Views hebben en kunnen gebruiken. Het beschrijven van je architectuur zal in XML gebeuren en ik heb een eerst idee gemaakt voor een opzet.
XML:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
| <architecture> <!-- Views gedefinieerd met de voor hun bestemde beperkingen variabelen. In je systeem is er dus voor elke View een aparte implementatie die elke View anders behandelt. --> <views> <view name="default"> <constraints /> </view> <view name="all"> <constraints> <constraint name="display" value="horizontal" /> </constraints> </view> <view name="paging"> <constraints> <constraint name="limit" value="20" /> <constraint name="display" value="vertical" /> <constraint name="order" value="title" /> </constraints> </view> <view name="limit"> <constraints> <constraint name="limit" value="10" /> <constraint name="display" value="horizontal" /> <constraint name="order" value="title" /> </constraints> </view> </views> <!-- enkelvoudige categorien,dus geen boomstructuur met parents --> <module name="category" cardinality="small"> <actions> ... </actions> </module> <module name="product" cardinality="small"> <actions> <action name="Overview" view="paging"> <paging /> <overview> <datagrid> <!-- format geeft het formaat aan en dus welke GUI component er gebruikt moet worden. Insert staat default op Manual, maar er is ook voor elk format een auto; de waarde wordt automatisch door het systeem ingevuld. --> <attribute name="product_id" format="primary" insert="auto" /> <attribute name="date" format="date" insert="auto" /> <attribute name="category.name" format="default" /> <attribute name="title" format="default" /> <attribute name="photo" format="image" /> <attribute name="price" format="price" /> </datagrid> </overview> <paging /> </action> <action name="Insert"> <insert view="default"> <datagrid> <attribute name="product_id" type="primary" /> <attribute name="category.name" type="dropdown" /> <attribute name="title" format="text" /> <attribute name="photo" format="file" /> <attribute name="price" format="text" /> </datagrid> </insert> <!-- Geef onder je invoervelden een overzicht van de laatste 10 ingevoegde berichten --> <import action="Overview" view="limit" /> </action> </actions> </module> </architecture> |
Dit model is alles behalve perfect. Het is ook een eerste opzet en ik ben er van overtuigd dat er problemen zullen optreden. Het idee is dus dat dit bestand geparsed worden en dat aan de hand hiervan alle PHP code gegenereerd wordt als Base classes;
Bevat alle gegenereerde code:
class BaseOverviewProductAction {}
Extension waarin je de uitzonderingen kan programmeren:
class OverviewProductAction extends BaseOverviewProductAction {}
Schiet mij maar lek...
[ Voor 11% gewijzigd door Verwijderd op 04-07-2005 12:50 ]
:strip_exif()/u/13818/episodebutler_60x60.gif?f=community)
