[DISC] XML/XSLT vs. PHP

[Rhapsody]

Hallo

De vraag die ik mijzelf al een tijd lang stel is:
moet ik met PHP een template parser schrijven? of is het beter om over te stappen op XML/XSLT?.

De site die ik wil maken heeft een aantal dingen waardoor ik niet weet wat nu het beste is. Zo wil ik met templates gaan werken, en moet het mogelijk zijn om met rechten en meerdere gebruikers te kunnen werken. (Gebruiker A mag wel Onderdeel A zien, maar Gebruiker B mag dat niet etc)

Na het lezen van diverse draadjes hier op GoT, (zelfs uit het begin van deze eeuw) lijkt het alsof ik tegen steeds meer dingen aanloop die toch wel essentieel zijn.
Zelf heb ik ook het idee dat ik veel te moeilijk zit te denken.
in dit topic wordt een hele interessante discussie gevoerd, maar uiteindelijk blijf ik toch met vragen zitten.

Kan iemand mij uitleggen waarom hij/zij voor de een, dan wel de ander zou kiezen of heeft gekozen?

[alienfruit]

Waarom gebruik je PHP zelf niet als engine? Ik gebruik zelf vaak XML/XSLT maar dit is om dit het makkelijkst is om te delen tussen ASP.NET en PHP. Als je een eigen template parser of PHP gebruikt moet ik weer aan de ASP.NET kant hetzelfde schrijven en dan nog zorgen dat het synchroon loopt. Daarom heb ik zelf gekozen voor de XML/XSLT combinatie. (ook handig als je met andere systemen wilt communiceren imho)

Maar als je gebruik maakt van alleen PHP kun je PHP zelf ook gebruiken als de template engine, vaak is er niet een groot verschil tussen PHP en template taaltje in PHP. Waarom zo je eigenlijk PHP niet gebruiken? In PHP v4 kun je zelf XSLT uit breiden met functionaliteit uiit PHP of JavaScript.

Bekijk hiervoor ook eens de onderstaande artikelen:

http://mail.gnome.org/archives/xslt/2004-July/msg00045.html

http://blog4.bitflux.ch/w...XSLT_functions_with_EXSLT

http://blog.bitflux.ch/ar...hp5_function_in_xslt.html

[Rhapsody]

Dus als ik het goed begrijp is het voor mij beter om dan gewoon enkel PHP te gebruiken?

Ik wil de site modulair maken, zodat deze makkelijk uit te breiden is.
Van de zomer heb ik al veel dingen doorgelezen en uitgewerkt, maar ik wil nu toch wel eens met het coden/programmeren zelf beginnen.

[Michali]

Je kunt toch ook de logica en opmaak scheiden zonder XSLT of een template parser? Je maakt bijvoorbeeld in de ene pagina een assosiatieve array met alle benodigde data en include je een pagina waarin je deze data weer invult tussen HTML tags, op de <?=$data['waarde']?> manier. Voordeel hiervan in dat je, mocht het nodig zijn, alle kracht van php nog kunt gebruiken. Met XSLT moet je veel inleveren en moet je soms vreemde truukjes bedenken wil je tot een oplossing kunnen komen. En daarnaast is puur gebruik van php ook nog eens een stuk sneller.

[ Voor 3% gewijzigd door Michali op 09-10-2004 15:48 ]

[MisterData]

Ik gebruik zelf voor mijn CMS de nieuwe XSLT-features uit PHP5 als template-engine. Dat werkt erg relaxed: met XSLT kun je heel gemakkelijk delen van templates hergebruilken, data ophalen uit externe XML-bestanden en nog veel meer Als je kunt: gebruik XSLT Een class die ik zelf heb gemaakt om gemakkelijk met die templates om te kunnen gaan volgt:

PHP:

<?php
class pnpTemplate {
    protected $_tpl, $_module, $_type, $_xslt, $_stylesheet;
    
    static function QueryTemplate($tpln) {
        return file_exists(cmsConfig::getPathToTemplate($tpln).".xsl");
    }
    
    function __construct($module,$type='xslt') {
        if(!is_object($module)||!($module instanceof pnpComponent)) {
            $tpl_name = cmsConfig::getPathToTemplate($module);
        }
        else {
            $tpl_name = cmsConfig::getPathToTemplate(get_class($module));
        }
    
        if($type=='unknown') {
            $type = pnpConfig::defaultTemplateEngine;
        }
        $this->_type = $type;
        
        if($type=='tplphp') {
            require_once("tpl/tpl3.inc.php");
            $tpp = new TemplateParser();
            
            if($module==NULL||!$module instanceof pnpComponent) {
                throw new pnpException("Templates can only be used from PnP modules",pnpException::notSupported);
            }
            else {
                $this->_tpl = $tpp->LoadTemplate($tpl_name);
            }
        }
        elseif($type=='xslt') {
            $xsl_dom = new DomDocument();
            $xsl_dom->load(strtolower($tpl_name).".xsl");
        
            $this->_xslt = new XsltProcessor();
            $this->_xslt->registerPhpFunctions();
            if($module instanceof pnpComponent) {
                $this->_xslt->setParameter(null,"prefix",$module->prefix());
            }
            
            $this->_stylesheet = $this->_xslt->importStylesheet($xsl_dom);
        }
        elseif($type=='replace') {
            $this->_tpl = implode(file(pnpConfig::componentDirectory.$module->GetName()."/".$tpl_name));
        }
        else {
            throw new pnpException("The template engine '$type' does not exist. ",pnpException::templateEngineUndefined);
        }
        
        $this->_module = $module;
    }
    
    public static function AddVarsToDOM(&$node, $params,&$inputdom) {
        foreach($params as $k=>$v) {        
            if(is_array($v)) {
                if(is_numeric($k)) {
                    $varnode = $inputdom->createElement("element");
                }
                else {
                    $varnode = $inputdom->createElement($k);
                }
                pnpTemplate::AddVarsToDOM($varnode,$v,$inputdom);
                $node->appendChild($varnode);
            }
            elseif($v instanceof DOMDocument) {
                $varnode = $inputdom->createElement($k);
                $nm = $inputdom->importNode($v->firstChild,true);
                $varnode->appendChild($nm);     
                $node->appendChild($varnode);
            }
            elseif($v instanceof DOMNode) {
                $varnode = $inputdom->createElement(is_numeric($k)?"element":$k);
                $nm = $inputdom->importNode($v,true);
                $varnode->appendChild($nm);
                $node->appendChild($varnode);
            }
            elseif(is_bool($v)) {
                $varnode = $inputdom->createElement($k);
                $valnode = $inputdom->createTextNode($v?"yes":"no");
                $varnode->appendChild($valnode);
                $node->appendChild($varnode);
            }
            elseif(is_object($v)) {
                try {
                    if(is_numeric($k)) {
                        $varnode = $inputdom->createElement("element");
                        $attribute = $inputdom->createAttribute("index");
                        $attribute->appendChild($inputdom->createTextNode($k));
                        $varnode->appendChild($attribute);
                    }
                    else {
                        $varnode = $inputdom->createElement($k);
                    }
                    
                    pnpTemplate::AddVarsToDOM($varnode,$v,$inputdom);
                    $node->appendChild($varnode);
                }
                catch(exception $e) {
                    throw new pnpException("Foutje gecatched",pnpException::xsltFailed);
                }
            }
            else {
                if(is_numeric($k)) {
                    $varnode = $inputdom->createElement("element");
                }
                else {
                    $varnode = $inputdom->createElement($k);
                }
                
                $valnode = $inputdom->createTextNode($v);
                $varnode->appendChild($valnode);
                $node->appendChild($varnode);
            }
        }
    }
    
    function Run($params=array(), $debug=false) {
        /* Add default variables, such as username */
        $params['session'] = array("user_name"=>pnpSession::GetUserName(), "user_id"=>pnpSession::GetUserID(), "user_logged_in"=>pnpSession::IsLoggedIn(), "user_status"=>pnpSession::GetUserStatus(), "user_preferences"=>pnpSession::GetPreferences(), "user_language"=>pnpSession::getUserLanguage());
        if($this->_module instanceof pnpComponent) {
            $params['module'] = $this->_module->GetName();
        }
    
        if($this->_type=='tplphp') {
            foreach($params as $k=>$v) {
                $this->_tpl->AddVariable($k,$v);
            }
            return $this->_tpl->Run();
        }
        elseif($this->_type=='xslt') {
            $inputdom = new DomDocument();
            $root_node = $inputdom->createElement("template");
            
            pnpTemplate::AddVarsToDOM($root_node,$params,$inputdom);
            pnpTemplate::AddVarsToDOM($root_node,array("preferences"=>pnpSession::GetPreferences()),$inputdom);
            $inputdom->appendChild($root_node);
            if($debug) {
                print "<b>Input XML:</b><hr/>";
                print htmlentities($inputdom->saveXML());
            }
            
            $newdom = $this->_xslt->transformToDoc($inputdom);
            if(!is_object($newdom)) {
                throw new pnpException("XSLT Transformation failed",pnpException::xsltFailed);
            }
            
            /* in de newdom zoeken naar pnp:widget elementen enzo) */
            $items = $newdom->getElementsByTagName("widget"); 
            
            foreach($items as $k=>&$v) {
                $params = array();
                
                foreach($v->attributes as $key=>$val) {
                    $params[$key] = $val->textContent;
                }
                
                $params['text'] = $v->textContent;
                $parent = $v->parentNode;
                
                if(!isset($params['name'])) {
                    throw new pnpException("XSLT Transformation failed: a pnp:widget tag was found, but no name attribute was specified.",pnpException::xsltFailed);
                }
                $name = $params['name'];
                
                // nieuw object maken
                $obj = pnpComponentManager::Instance($name);
                $parent->replaceChild($obj->Widget($params,$newdom),$v); // gooit exception als Widget niet is geimplementeerd
            }
            
            /* In de newdom zoeken naar content-type elementen zodat we headers kunnen sturen */
            /* in de newdom zoeken naar pnp:widget elementen enzo) */
            $items = $newdom->getElementsByTagName("content-type"); 
            
            $sent = headers_sent();
            foreach($items as $k=>&$v) {
                $type = $v->textContent;
                if($sent) {
                    header("Content-type: ".trim($type)."\r\n");
                    $sent = true;
                }
                $v->parentNode->removeChild($v);
            }
            
            return $newdom->saveXML(); 

        }
        elseif($this->_type=='replace') {
            require_once("tpl/replace.inc.php");
            return pnpReplaceTemplateEngine::Run($this->_tpl,$params);
        }
        else {
            throw new pnpException("The template engine '".($this->_type)."' does not exist. ",pnpException::templateEngineUndefined);
        }
        return 0;
    }
};
?>

[Rhapsody]

maar als ik dan gebruik maak van een database (en dat is zo ) dan moet ik eerst uit de db de boel in XML formaat zetten, die daarna laten parsen door de XSLT parser... dat lijkt mij een stap extra die ik zonder XML/XSL niet hoef te maken.

[Genoil]

In het topic dat je aanhaalt heerst imo wel een beetje de XSLT-halleluja sfeer waarin ik zelf tot voor kort ook nog verkeerde. Begrijp me niet verkeerd, het is nog steeds een elegante manier om jezelf te dwingen inhoud en structuur te scheiden. Met de nadruk op structuur, een cruciaal verschil ten opzichte van opmaak, waar men in het 2001 topic nog van repte.

Inmiddels is het 2004, en zijn de meeste webdevelopers het er hopelijk wel mee eens dat XHTML niet zo heel veel (meer) met opmaak te maken heeft. CSS is inmiddels volwassen, en kan voor het overgrote deel ingezet worden om de opmaak van een document te bepalen.

XSLT is vooral sterk in het structureel manipuleren van de bron-XML naar een andere structuur. Dat is alleen echt nodig als de input structureel (sterk) verschilt van de gewenste output. Een goed voorbeeld is bijvoorbeeld een tool waarmee je grote hoeveelheden statistische gegevens (data-structuren) in een document-structuur zoals XHTML moet gieten.

Daarnaast is het ideale tool om in te zetten wanneer het belangrijk is dat er verschillende output-formaten, zoals XHTML, PDF, enz. in je applicatie ondersteund worden.

Ga je daarentegen een CMS maken waarin de inhoud sterk "document-centric" is, hetgeen bij website-CMS-en nou eenmaal vrij vaak voorkomt, dan kun je je afvragen of je XSLT nog wel nodig hebt.

Ik schrijf tegenwoordig m'n templates in plain XHTML, laadt die in de PHP5 DOM, gebruik DOMXPath om m'n "hooks" te vinden waarin eventuele dynamische content ingevoegd moet worden en gebruik de DOM methodes om die op de juiste plek erin te hangen. Serializen naar een XHTML-string en echo'en maar.

Dat is de simpele versie van m'n huidige "pagina-engine". In de ingewikkelde versie zit er na de DOM-stap toch nog wel een XSLT-stap. Deze gebruik ik eigenlijk alleen maar als "aggregator", oftewel ik gebruik XSLT alleen maar om verschillende XHTML sources te verzamelen en achter elkaar in 1 pagina te zetten (bv. pagecontent.xhtml + menu.xhtml). In feite zou ik daar ook wel DOM voor kunnen gebruiken, maar het voordeel van XSLT is dan weer dat ik het altijd nog mooi kan gebruiken voor de dingen waar XSLT echt handig voor is.

Zo ben ik nu bezig met een site die zowel een mobiele telefoon-versie als een "normale" versie moet krijgen. In de normale versie zit een pagina met een vrij uitgebreide tabel, die op de meeste mobiele telefoons totaal niet past. Op de mobiele telefoon-versie bouw ik daarom de tabel met XSLT om naar een simpele lijst met linkjes naar losse pagina's waar steeds maar 1 tabel-rij als lijst wordt weergegeven. Dat zijn de structurele verschillen waar XSLT goed van pas komt in een document-centric omgeving.

Een andere reden dat ik veel liever de PHP5 DOM gebruik dan XSLT voor het manipuleren van m'n templates, is dat XSLT als declaratieve programmeertaal weliswaar een hele leuke uitdaging oplevert bij het oplossen van probleempjes die je in een procedurele omgeving in no-time gefixed zou hebben, maar dat de complexe oplossingen met ingewikkelde recursies en template parameters, om toch maar zo goed mogelijk een procedurele situatie te imiteren eigenlijk gewoon te ranzig (en ineffcient) voor woorden zijn.

En zoals alienfruit al aanhaalt ("In PHP v4 kun je zelf XSLT uit breiden met functionaliteit uiit PHP of JavaScript.")wringen mensen zich toch weer in allerlei bochten om in XSLT toch maar weer de beschikking te krijgen over wat fatsoenlijke functionaliteit om business-logic in de XSLT-trap uit te kunnen voeren. Dat vind ik maar raar, ben je net goed bezig met het scheiden van zaken als inhoud, structuur en vast ook opmaak, gooi je je business logic in de verkeerde laag!

Samengevat: gebruik XSLT voor waar het goed in is en zie het niet als de ultieme oplossing voor al uw template-problemen.

[alienfruit]

XSLT gebruik ik vooral in mijn cms waar alles in XML wordt opgeslagen of een combinatie hiervan. Maar voor "simpelere" WCMS gebruik ik vaak gewoon PHP met <?= ?> etc. etc. Waarom een template parser maken in PHP als het zelf al een goede template parser is Maar goed, ik gebruik dus vooral SOAP, XML, XSLT, XLinks e.d. als het een CMS moet zijn die niet alleen Web georienteerd is. Voor de makkelijke uitwisseling met andere programma's zoals Indesign, Star Office.

[Rhapsody]

Bedankt voor jullie replies,

Ik denk inderdaad dat het een beetje de 'halleluja-sfeer' (zoals je het mooi verwoordde) was die mij aan het twijfelen heeft gebracht.

Van de zomer heb ik samen met enkele anderen met XSL/XML gewerkt. Op een gegeven moment liepen we toen tegen problemen aan die niet 123 op te lossen waren. Na nogal wat druk en overhaastte beslissingen van mijn projectleider zijn we er toen vanaf gestapt.

Aan een CMS wil ik (nu) nog niet beginnen, omdat ik daar simpelweg nog niet genoeg kennis voor in huis heb.
Ik weet aardig wat van OO en kan redelijk uit de voeten in PHP, en dit is de eerste keer dat ik nu echt alles van te voren aan het uitwerken ben ik op papier.

[ Voor 26% gewijzigd door Rhapsody op 09-10-2004 16:57 ]

[alienfruit]

Eigenlijk is het allemaal afhankelijk van wat het doel is van het te maken product is, ik werk nu bijv. aan een cms dat zowel advertenties, pagina's e.d. moet kunnen genereren als de online tegenhanger. Hiervoor kan het interessant zijn om XML met de XSLT combinatie te gebruiken. Omdat je met XSLT-FO ook PDFs kan gegeneren, die dan mooi kan worden gebruikt voor bij drukwerk. Enige probleem is dat nog niet weet hoe je een PDF drukklaar moet aanleveren, Dus nu laat ik het XML uitspugen (transformatie dmv. een XSLT) na een formaat dat Indesign CS snapt, dan moet de vormgever nog wel wat doen maar het scheelt tijd.

[ Voor 16% gewijzigd door alienfruit op 09-10-2004 17:01 ]

[Rhapsody]

jaja.

In de toekomst wil ik wel een CMS gaan schrijven. Zeker omdat het het plan is om toch wat te gaan doen in de webdesignwereld. Maar daarvoor wil ik mij eerst nog gaan specialiseren. Op dit moment ben ik van mening dat ik nog te weinig kennis in huis heb.
Alhoewel een CMS ook een uitdaging kan zijn natuurlijk.

Maar zoals ik het nu zie, is XML/XSL voor een CMS of een uitgebreide site een overkill. Met een mooie n lagen architectuur geschreven in PHP kun je eigenlijk hetzelfde. Pas als er sprake is van 'communicatie' tussen diverse talen, applicaties zou XML van toepassing kunnen zijn.
Klopt dat een beetje?

[alienfruit]

Ja, dat vind ik ook Liefst zou ik PHP5 willen gebruiken Maar ja hostingsbedrijven

[ Voor 21% gewijzigd door alienfruit op 09-10-2004 17:30 ]

[Rhapsody]

Ik zit ook te wachten tot PHP5 wordt ondersteund, maar goed ik heb nog ff

Heb je nog tips voor het maken van een CMS trouwens? Hoe ik dat het beste aan kan pakken in het begin bijvoorbeeld?

[Genoil]

/me al maanden php5 shared hosting heeft maar niet gepast vind reclame te maken voor de bovenburen

tips voor het maken van een CMS:
• haalbare doelen stellen, probeer geen uber-CMS te maken.
• documenteren vanaf dag 1.
• als je na een jaar overnieuw wilt beginnen omdat het een puinhoop is, doe dat dan niet. je tweede CMS is namelijk na een jaar ook weer een puinhoop.
• probeer niet alles zelf te doen maar zoek goed naar componenten die je gemakkelijk kunt integreren, zoals diverse PEAR modules.

[Rhapsody]

Dat ben ik wel gewend, heb je lang zitten werken aan iets, leer je ondertussen allemaal nettere methoden.....

Maar dan zou je dus elke keer je bestaande versie moeten aanpassen ipv overnieuw beginnen, terwijl je toch het idee hebt dat het zo'n zooitje is...... dat is wel moeilijk vind ik.

[MisterData]

Ik mag bij mijn hoster (WideXS) gewoon zelf PHP5 installeren, wordt ik alleen wel van de update-lijst afgehaald, waardoor ik dus kernel-upgrades en dergelijke vanaf dan zelf moet doen... ze hebben naar eigen zeggen nog geen plannen voor een upgrade naar PHP5...