[XML] Pagina-componenten/indeling verwerken

[r0bert]

Ziet onderaan :)

Ik denk dat de code voor zich spreekt, maar toch eerst nog maar even een toelichting. Ik ben bezig met een website die bestaat uit verschillende componenten (zeg maar fora, gebruikers, nieuws). Deze wil ik allemaal in XML vorm outputten en heb daar ook al een groot deel van klaar.

Nu loop ik echter tegen een "probleem", misschien beter gezegd een moeilijkheid, bij het creeeren van de bovenste laag. Ik wou dit op deze manier opbouwen:

XML:

<?xml version="1.0"?>
<page>
    <componentset name="forasamenvatting">
        <component module="forum/discussie" query="messages/message[userid &lt; 100]">
            <variable name="iLimit">15</variable>
            <variable name="sSort">DESC</variable>
        </component>
        <component module="forum/nieuws" query="topics/topic[position() &lt; 5]" />
    </componentset>
    <component module="users/nieuw" query="users/user[position() &lt; 10]" />
</page>

zie ook hier

Nu vraag ik me echter af hoe ik dit het beste aan kan gaan pakken. De componenten zijn dus afkomstig van zowel (gegenereerde) statische XML bestanden als dynamisch XML bestanden die dmv PHP adhv een request worden opgesteld.

Ik ben bang dat ik niet onder het gebruik van PHP in de index uit komt. Het liefst zou ik natuurlijk door middel van een transformatie alles invoegen, maar zou niet weten hoe. Enige oplossing die ik kon bedenken, was door middel van PHP in de index, de indeling inlezen (DOMXML). Vervolgens dan met PHP de componenten inladen en query-en en invoegen.

Nadeel is dat bij mijn weten eerst de hele xml-files ingelezen moeten worden, voordat ik mijn selectie kan maken (bijv. eerste 10 records uit de XML file), misschien dat hier ook een oplossing voor is?

Zijn er mensen die ervaring hebben met deze manier van werken? Zowel directe hulp als linkjes zijn heel erg welkom!

[ Voor 26% gewijzigd door r0bert op 10-12-2005 11:42 ]

[LvdO]

Robert, wat is precies je vraag?

Zoek je een formaat voor je sitemap? Een architectuur voor een compleet XML gebaseerde website? Of een manier om middels XML een pagina te genereren die uit meerdere andere componenten bestaat?

[r0bert]

Een combinatie voor de laatste 2.

Het is dus zeker geen sitemap.

code:

XML Page Description
  -> PHP leest het uit
     -> voegt de componenten in (zijn xml bestanden)
         -> samen vormt het één xml bestand (met de data)
            -> serverside transformatie dmv XSL
                -> presentatie in XHTML formaat etc..

Dat is de manier die ik ietswat uit had gelegd (dmv PHP) die ik voor ogen had. Maar ik zou het liefst die tussenstap van PHP eruit laten, maar ben bang dat dat niet mogelijk is. Dus ik ben benieuwd hoe ik dat nog meer makkelijk aan kan pakken.

Trouwens die die beschrijvende xml file met componenten, kun je ook zien als uitgebreide (data)frames, zoals we frames kenden in HTML om pagina bij elkaar te voegen tot 1 pagina.

[r0bert]

Er moet toch wel iemand zijn die dit concept wel eens gebruikt heeft, op zijn minst geprobeerd te gebruiken? Lijkt mij ideaal. Als die component-selectie werkt zou je het zelfs kunnen gebruiken als XPointer simulatie.

Tussenstap mag van mij ook in Java/JSP, maar daar ben ik niet zo bekend mee. Liefst zou ik die tussenstap van PHP nog oplossen met XSL, maar dat is denk ik helaas niet mogelijk.

Iemand die me uit de brand kan helpen? Gaat me dus voornamelijk om die 2e stap.

[r0bert]

Weinig response tot nu toe, daarom heb ik het even beetje uitgewerkt in een kleine schematische tekening:

De stap waar het mij om gaat is het rode stuk PHP. Hiervoor ben ik op zoek naar vooral snellere en effectievere alternatieven dan DOMXML/SimpleXML. Danwel in PHP danwel in Java of soortgelijke taal.

[ Voor 3% gewijzigd door r0bert op 29-11-2005 17:01 ]

[Verwijderd]

Het lijkt wel alsof iedereen tegenwoordig bezig is met het schrijven van soortgelijke systemen. Eindelijk begint PHP een beetje volwassen te worden en de applicaties gaan ook echt beter in elkaar zitten.

Zelf ben ik hier ook al eens mee bezig geweest, en moet toegeven dat het soms echt wel moeilijk kan zijn omdat er vaak 1001 manieren zijn om het gewenste resultaat te berijken.

Misschien heb je iets aan deze link: http://www.xisc.com/, een framework in PHP5 geschreven welke ook veel gebruik maakt van xml files, o.a. voor het definieeren van de componenten en voor het 'configureren' van de applicatie.

[WouZz]

Hey r0bert.

Ik denk dat het geen probleem is om deze applicatie in PHP uit te werken. Uiteindelijk zal je 'het rode stuk' als controller moeten opzetten. Oftewel, aan de hand van de Page Description, permissies etc bepaal je hier welke gegevens je ophaalt en welke XSLT stylesheet je hier overheen gooit. Wat je nodig hebt is de DomDocument processor om je XML brongegevens in te lezen en naar XHTML te transformeren. Heb je al naar de de XSLT transformatie methodes in PHP 5 gekeken? Lijkt me vrij makkelijk. Als je van PHP 4 afhankelijk bent moet je helaas wel over de juiste extensies beschikken en is het misschien wat lastiger.

Mocht je over Java/JSP hosting beschikken dan zou ik voor JSP 2.0 gaan. Met de JSTL XML taglib is het helemaal een eitje.

[r0bert]

Verwijderd schreef op dinsdag 29 november 2005 @ 18:11:
Het lijkt wel alsof iedereen tegenwoordig bezig is met het schrijven van soortgelijke systemen. Eindelijk begint PHP een beetje volwassen te worden en de applicaties gaan ook echt beter in elkaar zitten.

Zelf ben ik hier ook al eens mee bezig geweest, en moet toegeven dat het soms echt wel moeilijk kan zijn omdat er vaak 1001 manieren zijn om het gewenste resultaat te berijken.

Dat iedereen wil ik me niet direct bij aansluiten, maar ik ben het er mee eens dat het lange tijd nogal rommelig is binnen PHP, zeker weten. Dat is denk ik ook te danken aan de populariteit en dat PHP vrij laagdrempelig is om mee te beginnen.

Veel mensen die een beetje (persoonlijke?) website wil maken, willen daar al gauw een gastenboek oid. in. Genoeg tutorials in Google, PHP ondersteuning is vrijwel standaard, dus aan de slag. Vinden het leuk, gaan er mee door, beetje schrijven als hobby.

Maar dan heb je dus wel een groep, die net kennis maakt met programmeren en die misschien ook wel nooit daadwerkelijk verder groeit hierin.

En ik moet zeggen dat de mogelijkheden en opzet van PHP5 ook duidelijk vooruitstrevend vind. En vind dat een goed streven, wat je zegt, om er een iets meer "volwassen imago" aan te geven.

Misschien heb je iets aan deze link: http://www.xisc.com/, een framework in PHP5 geschreven welke ook veel gebruik maakt van xml files, o.a. voor het definieeren van de componenten en voor het 'configureren' van de applicatie.

Is inderdaad beetje het idee wat ik ook graag wil gaan realiseren. Echter een paar verschillen. Ze maken hier gebruik van HTML templates waar ze de data invoegen. Daar wil ik graag gebruik gaan maken van XSL-templates die de daadwerkelijke XML datastream gaan transformeren voor het opgegven doel.

Doordat de modules allemaal een vastgelegde vorm van XML data leveren, wil ik het ook mogelijk maken om door middel van XQuery slechts delen van modules te kiezen, en niet alleen hele modules. Dus stel je hebt een forum, een nieuwsrubriek en een statestieken pagina. Dan wil je van forum de 10 nieuwste topics, 5 laatste nieuwsitems en de 15 laatste bezoekers op je pagina. Die data vraag je aan door middel van de Page Description zoals ik het maar even noem. De data wordt door in dit voorbeeld de PHPmodule samengesteld en geparsed naar de opgegeven XSL stylesheet.

Mooi gescheiden stappen en naar mijn idee zeker dynamisch! Ik zal eens kijken welke ideeën ik van Prado mee kan nemen!

WouZz schreef op dinsdag 29 november 2005 @ 18:28:
.. wat je nodig hebt is de DomDocument processor om je XML brongegevens in te lezen en naar XHTML te transformeren. Heb je al naar de de XSLT transformatie methodes in PHP 5 gekeken? ...

Dat is inderdaad zoals ik mijn website nu in principe opbouwde. Modules -> XML -> XSL. Echter was dat mij nog iets te "statisch". Ik wil graag modules gebruiken en dan alleen de specifieke details die ik nodig heb. Die wil ik op verschillende manieren kunnen transformeren etc..

En één van de moeilijkere stappen waar ik tegen aan loop, zoals ik al even had genoemd, is dat wanneer ik bijvoorbeeld 15 elementen wil selecteren uit een verzameling van 500 elementen, ik eerst alle 500 in moet lezen, dan de XQuery er overheen. Selecteer er 15 en de andere 485 heb ik eigenlijk voor niets ingeladen, zonde van de moeite.

Voor de rest heb ik hierboven grotendeels mijn punten ook al toegelicht. Ik ga in ieder weer eens even aan de slag!

e: Oh.. en dat JSP gedeelte ga ik nog even doornemen. Heb pas 2 dagen mijn boek Java/JSP dus is misschien nog wel even een kluif voor mij

[ Voor 25% gewijzigd door r0bert op 29-11-2005 23:49 ]

[r0bert]

Ok, ben nog niet zoveel verder inmiddels. Wou eigenlijk toch een soort van component-framework maken.

PHP:

class cPage{    
    public function __contruct()
    {}
    
    public function __destruct()
    {}
    
    public function _showMessage()
    {   echo 'hallo';   }
    
    public function _getXML()
    {}
};

class cFora entends cPage
{
    public function __contruct()
    {}
    
    public function __destruct()
    {}
    
    public function _doGek()
    {   echo 'hoi';       }

    public function _getPartialXML()
    {}
}

Bedoeling is nu zeg maar dat er zo'n description document in gaat (DomDocument vorm? als argument voor het constructen van cPage), en dat die vervolgens de goede componenten aanroept. Dan met _getXML wil ik alle xml-data ophalen.

Maar ik kom al niet verder bij de eerste stap. Hoe kan ik nou netjes en toch makkelijk (liefst dat ik niet handmatig aan hoef te passen), het script laten weten welke class er bij welke module hoort. En nog lastiger, hoe roep ik dat aan (de classname?) ?

[ Voor 15% gewijzigd door r0bert op 10-12-2005 12:30 ]

[r0bert]

PHP:

class cPage
{
    public $modules = Array();
    
    public function __construct()
    {
    }
    
    public function _addModule(&$oModule)
    {
        $this->modules[]    = $oModule;
        
        return $oModule;
    }
};

$oPage = new cPage();

/* include */
class cFora
{
    public $iId;
    
    public function cFora($sId)
    {
        $this->iId = $sId;
    }
}

$oMod = 
    $oPage->_addModule(
        new cFora('gek')
    );

Dat is hoe ik het zou kunnen bedenken, maar niet echt mooi denk ik heh?

[chris]

Lees eens wat goede boeken over object-georienteerd programmeren, en als je dat helemaal door hebt, lees eens wat boeken over Design Patterns. Volgens mij heb je daar best veel aan, het geeft je in ieder geval wel handvatten, probeer het dan nog eens. Dit bedoel ik niet om je te ontmoedigen, maar ik denk serieus dat je er veel ideeën van kunt gebruiken. In dit geval zou je misschien wel wat kunnen met een Factory ofzo?

En misschien dat het handig is voor jezelf (maar ook zeker voor ons) als je een UML-diagram of iets dergelijks maakt van wat je nou precies wil .

offtopic:
Volgens is het enkelvoud van fora gewoon forum trouwens .

[r0bert]

Okey, ik zal er eens naar kijken, genoeg te doen komende tijd.. Maar waar het mij nu eigenlijk nog het meest om gaat is.

Ik lees het XML bestand in, daar zet ik iets in als module="forum/nieuws" .. dan heb ik daar natuurlijk ook een class voor. Het probleem zit me echter in de AANROEP ervan.. hoe doe ik dat? Kan moeilijk new forum/nieuws() gaan doen. Die stap is dus het probleem

Hoe krijg ik de tekst uit het attribuut in de xml, vertaald naar het aanroepen van de bijbehorende functie.


edit:
oh en mijn bedoeling was dus om zoiets te vermijden:

PHP:

$modules = implode($module, '/');

$moduleLoad = new $modules[0]( new $modules[1]() );

e2:
mijn xml zolang webserver leeft: http://62.131.154.4/desc.xml
mijn php zolang webserver leeft http://62.131.154.4/class.php
mijn source van php: http://62.131.154.4/class.txt

[ Voor 33% gewijzigd door r0bert op 11-12-2005 18:52 ]

[r0bert]

Iemand een idee hoe het netter kan? zie vorige post

[Verwijderd]

r0bert schreef op maandag 12 december 2005 @ 17:21:
Iemand een idee hoe het netter kan? zie vorige post

Ja ik heb het idee dat je het graag doet om de technieken en dat is zeker interessant om naar te kijken. Daarin wil ik je absoluut niet ontmoedigen.

Qua design is het feitelijk vrij nutteloos; Je maakt een hoop onnodige stappen en je een raakt flexibiliteit kwijt. (en dan natuurlijk alle inherrente nadelen zoals bijvoorbeeld extra server load)

Je kunt beter je geselecteerde model direct door een willekeurige scripttaal omzetten naar het gewenste eind resultaat. En gewoon dat hele xml/xslt vergeten want het voegt helemaal niets toe aan functionaliteit of design.

[ Voor 8% gewijzigd door Verwijderd op 12-12-2005 20:30 ]

[r0bert]

Dat ben ik niet met je eens. Door de XML creeer ik mijn datalaag, deze worden aangemaakt op grond van de classes/modules/componenenten. Door deze onderdelen samen te voegen heb je een compleet datapakket van de benodigde informatie. Vervolgens kun je er door middel van de query, specifieke informatie uit halen. Vervolgens zal de opmaak van deze informatie niet overal hetzelfde zijn, dus daar gebruik ik een XSL template voor. Dat is een zeer logisch opeenvolging van stappen toch?

In de andere informatie, zou ik iedere pagina apart op moeten stellen. De dataaanvraag apart opstellen. Vervolgens alles wat binnenkomt direct naar de opmaak verwerken. Zo krijg je een wirwar van processen en informatiestromen.

Wat ik in bovenstaande doe, is de informatie clusteren. Zo kun je gestructureerd de stromen binnen de perken houden en wanneer je dat goed uitwerkt naar mijn idee juist de load verkleinen. Je kunt periodiek zo'n databestand aanmaken en voor verschillende transformaties (lees gebruikers) beschikbaar stellen, zonder dat de informatie steeds weer verzameld moet worden.

[Verwijderd]

Jij wilt bijvoorbeeld html als resultaat hebben. Zodoende kun je ook direct (periodiek) een html naar buiten schrijven. Die html kun je op het zelfde moment verversen als dat je nu met de xml van plan was. Je hebt in dit geval de 'dure' xsl transformatie weggenomen en je flexibiliteit behouden. Al met al rechtvaardigt geen van je argumenten een tussenstap met xml/xsl.

[ Voor 3% gewijzigd door Verwijderd op 13-12-2005 13:24 ]

[r0bert]

Maar als ik direct de HTML pagina's zou outputten, staat dat averechts op je verlies van flexibiliteit. Juist doordat ik de data later transformeer, kan de gebruiker het na eigen keuze orderen.

- Sorteren op bepaalde voorkeur (in een static html zouden dat allemaal bestanden worden
- Filteren van de gewenste informatie (welke kolommen wel, welke niet?)
- Onderdelen wel niet weergeven (as in GoT foraoverzicht)

Ik ben met je eens dat uniforme transformatie aan de clientside voordelen kan hebben, als minder serverload. Anderzijds publiceer je nu alleen maar de gevraagde informatie, ipv alles naar de client.

Ik denk dat het er uiteindelijk op uit zal draaien wat je voorkeur is. Data en opmaak gescheiden houden? Of je scripting in de opmaak verweven? Ik zie in de eerste methode meer voordelen, maar ik kan me best voorstellen dat voor sommige doeleinden je de 2e misschien makkelijker vindt werken.

e: om een vergelijking te trekken vind ik moeilijk te bedenken, maar vergelijk het met een krant.

Je kunt iemand een artikel van de start tot het eind laten maken. Kan prima, indien diegene daartoe capabel is. Echter kun je het ook opsplitsen. De een gaat op onderzoek uit en haalt de informatie op. De volgende stap is dat iemand deze informatie in een mooi verhaaltje zet. Vervolgens wordt de informatie gepubliceerd/opgemaakt.. de krant, televisie (docu) etc.

1e manier heb je weinig mensen nodig, iemand verzorgt alles. Echter diegene is daar druk mee en je slaat de stap van een mooi verhaaltje maken en informatie verzamelen voeg je eigenlijk samen. Voordeel is dat iemand deze hele weg specifiek kan zijn in wat er moet gebeuren volgens diegene.

2e manier, kost je meer mensen (per publicatie). Maar per onderdeel heeft diegene wel meer tijd en meer specificatie. Je verdeeld de stappen in stukken. En ieder stuk heeft zijn eigen efficiente proces.

Niet helemaal overeenstemmend, maar volgens mij wel tekenend voor het idee erachter.

[ Voor 38% gewijzigd door r0bert op 13-12-2005 13:39 ]

[Verwijderd]

Nee. Want ook ik houd heel duidelijk data gescheiden van opmaak. Alleen jij hebt nu feitelijk twee presentatie lagen:

persistentie laag
domain model
businesslogic
controllers
view (xml) -> view is dus tevens weer data laag (eventueel periodiek)
xsl -> niet sessie afhankelijke conversie


Wat ik dus suggereer is:

persistentie laag
domain model
businesslogic
controllers
view (php/asp/jsp). (eventueel periodiek)

Zodoende heb je meer flexabiliteit, en een onnodige stap weggenomen...

[r0bert]

Inderdaad, jij neemt de xml en php laag in één. Je laat de benodigde data opvissen en plaatsen op de plekken waar je deze gebruiken wilt. Vervolgens zul je of voor iedere eis van de gebruiker dit opnieuw moeten inladen. Of je zult de gebruiker moeten beperken. Of je zult voor elke mogelijkheid een apart periodiek bestand maken.

Wat jij dus inderdaad doet is de XML-stap (view zoals jij het noemt) over slaat, welke ik juist van grote toevoeging vind. Het maken van een XML-databestandje zal toch werkelijk niet zoveel van mijn systeem eisen in de omgeving waar ik nu in werk.

En de transformatie gebeurd anders in de stap van PHP/ASP/JSP, dus dat is ook geen extra load, eerder een specificering waardoor je dit efficienter kan laten verlopen.

Ik neem aan dat je bekend mee bent, met templates en wat hier de voordelen van zijn. Je kunt alles zoals je zelf wilt, rangschikken, zonder dat je daarmee met data hoeft te zitten knoeien. Je kunt de structuur aanpassen zoals je zelf wilt en de data valt vanzelf op zijn plaats, zonder dat je je druk hoeft te maken over de datainvoer zelf.

Voor manier 2 zul je de view (php/asp/jsp) aan moeten passen. Voor de bovenste manier zul je je templates = XSL aan moeten passen. Dan duik ik werkelijk liever in de XSL-template, dan in de mengeling van data en opmaak/structuur.

Je hamert en nu heel erg op dat je die 'onnodige' stap weg wilt nemen. Maar volgens mij is die stap juist een toevoeging. Een tussenstap die zeer gewenst is. Je zult daar energie in het transformeren moeten steken, maar dit lijkt me het meer dan waard en ook vrij te komen uit het besparen van de PHP stap.

Ik heb het idee dat jij vind dat de stap te zwaar is en het project versloomt. Ik zie het echter positief als een soort stap die de data alvast klaar legt voor de gebruiker, die er zelf vervolgens zijn ding mee kan doen. Dat is bij mijn weten ook het voordeel van XML. Je biedt het op een uniforme manier aan (schema's etc.), waarmee in principe elk systeem aan de gang kan en de data kan verwerken. Bij de 2e manier mis ik die stap en zul voor de informatie afhankelijk zijn van een voorgaande stap.

Kun jij mij vertellen waarom die tussenstap nie wenselijk is (ofwel "onnodig")?

e: oei, sorry voor de lap

[Verwijderd]

Ik krijg het gevoel dat je het idee hebt dat ik bijvoorbeeld ook mijn data ophaal in mijn asp/php/jsp pagina, maar dat kan ik natuurlijk mis hebben. In ieder geval is mijn bedoeling dat de asp/php/jsp pagina net als jou xsl een template is. Alleen zal een asp/php/jsp pagina kleiner in omvang zijn en vele malen sneller verwerkt zijn.