Hoe maken jullie gebruik van de OOP-mogelijkheden in PHP? Maken jullie voor elke pagina een klasse aan, of maken jullie voor bepaalde dingen zoals een database, formulier enz een klasse en maken jullie van daar uit je website, of gebruik je het heel anders?
In 1 bestand.
Het is zeg maar een klasse forum met een stack. dat is een array van forumtitel en wat info + een array met alle categoriëen. al die categoriëen bevatten weer een array met topics.
Door nu de stack te serializen en bij het aanmaken van een forum weer te unserializen heb je maar 1 string als data en geen database nodig!
OOP zorgt ervoor dat je vlotter websites/applicaties kan maken. En daarop baseer ik mij. Het is wat simpel voorgesteld maar da's de kerngedachte altijd bij OOP.
Ik wil dus eigenlijk weten of jullie bijv. met een core-klasse werken; of of dat jullie voor elke pagina een klasse maken (module). Dus eigenlijk hoe jullie jullie klassen-systeem opbouwen.
Ik denk eerst me applicatie uit. Welke features heeft het. Daarna bedenk ik hoe ik tewerk zal gaan, meestal is dat met classes. Daarna begin ik te denken waarvoor ik de classes ga gebruiken, want ze moeten het werk verlichten. Daarna begin je de classes te maken en daarna je applicatie.
Ik ben nu ook bezig (als ik tijd en zin heb) met classes te schrijven voor OCE3 en daarna begin ik aan het project zelf.
Framework is een grote bibliotheek met classes die het coderen makkelijker maakt voor de website onwikkelaar. Meestal zijn dat mini frameworks dan want als je je eigen framework moet maken ben je maanden bezig. Daarom als je toch een framework wilt gebruik, gebruik dan cakePHP of ZendFW.
Wat kan ik het beste doen? Ik heb nu verschillende klassen bedacht: database, parser, formulier, auth., enz. Kan ik deze dan het beste allemaal inladen in een 'core'-klasse en dan vanuit de core-klasse mijn website opbouwen of...?
dat klopt. Een ander probleem is dat iedere keer alles ingeladen wordt. dus ook alle topics die niet gebruikt worden. maar goed dat moet iemand tegen die tijd maar testen.
Ibrahim - 18/03/2007 19:50 (laatste wijziging 18/03/2007 19:50)
PHP expert
En dat telkens inladen gaat ook wat tijd kosten als het uitgroeit tot een groot forum
Misschien moet je maar eens caching nabouwen zodat het werkt met arrays.
Ik snap eigenlijk helemaal niet waarom je een class zou gebruiken >.<
Ik gebruik nu gewoon functies (bijv : weergeef_klantid , prijs , checkLogin etc) en op elke losse php pagina maak ik gewoon een script die gebruik maakt van die functies.
@marten: ja dat stond erin (is nu: no tolerance for nubs ). Maar het MVC pattern is wel mooi in theorie maar het snappen en uitwerken ervan is niet zo simpel.
Ik heb dat idee van ikkedikke een keer toegepast, exact hetzelfde, ongeveer een jaartje geleden. Het is helemaal niet zo moeilijk te gebruiken en alle applicatielogica zit in de klassen. Je moet gewoon hier en daar wat logische aanroepen hebben.
Het grote nadeel daarvan is dat je bestand na een tijd immens groot gaat worden, en je dus onnodige informatie ook gaat ophalen. Daarvoor is er dan indeling in verschillende bestanden nodig wat het heel verwarrend maakt.
Hoe het werkt (alleszins hoe ik het heb laten werken) is via __destruct in de forum klasse. Die dan automatisch wegschrijft naar het bestand (serialize($this)) zodat je geen gezeik op het einde hebt.
Wat ook belangrijk is, is dat je een goed onderscheid maakt tussen je framework en je (mogelijke) MVC klassen. Je model zal (bijna altijd (ik kan me geen situatie voorstellen waar het niet zo is)) een klasse zijn, je controller kan een klasse zijn, en als je heel scheef werkt kan je zelfs van je view een klasse maken (een zelfstandige dan, niet zoals bij Zend Framework, waar de view in de Zend_View klasse wordt geïnclude). Deze models en controllers dan horen niet thuis bij je framework. Een framework is statisch zegt maar, en er zal niet per module een klasse bijkomen, maar per functionaliteit.
Bij hetgeen ik nu mee bezigben (we zullen de naam maar niet vermelden, maar iedereen weet waarover ik het heb) zijn vooral een security, een template, een model, een user (een parent-model), een authenticatie (loopt hand in hand met de security klasse en de user klasse), een inputvalidator en een core klasse de belangrijkste onderdelen van het framework. Er zijn dan nog een dozijn andere klassen die niet op bijna elke pagina worden gebruikt maar die wel handig zijn.
Ja, dat dachten ze x jaar geleden ook toen ze dat gingen doen. Echt een leuk ideetje, maar enorm traag. Een database is nog altijd sneller hoor. Ik las eens een artikel van een webdesignbedrijf die de opdracht kregen om een website met xml-database te maken. Hadden ze dat gedaan. Bleek de website enorm traag te zijn. Hadden ze tests gerunned en de website omgegooid. Gelukkig voor hen hadden ze deftig gebruik gemaakt van een DAL en konden ze door slechts enkele files aan te passen de xml-database veranderen door een simpele MySQL 4 database. Bleek dat het 83% sneller ging. Echt waar, een xml-database is een grap dat ooit mooi leek wegens leesbaarheid van zowel computer en mens. Maar dan denk ik, sla het op in een formaat dat voor de computer leesbaar is en retesnel te verwerken is, en laat software zoals Access het omzetten zodat het voor de mens leesbaar is. Zodat het lezen van de database (iets wat zelden nodig is) eenvoudiger is met dezelfde (of mogelijk zelfs snellere) snelheid dan met een xml-database.
En hoedanook, zal opdeling in vele textfiles sneller zijn dan 1 gigantisch xml-bestand. Wat denk je dat sneller is: een geserializeerde string opslaan in een txt-bestand of naar een xml-bestand schrijven (en het lezen ervan) via vele tags?
mmm, ik dacht dat XML sneller ging zijn. Dus het besluit is dat XML een mooi ding is voor kleinere dingen. Maar euh zal serialize altijd dezelfde string lengte terug geven bij een file van zeg maar 15MB?
XML is een mooi formaat om data uit te wisselen tussen 2 verschillende applicaties. Maar het is totaal ongeschikt om data op te slaan voor regulier gebruik.
Wij gebruiken nu ook XML op school met een opdracht. We krijgen een 22.000-regelige XML file van school aangeleverd met de roosters. Die XML trekken wij uit elkaar en genereren hiermee een set van instructies om in te voeren in Exchange. Die zetten we weg in XML. Die XML wordt dan weer ingeladen door een ander deel van ons programma die dan ook daadwerkelijk die acties uitvoert.
Dus het besluit is dat XML een mooi ding is voor kleinere dingen. Maar euh zal serialize altijd dezelfde string lengte terug geven bij een file van zeg maar 15MB?
Ja, omdat het een encryptiemethode is, en geen hash of dergelijke.
XML is, zoals Proximus zegt, handig om data uit te wisselen tussen 2 verschillende applicaties ZONDER er layout rommel te hebben tussenstaan. Dat is het idee achter XML-RPC, SOAP, REST, RSS, e.a.
Wat is jouw favoriete javascript framework? (S: 18, R: 2)
Gesponsorde links
zodat het werkt met arrays.
Actiefste leden van de maand
