[PHP5] Echt object georienteerd programmeren

[Erpenator2]

Ik ben op zoek naar een manier om zo dicht mogelijk tegen het “echte” object georiënteerd programmeren aan te zitten met PHP 5. Op dit moment gebruik ik een index.php die en SuperClass aanmaakt om vervolgens een andere klasse aan temaken die bepaald welke pagina geladen moet worden. Al mijn variabelen die ik langer nodig heb bewaar ik in een sessie.

Maar liever zou ik zoveel mogelijk gegevens in een object bewaren zodat je de eigenschappen kunt aanpassen en deze dus niet steeds uit een database hoeft op te halen.

Wijzigingen die opgeslagen moeten worden zouden wel weer direct opgeslagen kunnen worden in de database of cookie. Dit omdat je niet weet wanneer een bezoeker een sessie beëindigt.

Maar na wat uitzoek werkt lijkt het er op dat wat ik graag zou willen erg lastig is. Je moet alle objecten opslaan in een sessie en vervolgens alle klasses instantieren voordat je sessie weer opnieuw start. Ook die je misschien niet meer nodig hebt. Maar dit is weer lastig om te doen aangezien het om een grote website gaat en er vele verschillende klasses geinstantieerd zouden kunnen worden, maar je weet vooraf niet welke, wat weer een hoop performance zou kunnen kosten.

Wie heeft hier ervaring mee en kan mij vooruit helpen.

[Grijze Vos]

Je hoeft classes toch pas te instantieren als je ze nodig hebt?
(Je kunt daarbij ook nog __autoload() gebruiken om je class files pas te parsen als je ze echt nodig hebt.

Ik zou gewoon je objecten instantieren vanuit de database, en ze niet in een sessie bewaren oid. Dat gaat even snel zo niet sneller hoor. Spaart je ook allemaal transaction problemen etc. Het is niet voor niks dat bijv. java hier een apart framework voor heeft, voor deze functionaliteit.

[Not Pingu]

Ik neem aan dat Grijze Vos doelt op O/R mappers als Hibernate? Er is een ORM framework voor PHP dus misschien zou TS daar naar kunnen kijken.

[twiekert]

Helaas, PHP is geen applicatie server waar je je spullen in het geheugen kunt houden terwijl de request al is afgelopen. Het enige wat je kunt doen is gegevens in een SESSION opslaan (user uniek) of in een memcache of apccache (app-wide).

Objecten in een sessie bewaren om te bewerken is alleen interessant als een gebruiker op dat moment in een workflow zit om het object te bewerken maar de bewerkacties over verschillende pagina's verdeelt zijn (en dus meerdere requests).

Het is leuk als cache maar hou er rekening met objectdata die out of sync raakt met de database.

[LuCarD]

Ik ga er iets anders mee om.

Aan de begin van de pagina start ik mijn sessie. Zodra er dan een class wordt gestart, dan kijk ik in de sessie container of relevante informatie in de sessie heb staan en laad die dan vervolgens in de object.

Als er een wijziging in de object komt en die is relevant voor de gehele sessie, dan sla ik die op in de sessie container. Zodat die automatisch meegaat naar de volgende pagina. Dit word allemaal geregeld binnen de class zelf. Dus vanuit de pagina hoef ik geen rekening te houden of iets wordt bewaard in de sessie of niet.

Verder je hoeft niet alle classes op te slaan in een sessie sommige classes heb je toch alleen maar tijdelijk nodig en kan je aan de eind van de pagina gewoon weggooien.

[Erpenator2]

Ik denk dat de methode van Lucard wel het meeste is wat in de buurt komt van wat ik zoek. Dat komt ook het dichtst in de buurt van wat ik op dit moment al heb.

Maken jullie dan ook nog een verschil tussen bijvoorbeeld de layout en de code? Dus MVC ?
Zo ja op welke manier?

Op dit moment gebruik ik de methode om min of meer complete blokken te parsen en naar een hogere klasse terug te geven om dat later het groter geheel te plaatsen. Op zich werkt deze manier erg efficient maar wellicht kan het ook beter/ anders.

Zelf vind ik het erg nutteloos om alles in een array te stoppen en deze daarna nogmaals door te lopen om de info te parsen.

[Verwijderd]

Erpenator2 schreef op woensdag 03 oktober 2007 @ 14:22:
Maken jullie dan ook nog een verschil tussen bijvoorbeeld de layout en de code? Dus MVC ?
Zo ja op welke manier?

Mijn webapplicaties werken redelijk MVC. Ik begin met een stuk code dat de user input afvangt. Het enige dat dit stuk code doet is gegevens uit GET en POST halen en meegeven aan de uit te voeren functies. Deze functies maken deel uit van het model. (In een goede bui bouw ik een net domeinmodel zodat ik geen gebruik hoef te maken van losse functies.)

Mijn model genereert XML. Deze XML wordt door een XSLT gehaald. De XSLT fungeert als mijn view. Hiermee is mijn HTML grotendeels gescheiden van mijn PHP. Natuurlijk maak ik gebruik van CSS om mijn HTML vorm te geven, waarmee ik de view in feite opgesplitst heb .

[Verwijderd]

Verwijderd schreef op woensdag 03 oktober 2007 @ 15:30:
Mijn model genereert XML. Deze XML wordt door een XSLT gehaald.

Dus je model wordt een view die als model fungeert voor de uiteindelijke view. Dat klinkt/is gewoon omslachtig. Verwijder de xml/xslt stap en je hebt een prima oplossing

[Grijze Vos]

Verwijderd schreef op woensdag 03 oktober 2007 @ 15:37:
[...]
Dus je model wordt een view die als model fungeert voor de uiteindelijke view. Dat klinkt/is gewoon omslachtig. Verwijder de xml/xslt stap en je hebt een prima oplossing

mwoah, hoeft niet. Misschien gebruikt hij die XML ook voor andere dingen dan HTML uitvoer? Dan is XSLT wel een mogelijke nette oplossing.

[Verwijderd]

Grijze Vos schreef op woensdag 03 oktober 2007 @ 15:41:
mwoah, hoeft niet. Misschien gebruikt hij die XML ook voor andere dingen dan HTML uitvoer? Dan is XSLT wel een mogelijke nette oplossing.

Je kunt ook php gebruiken om andere formaten uit te spugen dan html. Xml als tussen product is vrijwel nooit netjes en vrijwel altijd omslachtig. Maar het klinkt natuurlijk wel lekker hip!

edit:
En ja er is vast wel een voorbeeld te verzinnen waarbij een dergelijke opstelling gerechtvaardigd is, maar in een topic waarin in het algemeen wordt gesproken van een goede mvc methode kan maar beter benadrukt worden dat het doorgaans een bad-practice is.

[ Voor 31% gewijzigd door Verwijderd op 03-10-2007 15:49 ]

[Verwijderd]

Verwijderd schreef op woensdag 03 oktober 2007 @ 15:46:
[...] Xml als tussen product is vrijwel nooit netjes en vrijwel altijd omslachtig. Maar het klinkt natuurlijk wel lekker hip!

XML is specifiek ontworpen om de rol van tussenproduct te vervullen.

Waarom is Smarty wel een goede template engine, en XSLT niet? Het doet nagenoeg hetzelfde: data en presentatie scheiden. Ja, XSLT is een stap extra. Maar ik weet wél precies wat ik doe en waar ik bepaalde code moet veranderen. Dat is toch de essentie achter MVC?

Onderhoudbaarheid is soms belangrijker dan efficiëntie.

[koli-man]

Verwijderd schreef op woensdag 03 oktober 2007 @ 15:46:
[...]
Je kunt ook php gebruiken om andere formaten uit te spugen dan html. Xml als tussen product is vrijwel nooit netjes en vrijwel altijd omslachtig. Maar het klinkt natuurlijk wel lekker hip!

edit:
En ja er is vast wel een voorbeeld te verzinnen waarbij een dergelijke opstelling gerechtvaardigd is, maar in een topic waarin in het algemeen wordt gesproken van een goede mvc methode kan maar beter benadrukt worden dat het doorgaans een bad-practice is.

Als jij xml data genereert uit je database fetches en je transformeert die xml met behulp van xslt naar je (html) output, lijkt me dat zeer zeker een goede methode.

Dat doet bijvoorbeeld het spring framework(java) ook voor je..

[TeeDee]

Verwijderd schreef op woensdag 03 oktober 2007 @ 16:05:
[...]

XML is specifiek ontworpen om de rol van tussenproduct te vervullen.

offtopic:
Ik zie XML als datacontainer. Wat je er daarna mee doet is aan jou. Tussenproduct? Mwah, ik denk dat je er dan teveel aan geeft.

[Verwijderd]

Verwijderd schreef op woensdag 03 oktober 2007 @ 16:05:
XML is specifiek ontworpen om de rol van tussenproduct te vervullen.

Waarom is Smarty wel een goede template engine, en XSLT niet? Het doet nagenoeg hetzelfde: data en presentatie scheiden. Ja, XSLT is een stap extra. Maar ik weet wél precies wat ik doe en waar ik bepaalde code moet veranderen. Dat is toch de essentie achter MVC?

Onderhoudbaarheid is soms belangrijker dan efficiëntie.

Om de vraag dan maar even anders te stellen, waarom gebruik je twee 'tussenproducten'? Je hebt namelijk je 'php in memory model' en een xml model. In feite is de xml een view op je model.

Ik roep trouwens niet dat Smarty een goede template engine is, maar het gebruikt tenminste direct het in memory model (voor zover ik weet). Die 'essentie achter MVC' kun je ook gewoon realiseren binnen php.

Je gebruikt nu xml om de xml, het heiligt namelijk geen doel.

koli-man schreef op woensdag 03 oktober 2007 @ 16:05:
Als jij xml data genereert uit je database fetches en je transformeert die xml met behulp van xslt naar je (html) output, lijkt me dat zeer zeker een goede methode.
Dat doet bijvoorbeeld het spring framework(java) ook voor je..

Dat is een zeer slechte methode aangezien je op de verkeerde plek je data al naar een view aan het transformeren bent. Je levert dus juist in op flexibiliteit en onderhoudbaarheid. En nee dat doet spring niet voor je.

[ Voor 22% gewijzigd door Verwijderd op 03-10-2007 16:19 ]

[Verwijderd]

TeeDee schreef op woensdag 03 oktober 2007 @ 16:11:
Ik zie XML als datacontainer. Wat je er daarna mee doet is aan jou. Tussenproduct? Mwah, ik denk dat je er dan teveel aan geeft.

XML is bedoeld om applicaties op een uniforme manier met elkaar te laten kletsen. Vroegah had je allerlei binaire formaten die je met veel moeite moest specificeren en implementeren. Nu heb je een XML-stream waar je zonder problemen op kan inhaken.

[Verwijderd]

Verwijderd schreef op woensdag 03 oktober 2007 @ 16:17:
[...]
Om de vraag dan maar even anders te stellen, waarom gebruik je twee 'tussenproducten'? Je hebt namelijk je 'php in memory model' en een xml model. In feite is de xml een view op je model.

Ik roep trouwens niet dat Smarty een goede template engine is, maar het gebruikt tenminste direct het in memory model (voor zover ik weet). Die 'essentie achter MVC' kun je ook gewoon realiseren binnen php.

Je gebruikt nu xml om de xml, het heiligt namelijk geen doel.

XSLT vind ik als template engine (want daar praten we over) fijner werken dan PHP. XML gebruik ik verder vooral vanwege de mogelijkheid direct gegevens te kunnen output'en. Ik hoef geen apart formaat te definiëren, ik output domweg de XML zonder de XSLT.

Zo sla twee vliegen in één klap: XSLT als template engine, en XML-output om te communiceren met andere applicaties.

[Verwijderd]

Verwijderd schreef op woensdag 03 oktober 2007 @ 16:18:
XML is bedoeld om applicaties op een uniforme manier met elkaar te laten kletsen. Vroegah had je allerlei binaire formaten die je met veel moeite moest specificeren en implementeren. Nu heb je een XML-stream waar je zonder problemen op kan inhaken.

Met klem dus even: Xml kan uitkomst bieden om verschillende applicaties op een uniforme manier te laten kletsen. Maar intern is dat natuurlijk kolder.

Dat is alsof je zelf nederlands praat, het opschrijft in het frans en het vervolgens naar het engels vertaald voor de buitenwereld.

[Janoz]

Het punt dat mark maakt is eerder dat je je gegevens in je applicatie hebt, vervolgens ga je dit omzetten naar een ander formaat en dat geef je weer aan je eigen applicatie om het vervolgens om te zetten naar het uiteindelijke formaat.

Voordat ik iets dergelijks zou doen zou ik eerst een valide en concrete reden moeten hebben voor dat tussenproduct. In alle andere gevallen kun je je objectmodel gewoon rechtstreeks in je view toepassen.

[Verwijderd]

Verwijderd schreef op woensdag 03 oktober 2007 @ 16:22:
[...]
Met klem dus even: Xml kan uitkomst bieden om verschillende applicaties op een uniforme manier te laten kletsen. Maar intern is dat natuurlijk kolder.

Van alle templating-manieren die ik heb geprobeerd, vind ik XSLT persoonlijke het lekkerst werken. Waarom zou ik Smarty gebruiken, als XSLT veel generieker is, en XML diverse voordelen biedt ten aanzien van interoperabiliteit?

[koli-man]

Verwijderd schreef op woensdag 03 oktober 2007 @ 16:17:


Dat is een zeer slechte methode aangezien je op de verkeerde plek je data al naar een view aan het transformeren bent. Je levert dus juist in op flexibiliteit en onderhoudbaarheid. En nee dat doet spring niet voor je.

Die database fetches gebeuren in de business logic (die business objects gebruiken dus een dao), waarom het transactie mechanisme heenzit. Deze calls naar de business logic komen van de Controller die vervolgens een ModelAndView teruggeeft. Die serialized de data naar xml en transformeert het met xslt naar je output.

Ga me nou niet vertellen dat dit een slechte manier is.....

[ Voor 29% gewijzigd door koli-man op 03-10-2007 16:35 ]

[Janoz]

Mark heeft niet gezegd dat het een slechte manier is. Dat is het ook niet. Het is echter de vraag of die extra conversie stap te verantwoorden is. Je transformeert eerst je modelAndView naar xml en vervolgens laat je php je xml transformeren naar html. Als dit de enige plek is waar je dit gebruikt en er verder geen extern opgelegde eisen zijn om xslt te gebruiken dan zou je natuurlijk ook gewoon je modelAndView kunnen pakken en deze rechtstreeks middels php omzetten naar html. Dat draait namelijk een stuk efficienter.

[base_]

Heeft iemand hier toevallig ervaring met symfony? zie www.symfony-project.com , dit is een framework wat de structuur en objectgeorienteerdheid allemaal in zich heeft en lijkt mij een goede aanvulling op php om snel gestructureerd en OO te (leren) programmeren. ORM/scaffolding/MVC included....

[Kalentum]

Verwijderd schreef op woensdag 03 oktober 2007 @ 16:30:
[...]

Van alle templating-manieren die ik heb geprobeerd, vind ik XSLT persoonlijke het lekkerst werken. Waarom zou ik Smarty gebruiken, als XSLT veel generieker is, en XML diverse voordelen biedt ten aanzien van interoperabiliteit?

Je kan niet stellen dat XSLT per definitie beter is ofzo. Dat verschilt per situatie.

Smarty vereist in ieder geval geen extra conversie slag (het is gewoon 1 van de views op je data die je kan hebben), als je met aparte designers werkt kunnen ze zelf de code aanpassen zonder dat ze XSLT moeten kunnen en zonder dat je zelf de boel eerst moet omzetten.

[Verwijderd]

rutgerw schreef op woensdag 03 oktober 2007 @ 21:58:
Je kan niet stellen dat XSLT per definitie beter is ofzo. Dat verschilt per situatie.

Mee eens.

Smarty vereist in ieder geval geen extra conversie slag (het is gewoon 1 van de views op je data die je kan hebben), als je met aparte designers werkt kunnen ze zelf de code aanpassen zonder dat ze XSLT moeten kunnen en zonder dat je zelf de boel eerst moet omzetten.

Smarty is efficiënter dan XSLT. Een designer die Smarty kent, kan daar prima mee overweg. Maar om Smarty nu te verkiezen omdat 3% i.p.v. 2% van de designers ermee overweg kan… Als ik het de designers makkelijk wilde maken, had ik überhaupt geen ingewikkelde template engine (Smarty of XSLT) gebruikt .

[Michali]

Ik moet zeggen dat ik het totaal met Janoz en Mark Platvoet eens ben wat betreft het XML en XSLT verhaal. Ik heb dit ook wel eens te onpas gebruikt en dat gaat, als je het eigenlijk niet nodig hebt, alleen maar in de weg zitten. Niels Slijm, dat je zegt dat je XSLT het lekkerst vindt werken klinkt mij eerlijk gezegd erg vreemd in de oren; aangezien je door puur PHP te gebruiken dezelfde kracht en nog meer kunt uitoefenen, dus dat lijkt me erg sterk.

Bij het lezen van de topicstart krijg ik een vreemd gevoel. Klinkt alsof je het allemaal veel te moeilijk wilt doen. Zoals ik het lees is PHP helemaal niet zo geschikt voor waarvoor jij het wilt gebruiken. Of je probeert een probleem op te lossen dat helemaal niet bestaat. Dat ophalen van objecten uit de database is helemaal niet zo slecht voor je performance als je denkt waarschijnlijk. Het opslaan van domein objecten in je sessie lijkt me overigens eerlijk gezegd sowieso een slecht plan (in PHP althans, er zijn wel betere oplossingen te bedenken).

Probeer het eerst gewoon zo schoon en duidelijk mogelijk op te lossen. Als je dan met performance problemen blijkt te zitten, kom dan met een vraag over hoe je dat op kunt lossen. Volgens mij ben je nog amper begonnen en begin je je nu al zorgen te maken over de performance in delen waar je je waarschijnlijk nooit zo druk over hoeft te maken.

[Cyphax]

Janoz schreef op woensdag 03 oktober 2007 @ 20:32:
Mark heeft niet gezegd dat het een slechte manier is. Dat is het ook niet. Het is echter de vraag of die extra conversie stap te verantwoorden is. Je transformeert eerst je modelAndView naar xml en vervolgens laat je php je xml transformeren naar html. Als dit de enige plek is waar je dit gebruikt en er verder geen extern opgelegde eisen zijn om xslt te gebruiken dan zou je natuurlijk ook gewoon je modelAndView kunnen pakken en deze rechtstreeks middels php omzetten naar html. Dat draait namelijk een stuk efficienter.

Een voordeel van de aanpak met XSL+XML is dat je heel weinig PHP nodig hebt. Je hoeft alleen een parser te schrijven die een XML+XSL-file omzet, en wat includes die de data ophalen.
Het is niet de meest efficiente manier waarschijnljk, het is sneller om je PHP direct HTML uit te laten poepen, maar via XSL heb je wel veel vrijheid in je layout. Kan je ook nog met schema's werken om het te valideren als je wilt.

[prototype]

base_ schreef op woensdag 03 oktober 2007 @ 20:39:
Heeft iemand hier toevallig ervaring met symfony? zie www.symfony-project.com , dit is een framework wat de structuur en objectgeorienteerdheid allemaal in zich heeft en lijkt mij een goede aanvulling op php om snel gestructureerd en OO te (leren) programmeren. ORM/scaffolding/MVC included....

Een aardige Rails clone, maar je blijft met een probleem zitten: PHP. Ruby biedt syntactisch gezien wat interessante(re) mogelijkheden dan PHP die Ruby on Rails het overwegen waard maken.

Wat betreft de discussie van XML/XSLT: Niet doen als het niet nodig is. Zoals al eerder gezegd is het een extra conversieslag, en wel een die je applicatie minder transparant maakt. Daarbij zijn XML en XSLT's vrij verbose en imho niet lekker te onderhouden.

Het argument van XML/XSLT gebruiken om zodoende meer flexibiliteit te creeeren tov PHP als dependency vind ik dan ook niet zo sterk. Met andere woorden, het idee van XML/XSLT gebruiken omdat je ooit misschien niet PHP meer gebruikt. Dit is imho een veelvoorkomend denkfoutje, omdat men al rekening gaat houden met iets dat veel waarschijnlijker nooit ervan zal komen (YAGNI).

Wat betreft Smarty, daar is in het verleden wel 's gediscussieerd, en ik heb m'n mening ook al gegeven in het verleden hierover. Het voordeel van Smarty kiezen boven PHP zie ik tot op de dag van vandaag nog steeds niet. De naam zegt het namelijk zelf al: PHP Hypertext Preprocessor.

[Verwijderd]

prototype schreef op donderdag 04 oktober 2007 @ 00:20:
Het argument van XML/XSLT gebruiken om zodoende meer flexibiliteit te creeeren tov PHP als dependency vind ik dan ook niet zo sterk. Met andere woorden, het idee van XML/XSLT gebruiken omdat je ooit misschien niet PHP meer gebruikt. Dit is imho een veelvoorkomend denkfoutje, omdat men al rekening gaat houden met iets dat veel waarschijnlijker nooit ervan zal komen (YAGNI).

Grappig dat je dat opmerkt. Ik heb dat nooit voorzien, maar ik zit er nu wel over te denken om mijn framework te porten van PHP naar Python .

[koli-man]

Janoz schreef op woensdag 03 oktober 2007 @ 20:32:
Mark heeft niet gezegd dat het een slechte manier is. Dat is het ook niet. Het is echter de vraag of die extra conversie stap te verantwoorden is. Je transformeert eerst je modelAndView naar xml en vervolgens laat je php je xml transformeren naar html. Als dit de enige plek is waar je dit gebruikt en er verder geen extern opgelegde eisen zijn om xslt te gebruiken dan zou je natuurlijk ook gewoon je modelAndView kunnen pakken en deze rechtstreeks middels php omzetten naar html. Dat draait namelijk een stuk efficienter.

Ik had het over de combinatie met java en het spring framework...

[ Voor 3% gewijzigd door koli-man op 04-10-2007 09:12 ]

[Verwijderd]

koli-man schreef op donderdag 04 oktober 2007 @ 09:11:
Ik had het over de combinatie met java en het spring framework...

Ja ik weet ongeveer wel wat het springframework is en ik kan ook een beetje Java programmeren, maar ik zie niet in waar het gebruik van spring en java conceptueel anders zou zijn. Waarom zou het gebruik van een 'tussenproduct' met java+spring wel gerechtvaardigd zijn?

[koli-man]

Verwijderd schreef op donderdag 04 oktober 2007 @ 09:28:
[...]
Ja ik weet ongeveer wel wat het springframework is en ik kan ook een beetje Java programmeren, maar ik zie niet in waar het gebruik van spring en java conceptueel anders zou zijn. Waarom zou het gebruik van een 'tussenproduct' met java+spring wel gerechtvaardigd zijn?

niet per se gerechtvaardigd, je zou ook een jstlview met jsp pages kunnen gebruiken. Dan ben je van het zogenaamde tussenproduct af....
Echter , wil je informatie tonen op je scherm, wat lastige sorteringen, etc bevatten. Dan is xslt een goed middel om te gebruiken i.p.v. moeilijk gaan doen in n aantal regels code om die data zonder 'tussenproduct' op je scherm te krijgen.


* koli-man gaat even kijken waar de startpost ook alweer over ging...

[ Voor 5% gewijzigd door koli-man op 04-10-2007 09:46 ]

[Janoz]

Cyphax schreef op woensdag 03 oktober 2007 @ 23:58:
[...]

Een voordeel van de aanpak met XSL+XML is dat je heel weinig PHP nodig hebt. Je hoeft alleen een parser te schrijven die een XML+XSL-file omzet, en wat includes die de data ophalen.
Het is niet de meest efficiente manier waarschijnljk, het is sneller om je PHP direct HTML uit te laten poepen, maar via XSL heb je wel veel vrijheid in je layout. Kan je ook nog met schema's werken om het te valideren als je wilt.

Klopt, maar vervolgens moet je wel een berg implementeren in xslt. Die winst is vervolgens weer verloren. Verder denk ik niet dat je met XSL vrijer bent in je layout, sterker nog, ik denk dat je met php vrijer bent met hoe je je pagina opstelt.

[Zyppora]

Wat betreft het XML+XSLT verhaal:

Backend -> PHP -> XSLT -> output
Backend -> PHP -> output

Die eerste is alleen gewenst wanneer je 'output' meerdere formaten moet kunnen aannemen (of wanneer je output exporteerbaar/app-onafhankelijk moet zijn). Dus bijv. niet alleen html, maar ook txt, css, jsp, asp, pdf, etc.

Wanneer je maar een formaat wilt uitspugen (html) is die tweede beter m.i. In het eerste geval moet je PHP code schrijven die XML uitpoept, en daarna PHP code die die XML parst aan de hand van een XSLT bestand (wat je dus OOK moet schrijven). Dit in tegenstelling tot het schrijven van PHP die html teruggeeft (en dat is het principe vanwaaruit PHP dus ook ontwikkeld is).

[Verwijderd]

Zyppora schreef op donderdag 04 oktober 2007 @ 10:10:
Wat betreft het XML+XSLT verhaal:

Backend -> PHP -> XSLT -> output
Backend -> PHP -> output

Die eerste is alleen gewenst wanneer je 'output' meerdere formaten moet kunnen aannemen (of wanneer je output exporteerbaar/app-onafhankelijk moet zijn). Dus bijv. niet alleen html, maar ook txt, css, jsp, asp, pdf, etc.

Waar het dus om draait is dat je met de tweede optie net zo makkelijk(/makkelijker) txt, css, jsp, asp, pdf, etc kunt uitspugen. Je kunt namelijk meerdere php views op je model maken.

[Confusion]

Verwijderd schreef op woensdag 03 oktober 2007 @ 16:05:
[...]
XML is specifiek ontworpen om de rol van tussenproduct te vervullen.

Ja, voor situaties waar je interoperabiliteit nodig hebt. Niet als tussenliggend dataformaat binnen je eigen systeem.

[prototype]

Verwijderd schreef op donderdag 04 oktober 2007 @ 08:32:
[...]

Grappig dat je dat opmerkt. Ik heb dat nooit voorzien, maar ik zit er nu wel over te denken om mijn framework te porten van PHP naar Python .

Het feit dat je framework noemt doet me toch wat afvragen: zijn er niet reeds bestaande frameworks die voorzien in je nood (django)? Maar wat ik eigenlijk meende te zeggen is dat de voordeel die je denkt te hebben met XML/XSLT al lang verloren gaat door de factor tijd; je bent gewoon langer bezig met het onderhouden dan dat je in dezelfde tijd even snel een nieuwe view bakt. En dan ontbreekt de pragmatiek gewoon imho.

[Cyphax]

Janoz schreef op donderdag 04 oktober 2007 @ 09:46:
[...]

Klopt, maar vervolgens moet je wel een berg implementeren in xslt.

Ja, misschien iets meer dan met een template engine, maar met de juiste tools gaat dat best hard.
Ik implementeer hier op het werk heel veel HTML-nieuwsbrieven op die manier (omdat de emails in XML opgeslagen moeten worden), op zich werkt het best gaaf.

Die winst is vervolgens weer verloren. Verder denk ik niet dat je met XSL vrijer bent in je layout, sterker nog, ik denk dat je met php vrijer bent met hoe je je pagina opstelt.

Wellicht, mits je het netjes doet, anders krijg je een puinzooi aan PHP-code. Als ik mijn oude PHP-projectjes nu terugzie, dan is het toch echt even schrikken.
Anyway, ik ga je helemaal niet tegenspreken, ik mag ook graag werken met PHP en XML+XSLT is niet de beste manier. Maar het is in mijn ogen wel een werkbare manier met zijn eigen voordelen.