[PHP] Architecture/Project Opzet/Structuur

[Config]

Ik wil graag een discussie starten over het analyseren, ontwerpen en implementeren van (erg) grote PHP projecten. Op tutorialsites, fora en zelfs in de PHP boeken vind ik eigenlijk alleen maar wat PHP syntax, wat technieken zoals sessions, cookies en uploaden, en vervolgens 300 pagina's function reference. Ik heb meerdere van zulke boeken heb doorgewerkt, en tientallen zo niet honderen articles gelezen over PHP/MySQL, maar ik kan maar geen goede methode vinden om je PHP projecten echt uniform te schrijven, zodat ze scalable en makkelijk onderhoudbaar zijn.

Dit moet dus een combinatie van Database (met PEAR), PHP Classes, PHP function libraries, XML/XHTML, CSS(2), en Smarty templates combineren/overtreffen .

Ik zoek gewoon de allerbeste methode om grote projecten te realiseren. En dan heb ik het over sites die ingewikkelder zijn dan T.net, die bestaat slechts uit databasewerk. Ik doel vooral op e-commerce oplossingen, waar zomaar even tussendoor een special moet kunnen worden neergezet, zonder ingewikkeld DB/PHP werk. Maar het moet geeeen zootje worden!

Ik ben best bereid een prijzig boekje hiervoor te kopen, maar ik heb geen idee welke . En ik wil wel weten dat het een goede is natuurlijk .

Verder zijn alle ervaringen/ideeën welkom, vergezel je verhaaltje als het even kan met een schema oid (zo'n mooie uit MS Paint ).

[kvdveer]

stap 1: vergeet het. PHP is een dusdanige puinhoop dat iets groots schrijven onmogelijk gestructureerd kan, er zijn geschiktere frameworks. (.net, j2ee). PHP is bedoeld voor kleine projecten (personal home page), en voldoet daar.

stap 2: Modeleer zo ver mogelijk. In mijn CMS (bedoeld voor 10-1000 pagina's tekst, met weinig interactie) worden alle verschillende soorten pagina's andere klassen. Die objecten sla ik geserializeerd op in de database. Uiteraard heb ik een sql-layer, een sessieklasse en een skin-klasse.

Stap 3: Wees tevreden met beperkte unoformiteit... Bedenk het zelf maar: hoe kun je in vredesnaam uniform programmeeren in een taal waar de ene functie ksort() heet, en de andere array_push(), waar de volgorde van de argumenten schijnbaar willekerig is, en waar de sourcecode commentaren bevat als: "Without this it doen't compile, no idea what it does"...

[Anoniem: 45185]

kvdveer schreef op 27 oktober 2002 @ 16:20:
stap 1: vergeet het. PHP is een dusdanige puinhoop dat iets groots schrijven onmogelijk gestructureerd kan, er zijn geschiktere frameworks. (.net, j2ee). PHP is bedoeld voor kleine projecten (personal home page), en voldoet daar.

Jah, vergeet dat inderdaad maar.
Je bepaald *zelf* hoe gestructureerd je programmeerd, en als je dat niet / niet goed kan dan is dat jammer.

[Sybr_E-N]

Config schreef op 27 oktober 2002 @ 16:02:
Ik zoek gewoon de allerbeste methode om grote projecten te realiseren. En dan heb ik het over sites die ingewikkelder zijn dan T.net......

Btw de allerbeste methode bestaat niet.

Ik denk dat je een project al moet splitten in code en lay-out. Door middel van classes en templates.

[Config]

Hmm ja dat splitten van code en layout gaat met dingen als XML, een Database layer, etc.

Het zit zo: ik moet een groot ingewikkeld (en zeer brak) CMS van een grote bestaande e-commerce site compleet opnieuw gaan bouwen voor mijn stage. Ik begin daar over enkele maandjes aan. Ik heb echt zo'n droom CMS voor me zeg maar , waar je alles kan doen, dat heel uniform is en enorm goede documentatie etc, je kent het wel . Ik wil gewoon met een mooi produkt kunnen komen, waarmee ik laat zien dat die informatie analyse lessen op school niet voor niks zijn geweest. Maar het is erg moeilijk idd om met PHP iets te structureren. Maar ik denk dat het WEL mogelijk is. Bijv. dit artikeltje van Zend: http://www.zend.com/zend/tut/tutsweatpart1.php. Alleen ik vind dat niet genoeg zeg maar, ik wil meeer meeer meeeeeer structuur, documentatie, code, templates, etc.

[Config]

Jongens...ik wil niet moeilijk doen, maar is hier echt niet meer interesse voor? Ik ben een tijdje niet zoveel in dit forum geweest, maar is dit dan toch echt een scriptrequest forum geworden? . Zitten hier geen ervaren developers die hun mening kwijt moeten omtrent dit onderwerp?

[Anoniem: 9930]

Ik denk dat je zoiets niet vast kunt leggen in een boek, maar dat dat meer een persoonlijk ontwikkelde ervaring is. Waarvoor je deze kennis nodig hebt weet ik niet, maar als het voor persoonlijke doeleinden is dan zou ik gewoon beginnen aan een/het project en wat proberen. Zelf ben ik momenteel actief bezig om een forum te ontwikkelen, maar ik ben al drie keer opnieuw begonnen omdat ik voor ik begon niet duidelijk op papier had wat ik nu eigenlijk van plan was qua features etc.

[Config]

Zoals ik al had gezegd , is het voor een stage opdracht...

Maar ik PHP al wat jaartjes, en ik moet zeggen ik ben perfectionist op dat gebied, en ik 'geil' gewoon op de Perfecte CMS.

[PhoneTech]

Config schreef op 27 oktober 2002 @ 23:18:
Jongens...ik wil niet moeilijk doen, maar is hier echt niet meer interesse voor? Ik ben een tijdje niet zoveel in dit forum geweest, maar is dit dan toch echt een scriptrequest forum geworden? . Zitten hier geen ervaren developers die hun mening kwijt moeten omtrent dit onderwerp?

<rantmode>
Ervaren developers programmeren niet in PHP
<rantmode>

[Config]

PhoneTechnician schreef op 28 oktober 2002 @ 00:25:
[...]


<rantmode>
Ervaren developers programmeren niet in PHP
<rantmode>

Vind je? Kijk naar dit forum en T.net, php is geen kindje hoor .

But for the sake of argument: wat stel jij dan voor? JSP? ASP? (niet dat dat het gaat worden, maar gewoon for the sake )

[PhoneTech]

hehe...was ook een complete rant hoor! Maar wat ik voor stel om websites op enterprise niveua te gaan maken? iig een framework dat daar ook aan voldoet! Kijk naar het .NET verhaal van Microsoft of naar J2EE van Sun.

Zelf ben ik overgestapt naar ASP.NET met C#.
De overgang van ASP naar .NET is groot, maar eenmaal genomen zou ik niet meer terug willen!

Dan is het ook logisch dat ik ASP.NET voorstel

[Config]

Hehe, ja misschien leuk voor mijn afstudeeropdracht ofzo . Maar ik kan niet bij mijn stage bedrijf aankomen zetten met een taal die oneindig veel meer kost , en die ik zelf geeneens kan .

Maar ok ik weet wel dat de alternatieven die je noemt goed zijn, maar die kan je OOK opfucken hoor. Het ligt uiteindelijk toch aan je eigen werk, je structuur in de files/functies/classes/db etc.

[Anoniem: 45185]

Nou zal ik dan maar een aanzet geven:
De laatste dingen die ik gemaakt heb, heb ik volgens dit idee gedaan:

code:

[inc]
   [classes]
      mysql.class.php
      user.class.php
      session.class.php
   [content]
   application.config.php
   application.main.php
   application.eof.php
   functions.main.php

[template]
   [classes]
   theme.html.php

[web]
   index.php

In de dir web komt de aanvraag binnen, daar wordt de $content_type geset en application.main.php geinclude.
In application.main.php gebeuren de basis dingen, classes uit inc/classes includen, config file includen, rest includen, db connectie starten, sessie starten.
Daar wordt ook uit inc/content de file $content_type.inc.php geinclude, daar vinden berekeningen enz enz plaats
Daarna uit template de file $content_type.html.php geinclude, daar word de pagina opgemaakt.

Als laatste wordt theme.html.php geinclude, waar de inmiddels gevulde array $page is gevuld en daar word ge-echo't.

Dus alleen in de template directory staat html, en voor de rest nergens.

Ik zou zeggen, laten we dit idee bediscussiëren.

[ Voor 0% gewijzigd door Anoniem: 45185 op 28-10-2002 21:57 . Reden: kleine verbetering in de dir structuur ]

[Config]

Interessant idee NextGeneration .

Ik had het volgende in gedachte:

code:

Database (MySQL) 
             --> SQL Interface ---
                                |
                                |                 ------ Includes '/inc'
                                Processing ------ Classes '/classes'
                                |                 ------- Templates? '/templates'
                                |
                              XML
                                |
CSS 1 ---|                 |
CSS 2 ---|---------------> User Agent
XSL    ---|

- SQL Interface: set van php scripts die ALLE input/output met de database regelen. De PHP Processing mag de db nooit direct aanspreken. Gebruik PEAR voor de database connectie.

- Processing: De main php files. Classes en functies bevatten _geen_ layout code whatsoever. Puur het verwerken van functies en het maken van XML files.

- CSS en XSL code: Zorgen samen met XML voor de presentatie aan de user.

Ik hoop dat het een beetje duidelijk is , anders stel gerust een vraag.

[Anoniem: 45185]

Voor de database connectie gebruik ik mysql.class.php, die maakt de connectie etc.
Als ik dan dus een query uitvoer gaat dat zo: $db->query( 'SELECT * FROM blaat' );
Op die manier is het erg makkelijk om verschillende connecties naast elkaar te draaien.

Wat betreft PEAR, ik heb het nog nooit gebruikt en ik heb er ook nog nooit naar gekeken.
Ook gebruik ik in geeneen van mijn php applicaties xml (tot nu toe gebouwt met deze structuur: Een CMS frontend (universeel, daar komt dan ook deze structuur vandaan), 2 e-commerce sites (maatwerk).

Over het processing zijn we het wel eens, alleen wil ik daar toch een kleine kanttekening bij maken, in de directory template/classes staat bij mij tot nu toe nog maar 1 class, maar dat zullen er later nog wel meer worden.
Tot nu toe staat daar een class die dropdown boxjes genereert (komt dus html in voor een daar staat ie ook in template).

Wat mij niet duidelijk is wat je bedoelt met XSL code (ik ken de term niet, dat zal het wel zijn )

[Nielsz]

XSL is een 'taal' die XML code kan converteren. Naar een ander formaat XML, of bijvoorbeeld HTML (handig!)

[Config]

XSL is idd de taal die de XML datafile kan beinvloeden, en op die manier converten naar bijvoorbeeld XHTML. Wat mij absoluut niet duidelijk is, is hoe je al deze technieken nou combineert. In die XML documentatie in de PHP handleiding heb ik 0% vertrouwen, het staat er ook zo 'beta' . De W3C documentatie wordt ik ook nooit wijzer van. Moet ik nou PHP files XML files on the fly laten creeeren, ELKE keer als die opgevraagd wordt? neej toch? dat zou minder zijn .

Hoe zit het met de compabiliteit van al die technieken? Kan IE5/IE6 XSLT showen?

[Anoniem: 24408]

Anoniem: 45185 schreef op 28 oktober 2002 @ 21:17:
Nou zal ik dan maar een aanzet geven:
De laatste dingen die ik gemaakt heb, heb ik volgens dit idee gedaan:

code:

[inc]
   [classes]
      mysql.class.php
      user.class.php
      session.class.php
   [content]
   application.config.php
   application.main.php
   application.eof.php
   functions.main.php

[template]
   [classes]
   theme.html.php

[web]
   index.php

toon volledige bericht

Heya, das grappig. Ik doe het min of meer op dezelfde manier

code:

     {pocessors}
           {configuratie}
           {scripts}
     {base}
          {templates}
          {images}
     {core}
          {serverconfig}
          {database}
          {functies}
          {classes}
          {filesystem}
          {errorreporting en logging}

Volgens mij is dit ook een zeer duidelijke manier. Zelf ben ik van mening dat je, als je wilt, best heel gestructurreerd kan php'en als je maar weet wat je doet. Het is waar dat de uniformiteit in de functienamen tekort schiet, maar lekker belangrijk. Gemierenneuk vind ik dat persoonlijk.

[Anoniem: 11646]

Voor een projectje heb ik wel eens het volgende gebruikt:

Een PHP class Page die samen met een class MenuItems een XML structuur maakt. Deze class riep ik dan boven elke PHP pagina aan. Via een speciale functie in die class kan ik dan contents toevoegen. Daarna werd dit via de transform functie door een XSLT file gehaald die er netjes HTML van maakt.

Hier een voorbeeld van de XML structuur:

PHP:

- <page>
- <header>
  <title>ArtGal online</title> 
  </header>
- <menuitems>
- <submenuitem>
  <caption>ga naar beginpagina</caption> 
  <linkto>index.php</linkto> 
  </submenuitem>
- <submenuitem>
  <caption>beheer eigen atelier</caption> 
  <linkto>login.php?target=atelier</linkto> 
  </submenuitem>
  </menuitems>
   <contents>
   </contents>
  </page>

De code voor het opbouwen van de andere contents zut kwam uit andere classes die via een getxml functie een XML string teruggaven. Via een aparte class werd de database aangesproken.

Persoonlijk vond ik deze methode erg fijn werken. Layout en code zijn gescheiden. XML structuur is makkelijk mee te werken en de databaselaag is makkelijk aan te passen.

[Anoniem: 32521]

Config schreef op 29 oktober 2002 @ 11:05:
Moet ik nou PHP files XML files on the fly laten creeeren, ELKE keer als die opgevraagd wordt? neej toch? dat zou minder zijn .

Je laat php eerder strings met xml-data genereren, net zoals je normaal html zou genereren.

Hoe zit het met de compabiliteit van al die technieken? Kan IE5/IE6 XSLT showen?

MS IE6 heeft een goede xsl-transformatie engine (5.5 iets minder), maar je kunt ook serverside mbv xslt html-output genereren, voor browsers die geen xsl-transformaties kunnen doen.
Je kunt bv een webdesigner een paar sample xml-files meegeven, waarvoor deze een mooie layout kan bouwen. De achterliggende xml-genererende code hoeft dan nog bij lange na niet af te zijn.

[Config]

Hehe dit lijkt er meer op , die filestructures zien er goed uit *taking notes*.

Mensen nog aanbevelingen voor boeken om PHP en XML te koppelen? Op BOL kan ik alleen "XML and PHP" vinden.

[Nielsz]

code:

index.php
* templates
      * stylenaam
        -index.tpl
        -item.tpl
* includes
  -sql.class.inc.php
* modules
   -react.module.inc.php