[PHP/(My)SQL] voor dummies - Deel 47

quote:

Op zaterdag 28 juli 2007 17:38 schreef qu63 het volgende:

[..]

loopt nog steeds niet hoor

Nu wel .

quote:

Op zaterdag 28 juli 2007 17:46 schreef WyriHaximus het volgende:

[..]

Nu wel .

quote:

Op zaterdag 28 juli 2007 17:48 schreef qu63 het volgende:

[..]

of toch niet:
Fatal error: Call to undefined function: sql_addslashes() in /home/wyrihaxi/domains/wyrihaximus.net/public_html/fok/wow/do_edit.php on line 42

Als het het via xml_parse doet en een event-driven afhandeling opzet, dan kan je relatief eenvoudig een stack met parent id's bijhouden toch, middels de open_element en close_element functies.

quote:

Op zaterdag 28 juli 2007 17:51 schreef qu63 het volgende:

[..]

of toch niet:
Fatal error: Call to undefined function: sql_addslashes() in /home/wyrihaxi/domains/wyrihaximus.net/public_html/fok/wow/do_edit.php on line 42

Dankje , gefixed nu . Nu ff wat onderhouds scripts draaien .

quote:

Op zaterdag 28 juli 2007 15:29 schreef WyriHaximus het volgende:

[..]

In mijn situatie is alles OO . Maakt het makkelijker en overzichtelijker om bepaalde blokken die iets doen (bijvoorbeeld mijn wow screenshots weergeven op verschillende manieren) appart te houden .

Dus om maar een voorbeeld van deze pagina te geven, elke smilie is een object, elke post is een object, en elk stukje GUI is een object? En elke keer als je de pagina opvraagt bouw je dat compleet op, waarbij de data uit een ODBMS komt?

quote:

Op zaterdag 28 juli 2007 19:12 schreef Geqxon het volgende:

[..]

Dus om maar een voorbeeld van deze pagina te geven, elke smilie is een object, elke post is een object, en elk stukje GUI is een object? En elke keer als je de pagina opvraagt bouw je dat compleet op, waarbij de data uit een ODBMS komt?

Zo OO nog niet. Ga wel die kant op . Heb gewoon een set classes die alles afhandelen (templates, database connectivitie, cache, configuratie). Dus om ff het zelfde voorbeeld te pakken: de viewtopic class haalt de data uit de database met een query via de database class haalt het bericht door de bbcode class (voor de bbcode en smilies) waarna het het door stuurt naar de template class voor de weer gave. Op die manier OO .

quote:

Op zaterdag 28 juli 2007 19:12 schreef Geqxon het volgende:

[..]

Dus om maar een voorbeeld van deze pagina te geven, elke smilie is een object, elke post is een object, en elk stukje GUI is een object? En elke keer als je de pagina opvraagt bouw je dat compleet op, waarbij de data uit een ODBMS komt?

Nee, zo moet je het niet zien.

Een OO applicatie bestaat idealiter uit 3 delen: model, view en controller.

Het model is alle data voor je applicatie, inclusief de interface om die data op te halen en te manipuleren. Je hebt daar bijv een Database class om te praten met je database. Het model zijn ook je objecten die opgebouwd worden uit / gebruik maken van die data, zoals bijv je Settings class, een Page classe, een User class etc.

De view is alles wat de gebruiker ziet, de output van je applicatie. Voor webapplicaties is dat meestal de template engine. De view is "dom", in de zin dat het gewoon weergeeft wat ie aangereikt krijgt en geen weet heeft van applicatielogica. Het is gewoon een object waar je variabelen aan hangt, en deze worden op de juiste plek in de html weergegeven.

Die applicatielogica zit in het controller gedeelte. Deze maakt de objecten uit het model aan, doet er het een en ander mee, en geeft ze door aan de view die het netjes op het scherm tovert. Alle gebruikersinvoer komt weer bij de controller terecht die er weer op reageert. Het is zeg maar de tussenpersoon tussen gebruiker en data.

OO programmeren betekent niet dat je over *alles* als objecten gaat denken, in het geval van Fok is elke post gewoon een grote string die in de database staat. De smilies zijn geen aparte objecten maar gewoon deel van die string.
Het is meer dat je je applicatie opdeelt in de essentiele bouwblokken, voor deze onderdelen definieer je eigenschappen en methodes. Hoe je dat doet is aan jou maar de keuze van je objectstructuur is essentieel voor de mogelijkheden van je applicatie dus daar kun je beter goed over nadenken. Daarna maak je een controller laag die de objecten die je hebt gedefinieerd tot leven te wekken, ze met elkaar kan laten samenwerken en er uiteindelijk een template object van bakt wat je aan de gebruiker toont.

quote:

Op zaterdag 28 juli 2007 19:35 schreef Farenji het volgende:

[..]

Nee, zo moet je het niet zien.

Een OO applicatie bestaat idealiter uit 3 delen: model, view en controller.

Het model is alle data voor je applicatie, inclusief de interface om die data op te halen en te manipuleren. Je hebt daar bijv een Database class om te praten met je database. Het model zijn ook je objecten die opgebouwd worden uit / gebruik maken van die data, zoals bijv je Settings class, een Page classe, een User class etc.

De view is alles wat de gebruiker ziet, de output van je applicatie. Voor webapplicaties is dat meestal de template engine. De view is "dom", in de zin dat het gewoon weergeeft wat ie aangereikt krijgt en geen weet heeft van applicatielogica. Het is gewoon een object waar je variabelen aan hangt, en deze worden op de juiste plek in de html weergegeven.

Die applicatielogica zit in het controller gedeelte. Deze maakt de objecten uit het model aan, doet er het een en ander mee, en geeft ze door aan de view die het netjes op het scherm tovert. Alle gebruikersinvoer komt weer bij de controller terecht die er weer op reageert. Het is zeg maar de tussenpersoon tussen gebruiker en data.

OO programmeren betekent niet dat je over *alles* als objecten gaat denken, in het geval van Fok is elke post gewoon een grote string die in de database staat. De smilies zijn geen aparte objecten maar gewoon deel van die string.
Het is meer dat je je applicatie opdeelt in de essentiele bouwblokken, voor deze onderdelen definieer je eigenschappen en methodes. Hoe je dat doet is aan jou maar de keuze van je objectstructuur is essentieel voor de mogelijkheden van je applicatie dus daar kun je beter goed over nadenken. Daarna maak je een controller laag die de objecten die je hebt gedefinieerd tot leven te wekken, ze met elkaar kan laten samenwerken en er uiteindelijk een template object van bakt wat je aan de gebruiker toont.

MVC of niet, dan programmeer je in mijn opinie niet OO. Zelf heb ik diverse projecten met Java gedaan, waar basicly alles een object is. In Java zouden de smilies die op het moment onder mijn reply-message staan een object zijn, evenals het Preview en Invoeren knopje. Allemaal deel van de UI-laag.

In that case geef blijf ik wat PHP betreft liever bij "normaal" programmeren, aangezien ik liever geen mix van diverse programmeermanieren gebruik. Een databaseclass is leuk, als de rest van je software ook uit classes bestaat, en je niet stiekem ergens sjoemelt en je direct iets uit de database naar de gebruiker print.

Om een voorbeeld te geven, ik heb zoals elke student een bankproject moeten maken. En dan is dus wel alles een object. Geld overboeken doe je niet door in de database te klooien, nee, dat doe je een een Transactie-object aan te maken, die zelf de verantwoordelijkheid van de transactie draagt, en de rest van de transactie regelt.

quote:

Op zaterdag 28 juli 2007 19:47 schreef Geqxon het volgende:

[..]

MVC of niet, dan programmeer je in mijn opinie niet OO. Zelf heb ik diverse projecten met Java gedaan, waar basicly alles een object is. In Java zouden de smilies die op het moment onder mijn reply-message staan een object zijn, evenals het Preview en Invoeren knopje. Allemaal deel van de UI-laag.

Soms is dat handig. Soms absoluut niet. Als fok zo was opgebouwd dan hadden ze er wel 2 keer zoveel servers voor mogen inzetten want dat genereert een enorme hoeveelheid overbodige overhead. In Java wordt het OO denken heel ver doorgevoerd, zelfs een string is een object, in veel andere talen is een string gewoon een rijtje karakters afgesloten door een null character. Je bent als ontwerper vrij om te bepalen in hoeverre je de OO gedachte doorvoert. Als je het te ver doorvoert kan je helemaal verzuipen in de objecten, doe je het niet ver genoeg dan krijg je ongestructureerde en moeilijker onderhoudbare code.
Als je een gezicht beschrijft aan de hand van de kenmerken van de onderdelen zoals ogen neus en mond etc dan is dat duidelijker en zinvoller dan wanneer je een gezicht beschrijft aan de hand van de onderlinge samenhang van alle lichaamscellen in het gezicht.

quote:

In that case geef blijf ik wat PHP betreft liever bij "normaal" programmeren, aangezien ik liever geen mix van diverse programmeermanieren gebruik. Een databaseclass is leuk, als de rest van je software ook uit classes bestaat, en je niet stiekem ergens sjoemelt en je direct iets uit de database naar de gebruiker print.

Het voordeel van een database class is dat je een uniforme interface hebt die verschillende backends kan hebben. Je kan er een wrapper van maken en hiermee je applicatie onafhankelijk van de database te maken, zo kan je het zo doen dat ie zowel met MySQL als MSSQL als met XML files kan werken. Natuurlijk kun je altijd die class omzeilen maar daarmee doe je idd het idee achter OO teniet.

quote:

Om een voorbeeld te geven, ik heb zoals elke student een bankproject moeten maken. En dan is dus wel alles een object. Geld overboeken doe je niet door in de database te klooien, nee, dat doe je een een Transactie-object aan te maken, die zelf de verantwoordelijkheid van de transactie draagt, en de rest van de transactie regelt.

Inderdaad, objecten met elk hun eigen verantwoordelijkheden en taken, netjes afgescheiden van de andere objecten. Maar het is zinloos om alle data tot in de oneindigheid verder op te delen in objecten. Ergens moeten de objecten obhouden met object te zijn en gewoon een brok data worden.

quote:

Op zaterdag 28 juli 2007 20:06 schreef Farenji het volgende:

Het voordeel van een database class is dat je een uniforme interface hebt die verschillende backends kan hebben. Je kan er een wrapper van maken en hiermee je applicatie onafhankelijk van de database te maken, zo kan je het zo doen dat ie zowel met MySQL als MSSQL als met XML files kan werken. Natuurlijk kun je altijd die class omzeilen maar daarmee doe je idd het idee achter OO teniet.

Om puur hier op in te gaan: Is dat wel mogelijk? Is er dan niet voor elke compliceerde query een aparte functie (/method) nodig? Stel dat ik een query van een regel of zeven gebruik om de data op te halen, dan moet deze complete query in de class staan, onder een aparte functie, neem ik aan?

quote:

Op zaterdag 28 juli 2007 20:49 schreef Geqxon het volgende:

[..]

Om puur hier op in te gaan: Is dat wel mogelijk? Is er dan niet voor elke compliceerde query een aparte functie (/method) nodig? Stel dat ik een query van een regel of zeven gebruik om de data op te halen, dan moet deze complete query in de class staan, onder een aparte functie, neem ik aan?

Ja, want je geeft de SQL query aan de DBclass, deze voert hem uit en geeft de resultaten terug. Maar je kunt ook iets zoals propel gebruiken .

quote:

Op zaterdag 28 juli 2007 21:14 schreef WyriHaximus het volgende:

[..]

Ja, want je geeft de SQL query aan de DBclass, deze voert hem uit en geeft de resultaten terug. Maar je kunt ook iets zoals propel gebruiken .

Maar wat als je dus de SQL-query aan de DBclass doorgeeft, en je plotseling op XML-files over wilt stappen, of een totaal andere manier van storage? Meer op die manier.

quote:

Op zaterdag 28 juli 2007 21:34 schreef Geqxon het volgende:

[..]

Maar wat als je dus de SQL-query aan de DBclass doorgeeft, en je plotseling op XML-files over wilt stappen, of een totaal andere manier van storage? Meer op die manier.

Nee dat gaat dan niet, naar allerlei SQL servers wel maar XML niet tenzij je zelf storage engine er voor gaat bouwen . Maar Propel wat ik noemde maakt je hele database beschikbaar als object .

quote:

Op zaterdag 28 juli 2007 20:49 schreef Geqxon het volgende:

[..]

Om puur hier op in te gaan: Is dat wel mogelijk? Is er dan niet voor elke compliceerde query een aparte functie (/method) nodig? Stel dat ik een query van een regel of zeven gebruik om de data op te halen, dan moet deze complete query in de class staan, onder een aparte functie, neem ik aan?

Welcome to "models"

Mmmm. Blijft complicated, OO in PHP. Persoonlijk zou ik het pas willen gebruiken als ik dan ook gelijk 100% op OO over zou kunnen gaan, echter zou dat veel overhead en veel extra werk betekenen. For now blijf ik liever bij de standaard manier van programmeren, alles met functies, niks redundant. Is toch niks mis mee? Of kom ik daar de komende 2 jaar niet meer mee door?

We hebben heel lang zonder OO gezeten dus 2 jaar trek je ook wel, maar als je grote complexere applicaties maakt zal je merken dat het veel overzichtelijker en veel gestructureerder werkt als je te maken hebt met gedefinieerde objecten met methodes en eigenschappen, die ook van elkaar kunnen overerven, dan wanneer je allemaal ondefineerbare brokken code en ongedefineerde databrokken hebt zonder expliciete samenhang.

Voorbeeld: ik heb een CMS en een van de objecten van dat cms is het Page object wat ik zelf heb gedefinieerd. ALs ik een pagina wil tonen maak ik een nieuw Page object aan, bijv "var $page = Page->newByID(12)" en roep ik Page->outputHTML() aan waarna hij getoond wordt in de browser. Als ik een pagina wil aanpassen doe ik Page->setProperty( key => value ) en daarna Page->save() waardoor het in de DB wordt opgeslagen.

Ik kan ook meerdere instanties aanmaken van de Page class, ik kan met enkele regels code een array van honderden pagina's instantieren en deze allemaal makkelijk beheren en manipuleren dmv de object methodes. Ik weet namelijk altijd met wat voor object ik aan het werken ben, het is niet zomaar willekeurige data.

Ik kan een nieuw object definieren, bijv Chapter, dat alle methodes en eigenschappen overerft van Page maar daarnaast eigen functies heeft. Ik hoef dan alleen de afwijkende dingen te definieren, alle standaardfuncties heb ik al want die neemt ie automagisch over van de parent Page class.

Probeer zoiets eens met strict procedureel programmeren. Als dat al lukt gaat je dat sowieso vele malen meer code opleveren, maar waarschijnlijker is dat je compleet de weg en het overzicht kwijtraakt en met een niet goed werkende applicatie zit die niet meer te debuggen of onderhouden is.

Korte vraag; ik heb een database waar ik alleen de items van vandaag wil halen.

Ik gebruik datetime en dit is een voorbeeld query

select * from tabel where date = '" . date("Y-m-d") . "'"

Wrom gaat het fout?

Wat voor veld is date? En volgens mij is date ook een reserved word dus probeer eens `date` ipv `date` .

nee date werkt gewoon hoor.

Maar af en toe ben ik nogal blind :X



Opgelost :P (slotje :X)

quote:

Op zaterdag 28 juli 2007 19:35 schreef Farenji het volgende:


Een OO applicatie bestaat idealiter uit 3 delen: model, view en controller.

Dat is niet geheel waar. Je hebt verschillende design patterns, allemaal met een zeker doel/uitgangspunt. OO zegt niet dat je een MVC model moet implementeren.

MVC is vooral om de business logic te scheiden van de hoe de data wordt gepresenteerd op je scherm door het gebruik van de controller.

Ikzelf heb dit boek ooit aangeschafd: http://en.wikipedia.org/wiki/Design_Patterns

Zie verder ook: http://en.wikipedia.org/wiki/Object_oriented en http://en.wikipedia.org/wiki/Model-view-controller

Voor webapplicaties is het MVC model wel *het* model dacht ik zo. Ik zou zo gauw geen ander model kunnen noemen. Of het moet het "alles op 1 grote ondefinieerbare hoop" model moeten zijn.
Dat Design Patterns boek heb ik (uiteraard) ook in de kast staan, maar dat gaat niet direct over MVC maar meer over patterns die je zou kunnen gebruiken voor bepaalde doeleinden, eventueel binnen een MVC framework.

OO staat inderdaad los van MVC, maar MVC is inderdaad wel "het" model voor webpps

Ik gok zo even dat de uitvoering van MVC in Java exact hetzelfde is als MVC in PHP?