[php] html + code scheiden

[Verwijderd]

Ik ga 1 september mijn afstudeerstage lopen en ik wil er iets speciaals van maken.
Ik heb al eerder een hele site gemaakt in php met beheermodule en de hele rim ram. Ik heb toen echter gewoon alle php code verweven in de HTML en andersom.
Dit keer wil ik er een net project van maken, waarbij de code en HTML zoveel mogelijk van elkaar gescheiden zijn. Ik wil tevens van zo nieuw mogelijke technieken gebruik maken, dat verkoopt weer leuk aan school. Het moet echter wel met zo veel mogelijk browsers compatible blijven, het moet ook nog gebruikt worden namelijk.

Na wat rondzoeken zijn de volgende hersenspinsels ontstaan:
- PHP templates
- iets met php + xhtml
- iets met php + xml + html

Van de mogelijkheden weet ik nog verre van de hoed en de rand.
Over PHP templates zijn veel topics & tutorials, maar deze zijn al vrij oud... Zou dit een investering in het verleden zijn?!

Zelf lijkt het me ook wel gaaf om wat met XML / XHTML te doen. Volgens mij kan je php XML laten uitpoepen en dat weer in HTML/XSL uitlezen. (Of zeg ik nu hele domme dingen?)

Wie heeft er ervaring met een van deze mogelijkheden en waar kan ik me het best in verdiepen?

[samo]

Ik weet een mooi praktijkvoorbeeld: www.xoops.org
Hoe het precies werkt weet ik niet, maar dat staat vast wel op hun website. Indien nodig kan ik je een email adres geven van iemand die ik ken en die daar veel mensen kent

[Suepahfly]

Om je code en ontwerp (html) te schijden zou ik idd met templates gaan werken.

Er zijn genoeg opescource engines te vinden bv, Smarty of Yapter.

Op die manier is het ook heel goed mogelijk om XML te genereren ( Dit kan zelfs met een echo command)
Zolang je maar de juiste structuur aanhoud zoals beschreven in je .dtd bestand.

Je zou een kunnen kijken hoe andere CMS systemen het doen zoals PHP-Nuke of XOOPS.
De maken zelf ook gebruik van templates.
XOOPS is zelfs helemaal OO geprogrameerd .

[Not Pingu]

Ik werk met ASP en gebruik de volgende manier om html en code te scheiden:

maak een html file genaamd template.html. Dit is gewoon een pure HTML file die de layout + looks + css van je site bevat. Op bepaalde plaatsen zet je tags als: <%=PaginaInhoud%> (dit wordt gezien als een Response.Write aanroep, de PHP variant weet ik niet). Naar gelang je andere dingen nodig hebt (dynamisch menu, nieuwslijst, etc...) zet je daarvoor ook die tags op bepaalde plaatsen.

Dan schrijf je een asp file waarin je de variabelen PaginaInhoud etc. declareert, die vul je met de nodige tekst. eventueel doe je database aanroepen voor de nieuwslijst.

Vervolgens include je de template.html file en worden de variabelen op de plaatsen van de tags ingevuld.
Dit is niet helemaal fullproof en ook geen totale scheiding van code en inhoud, maar het werkt goed. je hebt er ook totaal geen template engine oid. voor nodig.

[Bosmonster]

Als je echt indruk wilt maken met technische vooruitstrevendheid, gebruik dan XML/XSLT ipv PHP-template-gevallen

[mr.inno]

gewoon
tpl + php + xhtml.
dat is denk ik het beste om alles gescheiden te houden..
maar warom sheiden.. ?
ik gebruik meestal gewoon tpl overgens.

[Not Pingu]

Bosmonster schreef op 28 August 2003 @ 14:54:
Als je echt indruk wilt maken met technische vooruitstrevendheid, gebruik dan XML/XSLT ipv PHP-template-gevallen

maar XSLT werk toch client-side? daarom is het nog een compatibiliteitsprobleem. als elke browser XML/XSLT een beetje gaat ondersteunen wordt dat pas echt een optie (intranetten en andere gesloten gebruikersomgevingen daargelaten)

[Soultaker]

Gunp01nt schreef op 28 August 2003 @ 15:18:
maar XSLT werk toch client-side? daarom is het nog een compatibiliteitsprobleem. als elke browser XML/XSLT een beetje gaat ondersteunen wordt dat pas echt een optie (intranetten en andere gesloten gebruikersomgevingen daargelaten)

Waarom zou je de transformaties niet server-side uit kunnen voeren en de resulterende (XHTML) code naar de client kunnen sturen? Hoewel client-side XSLT om een aantal redenen misschien beter zou zijn, betekent dat niet dat het niet server-side kan.

[PrisonerOfPain]

Gunp01nt schreef op 28 August 2003 @ 15:18:
[...]


maar XSLT werk toch client-side? daarom is het nog een compatibiliteitsprobleem. als elke browser XML/XSLT een beetje gaat ondersteunen wordt dat pas echt een optie (intranetten en andere gesloten gebruikersomgevingen daargelaten)

XSLT kan clientside je kan de XML + XSLT ook gewoon via een php script parsen

http://www.devshed.com/Server_Side/XML/XSLBasics

en

http://www.devshed.com/Server_Side/XML/XSLTrans

[mr.inno]

maar niet elke brouwser ondersleund het weer.

[PrisonerOfPain]

mr.inno schreef op 28 August 2003 @ 15:36:
maar niet elke brouwser ondersleund het weer.

De browser hoeft alleen (X)HTML te ondersteunen, omdat de XSL Transformatie serverside gebeurt, en zal de client daar dus nimmer mee te maken hebben, noch weten dat er XSL+XML gebruikt word , verder kan je nog veeeeeeeeel meer met XSLT als alleen (X)HTML documenten maken

[mr.inno]

al onderstuenne.
IE
Mozila
Netschaap
Opera
Liks
wel xhtml

[PrisonerOfPain]

mr.inno schreef op 28 August 2003 @ 15:39:
al onderstuenne.
IE
Mozila
Netschaap
Opera
Liks
wel xhtml

??? ik kan m ff niet volgen hoor, mischien iets minder snel typen,

[mr.inno]

xhtml word door redleijk wat brouwsers ondersteund.. kwam ik net toch achter..

[PrisonerOfPain]

jup

Netscape Navigator: Version 3+ will support most tags. Version 6+ supports XHTML1.1 well.
Internet Explorer: Version 3+ will support most tags. Version 5.5+ supports XML and XHTML1.1 well.
Amaya: supports XHTML1.1 fully.
Mozilla: supports XHTML1.1 well.

bron: http://www.tomoakley.net/xml/xhtml.xhtml

edit:

verkeerde stuk ge-quote, andere stuk ging over XHTML 2.0, en is te vinden op
http://www.w3.org/TR/2003...0030506/introduction.html

[ Voor 72% gewijzigd door PrisonerOfPain op 28-08-2003 15:51 ]

[Johnny]

XHTML wordt goed ondersteund, maar clientside XSL niet echt.

Hte gebruik van XHTML en CSS kan ik wel aanraden, het is wel even doorbijten maar als je het uiteindelijk onder de knie hebt gaat er een wereld voor je open.

[PrisonerOfPain]

Johnny schreef op 28 August 2003 @ 15:50:
XHTML wordt goed ondersteund, maar clientside XSL niet echt.

Hte gebruik van XHTML en CSS kan ik wel aanraden, het is wel even doorbijten maar als je het uiteindelijk onder de knie hebt gaat er een wereld voor je open.

daarom vond ik server-side XSL al z'n leuk idee

XSL is zowiezo aan te raden boven een eigen template engine, omdat php dr ten eerste al een zelf heeft en ten tweede omdat het veele malen sneller is als de meeste omdat de meeste gebruik maken van regexp's die bij elke aanroep de hele pagina doorlopen, waar Sablotron (de standaard XSL Transformatie-engine in php) de pagina maar een keer doorloopt

edit:

het parser geblaat hierboven

[ Voor 38% gewijzigd door PrisonerOfPain op 28-08-2003 16:07 ]

[mbravenboer]

[rml][ php] Template engine vs. XML + XSLT[/rml]

Voor meer topics:
zoek op xslt, xml, php

[Verwijderd]

whow dat klinkt veelbelovend allemaal!!

Zoals ik het nu voor me zie zou ik zoiets kunnen/willen/gaan maken:
1) via php data ophalen uit database -> converteren naar xml file
2) xslt stylesheet maken
3) via php deze beide files "mergen" en printen.

Hoe is de performance van zo'n constructie? Als je grote (veel omvattende) pagina's hebt is dit dan nog wel haalbaar?

He ik krijg er helemaal zin in!!

[PrisonerOfPain]

Verwijderd schreef op 28 August 2003 @ 17:34:

1) via php data ophalen uit database -> converteren naar xml file

Ik weet niet wat je allemaal in je database wilt zetten maar is het niet beter om, als het kan, het gewoon native XML te gebruiken, dat is natuurlijk gewoon sneller, en het kan gemakkelijk met de PEAR XMLTREE class te vinden op:

http://pear.php.net/package/XML_Tree

[mbravenboer]

Houd wel een beetje in de gaten dat PHP een Hypertext Preprocessor is. Misschien is het wel heel goed dat je signaleert dat je presentatie (html) te veel verweven is met de echte applicatie, maar is het dan wel de goede stap om de applicatie in PHP te houden en de presentatie te verplaatsen naar een transformatie in XSLT van XML naar XHTML?

Begrijp me goed: zoals je in de search kan vinden ben ik een groot liefhebber van XML en XSLT oplossingen, maar misschien dat het je precies het verkeerde element verwijderd uit PHP: PHP zou je misschien meer als concurrent van een XSLT transformatie naar XHTML moeten zien.

Je moet dus in feite twee vragen beantwoorden:
* In welke taal/platform implementeer ik de kern van m'n applicatie?
* In welke taal ga ik de zaak presenteren?

Nu doe je beide in PHP en ook nog erg door elkaar heen. Je overweegt nu om de presentatie te verhuizen naar XSLT, maar dan blijft er dus nog een deel over waarvoor je ook een keuze kan maken: de kern van de applicatie. Waarom kies je op dit punt nog voor PHP? Was PHP niet juist gunstig als je iets wilt presenteren? Waarom die laag niet implementeren in Java, .NET, of Python?

[Verwijderd]

mbravenboer: ik kan je verhaal niet helemaal volgen, maar ik zal de situatie proberen iets duidelijker uit te leggen.

Wat ik wil doen is het volgende:
Een dynamische site maken, waarbij informatie uit de database gepresenteerd wordt aan de gebruiker. Oud of nieuwe browser, onder beide moet het werken.

Mijn eis om het project uitdagender te maken:
* query's & code zoveel mogelijk en het liefst geheel scheiden van de (x)HTML output.

Realistatie:
* query's uitvoeren in PHP en PHP een XML file laten genereren.
* XSLT templates voor de opmaak van de pagina's
* Om het ook voor oude browsers te laten werken, de XML & XSLT laten mergen door PHP die de output print.

Het is voor mij allemaal nieuw dit, dus misschien zit er wel een flinke kronkel in mijn idee?!
De eis is echter wel dat het onder apache/ux/mysql komt te draaien. Dus dat sluit een hoop uit en de voorkeur van het bedrijf waar ik stage ga lopen is dat PHP de basis wordt....

[mbravenboer]

IceFlame: ik kan je verhaal niet helemaal volgen, maar ik zal de situatie proberen iets duidelijker uit te leggen.

Volgens mij kan je het wel aardig volgen want je legt de scheiding al aardig aan .

Mijn eis om het project uitdagender te maken:
* query's & code zoveel mogelijk en het liefst geheel scheiden van de (x)HTML output.

Precies, (X)HTML output is wat ik (en vele anderen) presentatie noemen.

Realistatie:
* query's uitvoeren in PHP en PHP een XML file laten genereren.

Das de kern van de applicatie. Vaak wordt die afhankelijk van de requirements en de omvang van de applicatie nog in meer lagen opgedeeld. Voor dit deel moet je dus een taal/platform/oplossing kiezen. Het is niet vanzelfsprekend dat je dit in PHP blijft doen. Sterker nog: in theorie zou je gezien het doel van PHP juist dit deel willen verkassen naar een andere taal/platform.

[Verwijderd]

Sterker nog: in theorie zou je gezien het doel van PHP juist dit deel willen verkassen naar een andere taal/platform.

Over dit punt heb ik verder nog niet zo nagedacht eigenlijk?
Waarom zou ik dit willen verplaatsen? Zijn er talen die dit sneller & beter kunnen?

Wat mijn keuze vrijheid wel beperkt is dat er nu al een aantal modules zijn ontwikkeld door een stagair voor mij. Deze zijn gemaakt in PHP en ik zal ze moeten gaan implementeren in mijn nieuwe ontwerp... (dat wordt zowiezo al een dobber volgens mij).

Voor de omvang van de beheermodule die ik ga ontwikkelen is deze hele opzet totale overkill, maar het is voor mezelf weer een extra leerdoel/prestige project. Ik sta open voor alle suggesties & ideeen om dit zo mooi/efficient mogelijk te gaan realiseren.

[ Voor 3% gewijzigd door Verwijderd op 28-08-2003 18:04 ]

[djc]

Het is waarschijnlijk in verband met performance bij gebruik van XSLT wel aan te raden een mooie cache in te bouwen. Wat dit betreft kun je misschien bij elke mogelijke URL een cache bestandje aanmaken zodra de pagina wordt aangevraagd, en alle desbetreffende cache-bestandjes te verwijderen wanneer dat nodig is in verband met een aanpassing aan content of design. Hiermee kun je veel opgevraagde pagina's heel snel serveren, terwijl je niet elke keer dat er iets veranderd wordt de hele site opnieuw hoeft te genereren.

[ Voor 3% gewijzigd door djc op 29-08-2003 03:18 ]

[Verwijderd]

Ik ben vandaag weer verder aan het filosoferen over het idee en wat dingen aan het uit tekenen, maar het lijkt met de minuut complexer te worden.

Mijn idee is nu ongeveer zo:
- de website bezoeker vraagt een pagina op:
* home.php wordt geladen, in home.php staat een lijst met functies die aangeroepen moeten worden om alle data op te halen. (ik denk erover om aparte functie files te maken, zodat deze gescheiden zijn en herbruikbaar, tevens om de xml output gelijk te houden)
De functies genereren gezamenlijk een xml bestand, welke ik vervolgens aanroep.
* Het xml bestand opent de xsl(t) template en genereerd de (x)HTML output.

Waar ik nog vraagtekens heb:
* Slaat dit idee uberhaupt ergens op?!
* Als er meerdere gebruikers tegelijk pagina's opvragen, hoe ga ik dat in deze situatie goed afhandelen. (aangezien verschillende gebruikers, verschillende rechten ed hebben in de beheermodule)
* Kan ik sessie's ed blijven gebruiken op deze manier?
* Werkt dit ook in oude browsers? Of moet ik dan de xml&xsl mergen en echo'en via php?

[Verwijderd]

Misschien ligt et aan mij hoor maar:

waarom sla je de data op in een database en later nog eens in xml !?
is dat niet dubbelop...

[ Voor 2% gewijzigd door Verwijderd op 29-08-2003 19:22 . Reden: typo ]

[djc]

Voor compatibility met oudere browsers zou je inderdaad de XSL transformatie op de XML moeten uitvoeren op de server. Eventueel zou je ook nog een soort cache kunnen toevoegen aan home.php.

[Verwijderd]

waarom sla je de data op in een database en later nog eens in xml !?
is dat niet dubbelop...

/me zoekt naar een mooie uitleg... ah gevonden!

XML is essentially just a data transfer format, and has very little to do with storage, so you can't really compare XML with a database. Many systems use the two together, storing chunks of XML in the database, specifying database queries in XML, formatting retrieved data in XML and so on..
An XML file may be a better choice than a database if the data is small, fundamentally hierarchical and doesn't change much. This is why a lot of applications store their configurations as XML files.

Voor compatibility met oudere browsers zou je inderdaad de XSL transformatie op de XML moeten uitvoeren op de server.

daar was ik al bang voor idd, ga ik eens even mee stoeien

Eventueel zou je ook nog een soort cache kunnen toevoegen aan home.php.

dat is lastig denk ik, aangezien verschillende gebruikers met verschillende rechten dezelfde home.php kunnen aanroepen...

[sjokki]

Ik vind het een beetje vreemd dat XSLT genoemd wordt in een topic dat gaat over het scheiden van HTML en code. Met XSLT staat de HTML namelijk midden tussen de presentatie-logica. De presentatie-logica gebruikt zelfs een syntax die sterk lijkt op HTML. Je kan XSLT gebruiken in een script waarin de business- en presentatie-logica gescheiden zijn, maar als hulpmiddel om HTML en logica van elkaar te scheiden is het niet geschikt.

Er zijn in PHP twee groepen XSLT-functies. De XSLT-functies op http://nl3.php.net/manual/en/ref.domxml.php , deze maken gebruik van libxslt en gebruiken als input en output een DOM-object, wat vooral voordelig als je het xml-document al in een DOM-object hebt. De functies op http://nl3.php.net/manual/en/ref.xslt.php maken gebruik van Sablotron en hebben een bestand of een string als input en output.

Ik zie eigenlijk geen enkele reden om de transformatie client-side te doen. Als je het server-side doet weet je zeker dat het altijd goed gaat.

[Verwijderd]

sjokki schreef op 30 augustus 2003 @ 02:17:
Ik vind het een beetje vreemd dat XSLT genoemd wordt in een topic dat gaat over het scheiden van HTML en code. Met XSLT staat de HTML namelijk midden tussen de presentatie-logica. De presentatie-logica gebruikt zelfs een syntax die sterk lijkt op HTML. Je kan XSLT gebruiken in een script waarin de business- en presentatie-logica gescheiden zijn, maar als hulpmiddel om HTML en logica van elkaar te scheiden is het niet geschikt.

Oeioei, dat is wel heel kortzichtig.

Zoals je neem ik aan weet, gebruikt XSLT XML als input (dat is iig gebruikelijk).
Dat houd dus in dat je scripts xml uitpoepen en dat je dan of aan de server kant, of aan de client kant de XSL en XML code verenigt.

Dat is dus perfecte scheiding van je logica 'layers'.
Te meer omdat het onmogelijk is om php te coden in je templates.

Bijkomend voordeel is dat je perfect XHTML genereert, omdat het anders simpelweg niet door de parser (client of server) geaccepteerd word.

Zie ook deze discussie: http://gathering.tweakers.net/forum/list_messages/747881.

Ik zie eigenlijk geen enkele reden om de transformatie client-side te doen. Als je het server-side doet weet je zeker dat het altijd goed gaat.

Kost minder server power om het aan de client kant te doen.

[ Voor 10% gewijzigd door Verwijderd op 30-08-2003 12:50 . Reden: quote erbij ]

[Verwijderd]

agree with nextGeneration!

Kost minder server power om het aan de client kant te doen.

nadeel is alleen wel weer dat oude browsers deze vertaalslag niet kunnen maken voor zover ik begrepen heb. Dus is server side weer een beter betrouwbare oplossing.

[sjokki]

Verwijderd schreef op 30 August 2003 @ 12:49:
[...]

Oeioei, dat is wel heel kortzichtig.

Zoals je neem ik aan weet, gebruikt XSLT XML als input (dat is iig gebruikelijk).
Dat houd dus in dat je scripts xml uitpoepen en dat je dan of aan de server kant, of aan de client kant de XSL en XML code verenigt.

Dat is dus perfecte scheiding van je logica 'layers'.
Te meer omdat het onmogelijk is om php te coden in je templates.

Een probleem in dit topic is de vaagheid van de gebruikte begrippen. Het begint met "scheiden van HTML en code". Omdat HTML ook een soort "code" is dus niet daarvan gescheiden kan worden heb ik in mijn eerste reply maar aangenomen dat "scheiden van html en logica" bedoeld werd. Mijn punt was dat het scheiden van HTML en logica moeilijk gaat met XSLT. Waarop jij zegt dat XSLT een perfecte scheiding is tussen logica-layers. Blijkbaar heb jij "scheiden van html en code" vertaald als "scheiden van presentatie-logica en business-logica". Dat is begrijpelijk omdat het scheiden van presentatie-logica en business-logica een redelijk algemeen streven is. De termen presentatie-logica en business-logica zijn ook in meerdere boeken gedefinieerd. Overigens heb ik ook gezegd dat XSLT wel samengaat met zo'n scheiding.

Maar ik heb moeite met de stelling dat XSLT zorgt voor een "perfecte scheiding" van deze logica layers. Stel je een applicatie voor waarin de kolomnamen uit een database rechtstreeks worden vertaald naar een XML-string die daarna wordt verwerkt door een XSLT-processor. Business-logica en presentatie-logica zijn dan gescheiden, maar er is wel "tight coupling" tussen de database en de presentatie-layer. Als een kolom in de database van naam veranderd moet je de stylesheets aanpassen. Dus de door XSLT afgedwongen scheiding is slechts zwak. Als je een sterkere scheiding wil zal je met encapsulatie-technieken aan de gang moeten.

XSLT is een mooie taal voor het uitvoeren van XML-transformaties en dus presentatie-logica. Maar het is geen wondermiddel waarmee je automatisch alle scheiding krijgt die je kan wensen.

[Verwijderd]

sjokki -> als je alle posts voor je gelezen had, dan had je je een hele hoop typwerk kunnen besparen....

Business-logica en presentatie-logica zijn dan gescheiden, maar er is wel "tight coupling" tussen de database en de presentatie-layer.

true, maar dit is in mijn geval totaal niet aan de orde. Het gaat in de door mij geschetste situatie helemaal niet over het "dom" heen en weer gooien van data direct uit de database naar xml.

Maar het is geen wondermiddel waarmee je automatisch alle scheiding krijgt die je kan wensen.

nee duh, daar heb je je business-logica voor.

aan de hele opzet ligt wel wat meer ten grondslag dan jij nu schetst..

[Verwijderd]

sjokki schreef op 31 August 2003 @ 02:17:
Een probleem in dit topic is de vaagheid van de gebruikte begrippen. Het begint met "scheiden van HTML en code". Omdat HTML ook een soort "code" is dus niet daarvan gescheiden kan worden heb ik in mijn eerste reply maar aangenomen dat "scheiden van html en logica" bedoeld werd. Mijn punt was dat het scheiden van HTML en logica moeilijk gaat met XSLT. Waarop jij zegt dat XSLT een perfecte scheiding is tussen logica-layers. Blijkbaar heb jij "scheiden van html en code" vertaald als "scheiden van presentatie-logica en business-logica". Dat is begrijpelijk omdat het scheiden van presentatie-logica en business-logica een redelijk algemeen streven is. De termen presentatie-logica en business-logica zijn ook in meerdere boeken gedefinieerd. Overigens heb ik ook gezegd dat XSLT wel samengaat met zo'n scheiding.

Formeel heb je gelijk als je zegt dat "scheiden van html en code" heel wat anders is als "scheiden van presentatie-logica en business-logica" (hoewel het verschil nihil is).
Maar vanaf de eerste reply werden deze begrippen gelijk getrokken en de topicstarter doelde blijkbaar ook op het scheiden van de logica layers.

Maar ik heb moeite met de stelling dat XSLT zorgt voor een "perfecte scheiding" van deze logica layers. Stel je een applicatie voor waarin de kolomnamen uit een database rechtstreeks worden vertaald naar een XML-string die daarna wordt verwerkt door een XSLT-processor. Business-logica en presentatie-logica zijn dan gescheiden, maar er is wel "tight coupling" tussen de database en de presentatie-layer.

Ik snap je punt hier niet echt.
Het feit dat de data die in het voorbeeld getoont wordt direct uit de database komt doet er niet toe.
In het voorbeeld zal de business logica geen berekeningen uitvoeren, maar het direct naar xml omzetten. Daarmee blijft het punt staan dat je je layers gescheiden wilt houden.

Stel nu dat je in het voorbeeld je resultaat in xhtml toont.
Maar nu wil je klant dat je het ook in pdf formaat kan downloaden.
Als je het met xml en xsl hebt gedaan, hoef je alleen je presentation layer te veranderen (nog een aanmaken) en hou je je input gewoon (want die had je al gemaakt).

Als een kolom in de database van naam veranderd moet je de stylesheets aanpassen. Dus de door XSLT afgedwongen scheiding is slechts zwak.

Ook als je je code niet scheidt (of je layers niet scheidt) dan moet je dat nog steeds aanpassen.
De scheiding is overigens niet sterker of zwakker als anders.

Als je een sterkere scheiding wil zal je met encapsulatie-technieken aan de gang moeten.

Hoe zou je een sterkere scheiding willen afdwingen met 'encapsulatie-technieken'?

XSLT is een mooie taal voor het uitvoeren van XML-transformaties en dus presentatie-logica. Maar het is geen wondermiddel waarmee je automatisch alle scheiding krijgt die je kan wensen.

Met xsl kan je een zeer sterke scheiding creeren, waarbij je een algemeen geaccepteerde taal gebruikt en geen code kan invoegen (alles kan, maar de verleiding is stukken kleiner) die in de business layer thuis hoort.

[sjokki]

Excuses voor de wat late reactie

Verwijderd schreef op 31 August 2003 @ 21:19:
sjokki -> als je alle posts voor je gelezen had, dan had je je een hele hoop typwerk kunnen besparen....


[...]

true, maar dit is in mijn geval totaal niet aan de orde. Het gaat in de door mij geschetste situatie helemaal niet over het "dom" heen en weer gooien van data direct uit de database naar xml.


[...]

nee duh, daar heb je je business-logica voor.

aan de hele opzet ligt wel wat meer ten grondslag dan jij nu schetst..

Ik wilde zeker niet suggereren dat jouw script simpel in elkaar zit. Het was een reactie op "perfecte scheiding van logica 'layers'". Ik wilde aantonen dat het gebruik van XSLT niet automatisch voor een perfecte scheiding zorgt.

[sjokki]

Verwijderd schreef op 31 augustus 2003 @ 23:33:
Hoe zou je een sterkere scheiding willen afdwingen met 'encapsulatie-technieken'?

Bijvoorbeeld door de data in een object te verpakken met getters en setters. Of, wat dieper, door de SQL-queries voor iedere tabel uit te schrijven zodat je "SELECT ... AS ..." kan gebruiken. De sterkere scheiding wordt dan gecreeerd aan de datakant, dus het wel of niet gebruiken van XSLT staat daar los van.

Met xsl kan je een zeer sterke scheiding creeren, waarbij je een algemeen geaccepteerde taal gebruikt en geen code kan invoegen (alles kan, maar de verleiding is stukken kleiner) die in de business layer thuis hoort.

Daar ben ik het helemaal mee eens. Vooral met het woord 'kan'

Als iemand om scheiding van html en code vraagt wordt er vrijwel altijd verwezen naar templates en XSLT. Terwijl het logischer zou zijn om aan te raden om een boek over layers en applicatie architectuur te lezen. Ik denk dat voor webdevelopers PoEAA een nuttig boek is. Overigens staan templates en XSLT daar ook in, maar PHP staat er in als voorbeeld van een templatetaal.