[PHP/Ajax] In grote projecten overzicht behouden

[Verwijderd]

De vraag die ik zou willen stellen, en mogelijk de discussie die daaruit volgt, ligt op de grens van server- en clientside, maar ik vermoed dat het voornamelijk voor de programmeurs van clientside interessant is.

Waar we door talen als Java, C++ en gelukkig ook steeds meer PHP leren om alles netjes volgens de Object-georiënteerde methode in Classes te programmeren, brengt dat volgens mij wel een lastigheid met zich mee op het gebied van Ajax. Stel dat je de hiërarchie van een forum in php-classes hebt uitgewerkt. Je hebt dan bijvoorbeeld een Thread, Post en User classe, met ieder z'n getters en setters (getTitle, getContent, setEmailaddress, etc). Hierin kan je de juiste controles uitvoeren en je data-model consistent houden.

Wanneer je het oldskool zou programmeren zou iedere pagina voor je bezoeker een bijbehorende pagina op de server hebben; viewTopic.php, updateUser.php, etc. In deze serverside pagina's roep je on-the-fly de juiste getters/setters.

Stel dat je er nu voor kiest om het zoveel mogelijk via Ajax te doen. Voor al deze getters en setters moet je dan eigenlijk wrappers schijven. Bijvoorbeeld ajaxRequest.php?type=topic&request=getTitle&uid=42. Hiermee maak je een laagje boven je Topic->getTitle( 42 );, en dat klinkt als dubbel werk (iets dat voor een programmeur meestal niet aantrekkelijk klinkt).

Ik ben bekend met Xajax, waarbij je functies in php kan schrijven die je als het ware vanuit javascript aanroept. Ik vind die methode erg fijn werken, maar het is lastig een goed overzicht te houden van al je functies wanneer het gaat om bijvoorbeeld 20+ classes met getters en setters.

Je zou ook met Xajax één php-functie kunnen schrijven die de parameters afvangt en zelf de juiste klasse aanmaakt en getters/setters pakt. Je komt dan echter met het probleem dat die erg veel kennis moet hebben van je presentatie laag. Hierdoor wordt de MVC-methode weer lastiger te gebruiken.

Zijn er methodes om met dit probleem om te gaan, en welke? Of is het toch een kwestie van (veel) ajax-pagina's met gegroepeerde functies/functionaliteiten?

Daarnaast; in mijn ogen is de ideale manier dat je Ajax request alleen data oplevert (xml of json bijvoorbeeld) en dat de presentatielaag dat zelf verwerkt (een tabel van maakt), en niet dat -wat bijvoorbeeld met XajaX snel wordt gedaan- het resultaat van het request ook de opmaak etc bevat. Hoe denken jullie daarover?

[FragFrog]

Wat ik zelf veel gebruik is een aangepaste versie van de SAJAX library. Hierin heb ik functionaliteit toegevoegd om statische class members direct aan te roepen, in mijn pagehandler worden AJAX requests vervolgens direct afgehandelt voor de presentatie-laag aangeroepen wordt zodat er verder ook geen opmaak in de response zit (en er heel weinig overhead op zit).

Aan de javascript kant wordt dit dan iets als x__topic__getTitle(argument1, argument2, callback);

Verder regelt de controller ook dat alle requests gewoon centraal afgehandelt worden en een classloader zorgt ervoor dat classes ook daadwerkelijk geladen worden als ze nodig zijn. Daar zit verder nog wat security bovenop om te zorgen dat de gebruiker alleen die functies kan aanroepen op deze manier die op zijn pagina's beschikbaar zijn gesteld. Op die manier kun je redelijk transparant functies in je class beschikbaar maken door ze in de oorspronkelijke request te markeren als beschikbaar (iets als $handler -> addAjaxMethod($callback)).

Aangaande wat je terugkrijgt: JSON is in mijn opinie veruit de beste keuze aangezien het resultaat door javascript verwerkt moet worden. Opbouwen van een table bijvoorbeeld betekend wel dat je ook met JS dom elementen moet lopen aanmaken en toevoegen, maar in mijn ervaring is dat nauwelijks meer werk dan de oorspronkelijke HTML schrijven. Het voorkomt ook dat je HTML in je model gaat lopen bouwen. Als je echt met AJAX stukken HTML random op je pagina wil kunnen laden ben je feitelijk bezig iFrames na te maken, ik zie het nut daar niet zo van in

[ Voor 10% gewijzigd door FragFrog op 01-12-2010 01:18 ]

[B-Man]

FragFrog schreef op woensdag 01 december 2010 @ 01:15:
...knip...
Als je echt met AJAX stukken HTML random op je pagina wil kunnen laden ben je feitelijk bezig iFrames na te maken, ik zie het nut daar niet zo van in

Ik ben een fervent gebruiker van Apache Wicket, een java component-based framework voor het bouwen van webapps. Een van de zaken die me daarin heel sterk aanspreekt is dat AJAX transparant werkt; Simpel gezegd maakt het voor een component niet uit of deze in een pagina of los gerendered wordt. Dit maakt het mogelijk om via AJAX eenvoudig componenten te vernieuwen.

Ik vermoed dat bovenstaande ook mogelijk is met andere component-based frameworks. Het grote voordeel hiervan is dat je dus niet langer zelf een (json-) response hoeft te parsen en "renderen".

Het is niet direct een antwoord op de vraag van de TS, maar zeker het bekijken waard.

[Kalentum]

Verwijderd schreef op woensdag 01 december 2010 @ 00:52:
Ik ben bekend met Xajax, waarbij je functies in php kan schrijven die je als het ware vanuit javascript aanroept. Ik vind die methode erg fijn werken, maar het is lastig een goed overzicht te houden van al je functies wanneer het gaat om bijvoorbeeld 20+ classes met getters en setters.

Je zou ook met Xajax één php-functie kunnen schrijven die de parameters afvangt en zelf de juiste klasse aanmaakt en getters/setters pakt. Je komt dan echter met het probleem dat die erg veel kennis moet hebben van je presentatie laag. Hierdoor wordt de MVC-methode weer lastiger te gebruiken.

Dat laatste snap ik niet. Je kan prima serverside een MVC opzet handhaven. Je controller vraagt op basis van het request gegevens aan een model en het resultaat wordt dan in een view gerenderd. Of die view nu HTML moet gegeneren of JSON of XML, dat maakt niet uit. JSON is gewoon een andere presentatie van data.

Daarnaast; in mijn ogen is de ideale manier dat je Ajax request alleen data oplevert (xml of json bijvoorbeeld) en dat de presentatielaag dat zelf verwerkt (een tabel van maakt), en niet dat -wat bijvoorbeeld met XajaX snel wordt gedaan- het resultaat van het request ook de opmaak etc bevat. Hoe denken jullie daarover?

Het is netter om alleen data te genereren. Maar je moet oppassen dat je dan geen dubbel werk zit te doen. Als je bv een bepaalde tabel zowel server side genereert alsook via javascript zit op te bouwen zit je twee keer dezelfde HTML te maken, wat dubbel werk is zonder meerwaarde.

Je kan er ook voor kiezen om alle rendering door javascript te laten gebeuren. Ik heb zelf een webapplicatie in Javascript gebouwd door middel van het ExtJS framework. Aan de serverkant zit een PHP-applicatie die via MVC werkt. Deze serverside applicatie doet twee dingen: het configureren van user interface elementen (ExtJS objecten) en data. Zowel die ExtJS objecten als de data zijn JSON-gecodeerd. Het ExtJS framework leeft in de client en zorgt voor het renderen van de user interface en afhandelen van events.

[Mod_Aap]

Waarom niet je JS met een (REST/XML-RPC) webservice laten praten?

[Verwijderd]

Snot_Aap schreef op donderdag 02 december 2010 @ 10:07:
Waarom niet je JS met een (REST/XML-RPC) webservice laten praten?

Zou je daar iets meer toelichting over kunnen geven, hoe je dat dan ook praktisch organiseert?

[Gomez12]

FragFrog schreef op woensdag 01 december 2010 @ 01:15:
Als je echt met AJAX stukken HTML random op je pagina wil kunnen laden ben je feitelijk bezig iFrames na te maken, ik zie het nut daar niet zo van in

Imho is het voornamelijk een verschil in aanpak. Ik persoonlijk wil alles zoveel mogelijk in 1 pageload stouwen ( ik heb een hekel aan 1 html pagina waar ik niets zie totdat er 10 ajax-calls klaar zijn ). Oftewel ik heb zo ongeveer van alles al html-templates nodig.

Daarnaast introduceert JSON enkel maar extra complexiteit terwijl het slecht herbruikbaar is ( het enige echte gebruik wat ik ervan zie is dat er aan de serverkant extra complexiteit wordt gebouwd om JSON te verzorgen en aan de clientkant is er extra complexiteit benodigd om de JSON weer terug te zetten naar HTML. Verstuur het dan in een verkorte XML oid dat is tenminste nog redelijk herbruikbaar door andere apps )

JSON scheelt je veel bandbreedte, maar kost je redelijk wat extra beheerstijd imho.
En dat is gewoon een afweging, als het om een high-traffic component gaat als bijv de tracker op t.net / GoT kan ik me voorstellen dat de bandbreedte besparing goed opweegt tegen de beheerskosten, maar op bijv een tab-element de losse tabinhouden met JSON versturen vind ik erg twijfelachtig.

[FragFrog]

Gomez12 schreef op donderdag 02 december 2010 @ 22:25:
JSON scheelt je veel bandbreedte, maar kost je redelijk wat extra beheerstijd imho.

Dat hangt er ook weer volledig vanaf hoe en waarom je het gebruikt. Als je AJAX daadwerkelijk gebruikt als veredelde vorm van iFrames om content op een bepaalde plek volledig te herladen is JSON niet handig. Maar stel dat je bijvoorbeeld een knop wilt verbergen, een vraag uit een formulier wilt halen, een extra upload element wilt toevoegen, etc, dan is het gewoon stom om dat hele component weer opnieuw te laden en renderen. Als resources toch niet belangrijk zijn kun je dan net zo goed de hele pagina herladen.

Met AJAX kun je juist op specifieke kleine plekken op de pagina aanpassingen doen aan de hand van serverside veranderingen (ik gebruik het bijvoorbeeld in een multi-user agenda applicatie om afspraken bijna realtime bij te plaatsen zodra ze ingeplanned worden), als je hele blokken gaat herladen is het nut van asynchrone updates imo weer grotendeels weg. Gebruik het dan niet, wordt je app nog veel simpeler en beheersbaarder door

[Mod_Aap]

Verwijderd schreef op donderdag 02 december 2010 @ 21:17:
[...]
Zou je daar iets meer toelichting over kunnen geven, hoe je dat dan ook praktisch organiseert?

Even er vanuit gaan dat je begrijpt hoe je een REST/XML-RPC webservice inricht zal ik alleen ingaan op het Javascript gerelateerde. Hierbij is het simpelst om een REST webservice te gebruiken, waarbij gegevens via POST/PUT/GET/DELETE met de server uitgewisseld worden. Als return data van de server kan je of XML en/of JSON gebruiken. Het voordeel van XML is dat het in de meeste programmeer talen beter ondersteund wordt, het voordeel van JSON is minder overhead. Heb je tijd over dan zou je beide kunnen ondersteunen anders zou ik zelf XML gebruiken.

Het voordeel van een REST webservice is dat als je bijvoorbeeld form serialization ed nog gewoon kan gebruiken en dat er vrij weinig tot niets veranderd aan je manier van Javascript/Ajax scripten. Bij een XML-RPC webservice zal je eerst de data die je naar de server toe stuurt om moeten zetten naar XML.

Waarom ik deze manier gebruik: Ten eerste wordt je geforceerd om je server-sided code netjes op te zetten, op deze manier krijg je geen views die als enige doel hebben een object te JSON encoden. Ten tweede je hebt vaak meteen voor een groot gedeelte een API klaar die je kan gebruiken om andere software te koppelen met je systeem. (Mobile apps etc)