[PHP] Ideeen voor framework

[cytherea]

Ik ben al een tijdje aan het brainstormen over een framework die ik wil gaan bouwen. Het moet een framework worden die voor elke website inzetbaar is (dus hele klein maar ook hele grote sites). Ik heb al avonden gezocht op internet en kan geen enkel framework vinden wat op een dergelijk niveau werkt.

Een paar dingen wat het zou moeten kunnen:
- Multi site (dus meerdere websites met dezelfde software)
- Meerdere talen (dus eenvoudig kunnen schakelen naar verschillende talen)
- Meerdere layout (dus de layout onafhankelijk van de software en eventueel uitvoer naar XML/WML/enz..)
- Transparante url's (dus dat je zelf kan opgeven waar een url naar moet verwijzen)
- Bestaan uit modules (dus dat voor een hele kleine site maar een of twee modules erop hoeven te staan maar voor grotere sites meerdere modules)
- Koppelingen met diverse databases. (MySQL/Postgres/enz..)
- Functionaliteiten voor bijvoorbeeld XML-RPC/SOAP

Is wel een erg lang lijstje aan het worden

Ongeveer 50% van deze dingen heb ik al werkend, of tenminste ik heb er ideeen over hoe ik het werkend kan krijgen. Ik gebruik ideeen uit allerlei diverse software pakketten (PEAR, PHPLib, PHPMvc, Struts) alleen is dit handig? Elke software heeft zijn eigen benadering en die moet ik allemaal gebruiken en implementeren, ik heb het idee dat de software hier een beetje een zooitje van word. Maar aan de andere kant alles zelf bouwen is ook geen optie dan ben ik over 10 jaar nog bezig.

Heeft iemand van jullie hier ideeen over of misschien al zo'n zelfde project lopen?? Ik post dit vooral om wat andere ideeen te zien die mij misschien kunnen helpen.

Of als er iemand is die het leuk vind om deze ideeen uit te werken dan vooral posten!! Ik heb namelijk het idee dat dit een erg ambititeus project gaat worden...

[whoami]

Hmmm, .... waarom wil je dat perse zelf ontwikkelen voor PHP?
Het .NET framework van MS heeft eigenlijk al al deze functionaliteit.

[cytherea]

Op zich een goed punt maar ik ben het niet eens met de policy van Microsoft dus ik gebruik die software van hun niet. En het LAMP platform heeft zich al bewezen dus daar wil ik graag op door bouwen.

[MisterData]

Je kunt voor PHP je code en HTML scheiden met een zgn. template-parser. Je beschrijft dan in een template de layout, en vanuit de PHP-file genereer je dan op basis van die template de layout. Het werkt heel simpel, voorbeeldje:

PHP:

<?php
require("tpl.php");
// test.php
$tpl = loadTemplate('template.tpl');
addTemplateVar($tpl,"tijd",time($tpl));
validateTree($tpl,false);
echo parseTemplate($tpl,false);
?>

code:

template.tpl:

De tijdcode is %tijd% !

Het bovenstaande voorbeeld werkt iig met mijn zelfgeschreven, stackbased template-parser Ik gebruik hem tegenwoordig voor vanalles en nogwat, en ik moet zeggen dat ik achteraf blij ben dat ik de moeite heb genomen dat ding van 500 regels te schrijven. Je mag hem gratis gebruiken van me, je mag hem zelfs aanpassen, lees maar bovenaan tpl.php voor de 'licentie' (zlib-style).

Als je nog voorbeeld-templates zoekt, dan kun je altijd contact met me opnemen.

Er zijn ook andere template-parsers natuurlijk: een hele bekende is Smarty, maar als je goed zoekt dan vind je er een hoop. Ik heb zelf echter weinig stackbased template-parsers gezien (vandaar dat ik hem zelf heb geschreven). Stackbased wil zeggen dat je If's, else's en foreaches kunt gebruiken in je template en die ook kunt nesten. Normale template-parsers doen meestal alleen aan het vervangen van %variabele% met iets anders...

Hoop dat dit je iets verder helpt.

edit:
nog even iets over het project waar ik mee bezig ben...

Ik ben een CMS aan het maken, dat geheel te templaten is, en voorziet in alle features die een middelgroot- of klein bedrijf nodig heeft. Het CMS is perfect geschikt ook voor verenigingen (zie www.bkvdenbosch.nl). Het kan niet alleen pagina's maken, maar ook thumbnails, plaatjesupload, automatische formulieren met regex-validatie, polls, shoutbox zit ingebouwd, MD5-challenge login.....
Door het gebruik van templates is het dus goed mogelijk om bijvoorbeeld verschillende uitvoerformaten te gebruiken: je maakt bijvoorbeeld een template voor HTML-uitvoer, maar ook eentje voor WML-uitvoer en nog wat formaten. Eventueel zou je het templaten kunnen vergelijken met een XSLT-transformatie.

[ Voor 27% gewijzigd door MisterData op 30-10-2003 10:56 ]

[Verwijderd]

cytherea schreef op 30 oktober 2003 @ 10:41:
Ongeveer 50% van deze dingen heb ik al werkend, of tenminste ik heb er ideeen over hoe ik het werkend kan krijgen. Ik gebruik ideeen uit allerlei diverse software pakketten (PEAR, PHPLib, PHPMvc, Struts) alleen is dit handig? Elke software heeft zijn eigen benadering en die moet ik allemaal gebruiken en implementeren, ik heb het idee dat de software hier een beetje een zooitje van word. Maar aan de andere kant alles zelf bouwen is ook geen optie dan ben ik over 10 jaar nog bezig.

Heeft iemand van jullie hier ideeen over of misschien al zo'n zelfde project lopen?? Ik post dit vooral om wat andere ideeen te zien die mij misschien kunnen helpen.

Of als er iemand is die het leuk vind om deze ideeen uit te werken dan vooral posten!! Ik heb namelijk het idee dat dit een erg ambititeus project gaat worden...

Ik heb zelf bijna heel struts geport naar php (veel completer dan de bestaande struts implementaties in php). Daarnaast gebruik ik van jphp de classregistry zodat ik klassen kan 'inporten'. Het schema van de top-level configuratiefile heb ik aangepast zodat ik daarin meerdere sites kan configureren en aangeven van welke modules deze site gebruik maakt en op welk path deze modules zitten.

Het grote nadeel is dat importen van veel bestanden in php nogal wat tijd kost. Daarnaast kost ook het interpreteren van de verschillende configuratiebestanden nogal veel tijd kost (een van de door jou genoemde php libs had geloof ik een implementatie van de Digester in php welke ik ook gebruik). Ik stop het object model van de configuratie daarom in de sessie. Zo kost dat alleen de eerste keer veel tijd. Ik moet nog maken dat ie op een of andere manier ziet dat de configuratie gewijzigd is want alle browserwindows sluiten om de configuratie te reloaden is niet handig

Ook de ActionServlet en de RequestProcessors stop ik in de sessie (eigenlijk stop ik die in de ServletContext en sla ik per site een ServletContext in de sessie). Dat scheelt ook weer een beetje tijd.

Verder zit er in struts eigenlijk wel alles wat jij hierboven beschreven hebt en dat had ik zelf ook nodig

Omdat mijn struts geen taglibs heeft (doh) heb ik dat opgelost door een Template object (de template van phpbb, die is wel prettig met z'n blocks) in het Response object te stoppen. Daar kunnen Action klassen dan weer gebruik van maken.

Ik weet niet of je de MessageResources van struts al had gezien. Zoiets wil je ook Erg prettig.

[cytherea]

MisterData schreef op 30 oktober 2003 @ 10:51:
Je kunt voor PHP je code en HTML scheiden met een zgn. template-parser. Je beschrijft dan in een template de layout, en vanuit de PHP-file genereer je dan op basis van die template de layout. Het werkt heel simpel, voorbeeldje:

Er zijn ook andere template-parsers natuurlijk: een hele bekende is Smarty, maar als je goed zoekt dan vind je er een hoop. Ik heb zelf echter weinig stackbased template-parsers gezien (vandaar dat ik hem zelf heb geschreven). Stackbased wil zeggen dat je If's, else's en foreaches kunt gebruiken in je template en die ook kunt nesten. Normale template-parsers doen meestal alleen aan het vervangen van %variabele% met iets anders...

Hoop dat dit je iets verder helpt.

edit:
nog even iets over het project waar ik mee bezig ben...

Ik ben een CMS aan het maken, dat geheel te templaten is, en voorziet in alle features die een middelgroot- of klein bedrijf nodig heeft. Het CMS is perfect geschikt ook voor verenigingen (zie www.bkvdenbosch.nl). Het kan niet alleen pagina's maken, maar ook thumbnails, plaatjesupload, automatische formulieren met regex-validatie, polls, shoutbox zit ingebouwd, MD5-challenge login.....
Door het gebruik van templates is het dus goed mogelijk om bijvoorbeeld verschillende uitvoerformaten te gebruiken: je maakt bijvoorbeeld een template voor HTML-uitvoer, maar ook eentje voor WML-uitvoer en nog wat formaten. Eventueel zou je het templaten kunnen vergelijken met een XSLT-transformatie.

Ik had zelf Smarty ook al ontdekt en al gebruikt bij verschillende projecten en dat is me erg goed bevallen. Verder ben ik wel bekend met verschillende templatje-parsers.

Ik ben wel benieuwd wat voor CMS dat precies is, kun je me daar wat meer details over vertellen???

[xces]

Zelf heb ik een "framework" geschreven,
- dat controleert de browser van de bezoekers
- of ze cookies hebben aanstaan
- javascript 1.2 minimaal hebben
- frames kunnen weergeven
- flash 6 hebben

dit alles mbv een php file en een stuk javascript wat de frameset code print. Ik ondersteun op mijn websites Netscape 6+, Opera 7+, IE4+ (op mac IE5+) en natuurlijk mozilla 1+ en Safari. Eigengelijk kijk in in de useragent string naar IE of Netscape 4, bij gecko based browsers kijk ik naar het build nummer van Gecko, ik ondersteun browsers die een nieuwere engine build hebben dan "20030000" die build bestaat niet, maar betekend simpelweg, een build die dit jaar gedaan is of later.

Klinkt stom maar alleen zo weet ik dat de bezoeker de site ervaart zoals ik hem gemaakt heb. Ze krijgen een foutmelding als ze de foute browser hebben en een waarschuwing met mogelijkheid om door te gaan als ze 1 of meerdere items niet ondersteunen; "Het kan zijn dat u fouten krijgt maar bekijk gerust de site" of zoiets...

Ik doe het zo:

code:

PHP -> browsercheck
  OK: template met flash 6 detectie
    OK: Frameset geprint
      OK: Klaar
      KO: geen frames capable browser
    KO: Geen flash 6
  KO: Geen javascript aanstaan
KO: Sorry pagina

Ow ja, en buiten dat doe ik ook mijn PHP code en MYSQL code timen en meteen GZIP output als de browser dat ondersteund

[ Voor 7% gewijzigd door xces op 30-10-2003 11:08 ]

[cytherea]

Verwijderd schreef op 30 oktober 2003 @ 10:52:
[...]


Ik heb zelf bijna heel struts geport naar php (veel completer dan de bestaande struts implementaties in php). Daarnaast gebruik ik van jphp de classregistry zodat ik klassen kan 'inporten'. Het schema van de top-level configuratiefile heb ik aangepast zodat ik daarin meerdere sites kan configureren en aangeven van welke modules deze site gebruik maakt en op welk path deze modules zitten.

Heb je ergens wat voorbeeldcode van een module ofzo? Ik vond struts namelijk behoorlijk ingewikkeld inelkaar zitten, maar misschien was dat een brakke implementatie. Misschien dat jouw implementatie wat makkelijker is?

[Verwijderd]

cytherea schreef op 30 oktober 2003 @ 11:08:
[...]

Heb je ergens wat voorbeeldcode van een module ofzo? Ik vond struts namelijk behoorlijk ingewikkeld inelkaar zitten, maar misschien was dat een brakke implementatie. Misschien dat jouw implementatie wat makkelijker is?

Dat heeft niet zoveel zin. Het zijn nogal wat klassen. Een module bestaat uit een configfile, een heleboel acties, messages-files (voor elke taal een) en (eventueel) een module-specifieke RequestProcessor. Eigenlijk is het bijna precies de struts code (in java dus) omgezet naar php en alles wat ik niet nodig had eruit gesloopt.

[cytherea]

Verwijderd schreef op 30 oktober 2003 @ 11:18:
[...]


Dat heeft niet zoveel zin. Het zijn nogal wat klassen. Een module bestaat uit een configfile, een heleboel acties, messages-files (voor elke taal een) en (eventueel) een module-specifieke RequestProcessor. Eigenlijk is het bijna precies de struts code (in java dus) omgezet naar php en alles wat ik niet nodig had eruit gesloopt.

Ja dat viel mij ook al op van die implementatie die ik gevonden had, de grote hoeveelheid bestanden die er bij zaten.
Maar hoe heb jij dan zoiets als meerdere talen opgelost? In die implementatie van mij kon ik niet iets daarvoor ontdekken hoe dat makkelijk kan.

[MisterData]

cytherea schreef op 30 oktober 2003 @ 11:06:
[...]

Ik ben wel benieuwd wat voor CMS dat precies is, kun je me daar wat meer details over vertellen???

Om te beginnen even een paar sites waar m'n CMS draait:
http://www.qprcostcontrol.nl - Website van een bedrijf dat software en support levert
http://www.bkvdenbosch.nl - Kunstschaatsvereniging
http://dev.trag.nl/bkv/ - Zelfde site als bkvdenbosch.nl maar dan met eigen database, dit is waar ik de nieuwe versies test

Het is geschreven in PHP, er wordt geen OO gebruikt (leek me niet nodig en qua performance zelfs niet handig). Mijn template-parser is een belangrijk onderdeel in het CMS. Features:
• Pagina's toevoegen en verwijderen via admin, mogelijkheid tot nesten van pagina's oneindig diep. Voorzien van BB-parser.
• Loginsysteem met ranks per gebruiker, pagina's kunnen public, alleen voor registered users of voor een select groepje users beschikbaar zijn
• Forum, wederom gebaseerd op dit inlogsysteem
• Shoutbox, ook geintegreerd met het inlogsysteem, volledig te templaten
• Poll, en je raad het al, ook geintegreerd, en ook volledig te templaten
• Functie waarmee formulieren online kunnen worden samengesteld, inclusief regex-validatie
• Plaatjes en bestanden kunnen gemakkelijk via de admin worden geupload
• Bannen kan op IP en per gebruiker
• Thumbnailscript en albumfunctie
• Caching voor pagina's en thumbnails
• Bookmarkfuncties voor zowel pagina's als forumtopics
• Nieuwsfunctie

M'n CMS is in principe commercieel, meestal verkoop ik het aan een bedrijf samen met templates voor dat bedrijf en installatie. Het is gericht op gebruikers die niet al te veel van websites af weten, maar wel in het Nederlands de website willen aanpassen en zodoende actueel houden. Voor verenigingen (non-profit) geldt in overleg een korting.

Systeemeisen server: M'n CMS is getest met Apache 1.3.* en zowel MySQL 3 als 4 (recente versies). Verder werkt het onder PHP 4.3.2. Het CMS maakt geen gebruik van register_globals. Totaal zijn voor 1 website een stuk of 20 MySQL-tabellen nodig.

Dat zijn eigenlijk wel de hoofdpunten... Ik wil je eventueel wel toegang geven tot de admin van de testsite, dan kun je daar eens rondkijken.... mail me maar even als je dat wil.

[ Voor 7% gewijzigd door MisterData op 30-10-2003 11:39 ]

[Verwijderd]

cytherea schreef op 30 oktober 2003 @ 11:21:
[...]

Ja dat viel mij ook al op van die implementatie die ik gevonden had, de grote hoeveelheid bestanden die er bij zaten.
Maar hoe heb jij dan zoiets als meerdere talen opgelost? In die implementatie van mij kon ik niet iets daarvoor ontdekken hoe dat makkelijk kan.

Op basis van de locale wordt een bepaalde message resource geladen (eigenlijk een verzameling woorden en zinnen) voor een bepaalde taal. Die kun je dan weer gebruiken in je actions.

[Brakkie]

MisterData schreef op 30 oktober 2003 @ 11:37:
[...]

Dan weet ie toch nog niks over het programmeer framework waar je gebruik van maakt?

Denk dat ie meer een framework bedoel om programmeer technisch een standaard te ontwikkelen voor het afhandelen van zaken zoals:

- Acties
- Errors
- Templates
- Sessies
- Database connectie
- Enz.

[ Voor 17% gewijzigd door Brakkie op 30-10-2003 11:45 ]

[MisterData]

Brakkie schreef op 30 oktober 2003 @ 11:44:
[...]


Dan weet ie toch nog niks over het programmeer framework waar je gebruik van maakt?

Denk dat ie meer een framework bedoel om programmeer technisch een standaard te ontwikkelen voor het afhandelen van zaken zoals:

- Acties
- Errors
- Templates
- Sessies
- Database connectie
- Enz.

Qua acties zit m'n CMS niet bijster ingewikkeld in elkaar: iedere actie heeft z'n eigen PHP-pagina (make_page.php als voorbeeld). Daarin wordt bepaalde input 'gerequired'. Daar staat bijvoorbeeld een regel zoals requireNumericInput('id'). Eventueel zit daar nog validatie met een regex achter. De php-pagina geeft z'n fouten door aan 1 functie, die de foutafhandeling regelt (heet fatalError). Per pagina is er ook een template. Sessies worden geregeld vanuit 1 pagina die door alle andere wordt geinclude (heet page.php). Deze regelt het inloggen/uitloggen, sessievariabelen etc. De database-connectie zit in database_connection.php die weer wordt geinclude op page.php. Het zit allemaal retesimpel in elkaar, en dat is imho de kracht van dat CMS, en komt ook overeen met de doelgroep. KISS (Keep it simple, stupid) is misschien wel van toepassing...

[Martin Sturm]

D'r zijn inmiddels best wel wat frameworks voor php beschikbaar, en ik vraag me af of je in je eentje in staat bent om een kwalitatief hoogwaardig framework te schrijven (kwaliteit is wel vereist, anders is het gewoon niet meer vernieuwend en dus zonde van je werk). http://www.phppatterns.com/index.php/link/category/34/ vermeld een aantal frameworks.

Eclipse is bijvoorbeeld een zeer moei implementatie in volledige OO-code waarbij gebruik is gemaakt van allerlei design-patterns (http://www.phppatterns.co.../people/voostind/eclipse/)

Ook zijn er al best veel PHP-implementaties van struts. PHP-MVC is een bekende (www.phpmvc.org), Eocene http://www.eocene.net/ en phrame ( http://phrame.sourceforge.net/ ).

En dan zijn er nog een hoop die ik niet heb genoemd. Veel van die frameworks voorzien al in wat TC wil, en het is dus niet zo slim om het wiel weer helemaal opnieuw uit te vinden. Overigens, in Python is er ook nog een heel mooi framework, Zope. Dat voldoet volgens mij in alle opzichten aan wat TC wil, en is Open source, en zeer stabiel www.zope.com.

[MisterData]

Anders moet je es kijken naar Ariadne

[Verwijderd]

Ik heb ook ooit eens iets geschreven wat wel iets wegheeft van een framework... denk ik Ik heb het ooit geschreven voor een site, maar daar is het uiteindelijk niet echt op terecht gekomen, dus uiteindelijk werd het meer een soort van studieobject. Het is wellicht crappy as hell en slecht gecode, maar ik was er best trots op.

Het biedt de volgende functionaliteit:
- Registreer en login systeem
- Rechtensysteem
- Templateparser met ondersteuning voor simpele if-else en foreach
- Documentatie
En, wat ik persoonlijk nogal handig vind:
- Modulelader

Dit laatste houdt in dat je, als je een bepaalde functionaliteit mist, je deze zelf kan schrijven (gewoon in PHP) en deze vervolgens door het systeem kan laten gebruiken al ware het een onderdeel van het systeem.
Het framework biedt een interface voor de templateparser, databaseverbinding en wat ander functionaliteit.

Anyway, mocht je geïnteresseerd zijn in de code: Sourceforge/Mirror

[djc]

Ik gebruik zelf altijd een eigen framework, en in de laatste versie daarvan werk ik bouw ik in PHP XML documenten op die vervolgens door een XSL transformatie worden gejaagd. Het is wel een beetje afwachten of die module aanstaat op je server (maar ik heb ervoor gezorgd dat ie op alle servers waar ik voor ontwikkel aanstaat), maar het werkt wel immens prettig. Hele goede content-layout separatie, bovendien kan je een deel van de display logic in de template proppen in plaats van in je PHP.

[.oisyn]

MisterData schreef op 30 oktober 2003 @ 10:51 iets over templates

Ik heb het vaker gezegd, maar ik zeg het nog een keer: PHP blijft imho de beste template parser. Want waarom een parser schrijven in PHP terwijl het PHP prima zelf kan? Dat lijkt me een beetje dubbelop

PHP:

$template->page_title = "test";
$template->page_body = "woei";

include ("testtemplate.php");

testtemplate.php:

PHP:

<html>
<head>
    <title><?=$template->page_title?>
</head>
<body>
<?=$template->page_body?>
</body>
</html>

Het voordeel van PHP zelf als template parser is dat je gelijk gebruik kan maken van PHP's arsenaal aan functies en control flow statements.

[Verwijderd]

Heb je ook al naar TYPO3 gekeken? Dit is zooo uitgebreid en ik vind het geweldig

[Erkens]

.oisyn schreef op 31 oktober 2003 @ 03:12:
testtemplate.php:

PHP:

<html>
<head>
    <title><?=$template->page_title?>
</head>
<body>
<?=$template->page_body?>
</body>
</html>

Het voordeel van PHP zelf als template parser is dat je gelijk gebruik kan maken van PHP's arsenaal aan functies en control flow statements.

het enige nadeel aan dit concept is dat niet programmeurs lastiger met die files kunnen werken

[ripexx]

Erkens schreef op 31 oktober 2003 @ 07:37:
[...]

het enige nadeel aan dit concept is dat niet programmeurs lastiger met die files kunnen werken

Way offtopic maar een beetje html'er moet dit toch nog wel kunnen begrijpen. Hoe meer features hoe onoverzichtelijker het wordt en des te meer kennis is er nodig. Het blijft toch altijd een afweging.

[mjax]

Erkens schreef op 31 oktober 2003 @ 07:37:
[...]

het enige nadeel aan dit concept is dat niet programmeurs lastiger met die files kunnen werken

Tsja, als je met wat "geavanceerdere" template parsers aan de slag gaat, zit je ook al snel met if..then.else, foreach etc. constructies in je template. Dat is nu ook bepaald niet iets voor non-proggers.

Ik ben het helemaal met .oisyn eens dat PHP zelf de beste template parser is. Je ziet nl. vaak genoeg dat een template parser z'n doel voorbij schiet en allerlei languageconstructs uit PHP gaat overnemen in het template (getuige de if..then..else constructies). Waarbij op een gegeven moment het enige verschil tussen de template en PHP zelf bestaat uit de soort haakjes die gebruikt worden!

Als je data/content goed wilt scheiden ga dan meteen voor een XML/XSL systeem.

Persoonlijk vind ik de XSL transformaties vele malen lastiger te begrijpen, gebruiken en te debuggen dan PHP code, maar dat zal ook wel een gebrek aan kennis op dat vlak zijn!

In een groot project waar ik nu aan werk, gebruiken we ook gewoon PHP als "templateparser". Maar het is wel de bedoeling dat we op termijn overgaan naar XML/XSL transformaties.

[ Voor 7% gewijzigd door mjax op 31-10-2003 08:26 ]

[vargo]

mjax schreef op 31 oktober 2003 @ 08:24:
[...]


Tsja, als je met wat "geavanceerdere" template parsers aan de slag gaat, zit je ook al snel met if..then.else, foreach etc. constructies in je template. Dat is nu ook bepaald niet iets voor non-proggers.

Ik ben het helemaal met .oisyn eens dat PHP zelf de beste template parser is. Je ziet nl. vaak genoeg dat een template parser z'n doel voorbij schiet en allerlei languageconstructs uit PHP gaat overnemen in het template (getuige de if..then..else constructies). Waarbij op een gegeven moment het enige verschil tussen de template en PHP zelf bestaat uit de soort haakjes die gebruikt worden!

Als je data/content goed wilt scheiden ga dan meteen voor een XML/XSL systeem.

Persoonlijk vind ik de XSL transformaties vele malen lastiger te begrijpen, gebruiken en te debuggen dan PHP code, maar dat zal ook wel een gebrek aan kennis op dat vlak zijn!

In een groot project waar ik nu aan werk, gebruiken we ook gewoon PHP als "templateparser". Maar het is wel de bedoeling dat we op termijn overgaan naar XML/XSL transformaties.

Waarom 'in plaats van' en niet 'in combinatie met'?

[cytherea]

Manuzhai schreef op 31 oktober 2003 @ 02:44:
Ik gebruik zelf altijd een eigen framework, en in de laatste versie daarvan werk ik bouw ik in PHP XML documenten op die vervolgens door een XSL transformatie worden gejaagd. Het is wel een beetje afwachten of die module aanstaat op je server (maar ik heb ervoor gezorgd dat ie op alle servers waar ik voor ontwikkel aanstaat), maar het werkt wel immens prettig. Hele goede content-layout separatie, bovendien kan je een deel van de display logic in de template proppen in plaats van in je PHP.

Ik ben hier ook al een tijdje naar aan het kijken maar als ik het vergelijk met Smarty geef ik toch de voorkeur aan Smarty. In smarty zitten een aantal functies ingebakken zoals het omzetten van newline tekens naar br enzo.. en die functies zijn erg makkelijk, het versneld dingen wel enorm.
En met Smarty is ook een totale scheiding van layout en code te bereiken en dat is erg mooi.