SJP: Shared Javascript and PHP
1 script die je eenmalig kan omzetten naar zowel JS en PHP.
Met dit systeem kan je een script maken waarmee je functies kan aanmaken en dynamisch HTML kan aanmaken en aJaX requests kan doen.
Er komt dan een programma (denk PHP script) die deze scripts eenmalig omzetten naar een JS versie, die zn data ophaalt met aJaX, en een PHP versie die direct werkt met een PHP functie om data op te halen.
Hier is een voorbeeld:
De SJP code:
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
<? // <<< just voor syntax highlighting NIET NODIG
function load_topic(id) {
var posts = request('posts',{//Y as X
poster:poster,//dit zijn de waardes die opgevraagd worden + eventuele functies die eroverheen moeten uitgevoerd worden.
message:bbcode(message),
time:time,
},{
topicid:id,
});
var output = '';
for(var x=0;x<posts.length;x++) {
output += '<div>' + posts[x].message + '</div>';
}
return output;
}
/* voor syntax highlighting! >>> */ ?>
function load_topic(id) {
var posts = request('posts',{//Y as X
poster:poster,//dit zijn de waardes die opgevraagd worden + eventuele functies die eroverheen moeten uitgevoerd worden.
message:bbcode(message),
time:time,
},{
topicid:id,
});
var output = '';
for(var x=0;x<posts.length;x++) {
output += '<div>' + posts[x].message + '</div>';
}
return output;
}
/* voor syntax highlighting! >>> */ ?>
En dit wordt dan omgezet naar de volgende JS:
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
<? /* <<< syntax highlighter */
function load_topic(id,oncomplete) {
ajax('ajax.php?\'posts\',{poster:poster,message:bbcode(message),time:time,},{topicid:'+id+',}',function(posts) {
var output = '';
for(var x=0;x<posts.length;x++) {
output += '<div>' + posts[x].message + '</div>';
}
oncomplete(output);
});
}
/* syntax highlighter >>> */ ?>
function load_topic(id,oncomplete) {
ajax('ajax.php?\'posts\',{poster:poster,message:bbcode(message),time:time,},{topicid:'+id+',}',function(posts) {
var output = '';
for(var x=0;x<posts.length;x++) {
output += '<div>' + posts[x].message + '</div>';
}
oncomplete(output);
});
}
/* syntax highlighter >>> */ ?>
De functie "ajax" doet een request waarbij de complete query string in de PHP functie "request" wordt gegooit die gaat controleren of de opgevraagde data opgehaald mag worden door de betreffende gebruiker.
Omdat JS aJaX asynchroon loopt moet ik dus met oncomplete werken.
De PHP versie kan gewoon "return" gebruiken, maar kan eventueel ook werken met een oncomplete functie.
En de volgende PHP code:
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
Hier wordt de functie "request" direct opgeroepen en er hoeft dus niet op gewacht te worden.
Het wordt dus een script dat een script met JS-like syntax kan porten naar een werkende JS en een werkende PHP.
Hebben jullie hier nog opmerkingen over? Goed idee? prut idee? geweldig idee?
Nog tips?
Gewijzigd op 01/01/1970 01:00:00 door Toby hinloopen
De scheiding van logica is duidelijk:
Je Model bevat je database of andere data logica
Je Controller bevat je applicatie logica
Je View bevat je lay-out logica (templates).
In veel gevallen kan je ajax requests afhandelen door een aparte view voor ajax te gebruiken (bijv. html zonder lay-out template). Je kan hier ook voor kiezen om dit in JSON te doen. In sommige gevallen zal je ook aparte logica in je controller voor ajax requests hebben.
Een typische MVC oplossing zal op dit lijken:
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
class xxController extends Controller
{
function executeTopiclist
{
// laad de topic list uit je model
$this->topiclist = Topics::get(); // zoiets, zal verschillen per implementatie
if (isset($_GET['ajax']))
{
$this->view = 'TopicLoadAjax.html';
// geen layout gebruiken
$this->layout = null;
} else {
$this->view = 'TopicLoad.html';
}
}
}
?>
{
function executeTopiclist
{
// laad de topic list uit je model
$this->topiclist = Topics::get(); // zoiets, zal verschillen per implementatie
if (isset($_GET['ajax']))
{
$this->view = 'TopicLoadAjax.html';
// geen layout gebruiken
$this->layout = null;
} else {
$this->view = 'TopicLoad.html';
}
}
}
?>
Hier kom je ook in een punt waarom jouw implementatie schort: je scheiding tussen applicatie logica en tussen layout logica (je neemt html op in je code). Maar je bent wel een goed eind in de goede richting.
Gebruik json
Het deel van php naar javascript porten is voor een groot deel al mogelijk dmv de JSON functies. Deze kunnen php array/data omzetten naar JSON (google, dit is direct te gebruiken in javascript).
Zie ook de JSON extensie voor PHP
Je kan je afvragen of het echo'en in javascript wenselijk is. Dit neemt vaak veel tijd ivm het parsen in PHP (en kan je bovendien gebruik maken van cache). Zelf ben gebruik ik vrijwel altijd pure HTML voor AJAX tenzij anders absoluut nodig.
Gebruik jQuery of Prototype of Mootools
Als je serieus javascript gebruikt is dit een must.
Scheid je programma logica en opmaak logica
In zowel javascript als php. Dit om zeer verscheidene redenen.
Gewijzigd op 01/01/1970 01:00:00 door Arend a
Maar dat staat toch los van mijn idee?
mijn idee is bedoeld om HTML te genereren met zowel PHP als JS met dezelfde functie.
Alleen het template idee gaat dan verloren. Je schrijf je UI/view dan in een JS script die ook in PHP werkt. Ook hier kan je MVC in werken: gewoon 2 files aanmaken, 1 die de data ophaalt en 1 die de data omzet in HTML. Deze files converteer je naar zowel PHP als JS en klaar.
blijft MVC alleen geen HTML template... maar in ruil heb je wel een prachtig aJaX systeem dat je maar 1x hoeft te programmeren.
JSON ken ik wel sinds kort. Is zeer handig.
Maar ik zal mijn OOP kennis nog eens verder uitbreiden. Hopelijk hoef ik niet teveel uit te breiden aan bestaande classes, want zit ongeveer 2 maanden werk in.
Gewijzigd op 01/01/1970 01:00:00 door toby hinloopen
Wat prima werkt is linkjes/ formulierposts en dergelijke met jquery *bijvoorbeeld* een AJAX request mee te geven in de onclick functie, met daarna een return false. Staat JavaScript uit, dan volgt die gewoon de URL die in de link staat.
-> Je code is valide wanneer je met Jquery de onclick attributen toevoegt.
-> Je code blijft overzichtelijk
-> Het is veel meer code als je voor elke functie (of bepaalde functies) een stuk javascript laat genereren die feitelijk hetzelfde doet, namelijk gegevens posten en de output (reactie) weer inlezen.
Dus ik zet grote ??? bij het idee wat je hebt.
Quote:
Ik ben even aan het googlen naar MVC tutorials.
Maar dat staat toch los van mijn idee?
Maar dat staat toch los van mijn idee?
Niet helemaal: het MVC model heeft namelijk door zijn scheiding een zeer eenvoudige vorm om zowel naar html als ajax te kunnen outputten.
Quote:
mijn idee is bedoeld om HTML te genereren met zowel PHP als JS met dezelfde functie.
Alleen het template idee gaat dan verloren. Je schrijf je UI/view dan in een JS script die ook in PHP werkt. Ook hier kan je MVC in werken: gewoon 2 files aanmaken, 1 die de data ophaalt en 1 die de data omzet in HTML. Deze files converteer je naar zowel PHP als JS en klaar.
Alleen het template idee gaat dan verloren. Je schrijf je UI/view dan in een JS script die ook in PHP werkt. Ook hier kan je MVC in werken: gewoon 2 files aanmaken, 1 die de data ophaalt en 1 die de data omzet in HTML. Deze files converteer je naar zowel PHP als JS en klaar.
Lijkt een mooi idee: om in een soort pseudocode iets algemeens te maken, maar het lijkt mij niet erg interessant. Met name omdat de javascript code voor ajax niet zozeer dataafhandeling en templateting zal doen, maar het toevoegen van events en afhandelen van requests. Dit heeft in php geen tegenhanger.
Ook vraag ik me nogmaals af of je je code wel in javascript moet itereren en embedden. (Ik zou rauwe html injecteren tenzij anders nodig).
In dit geval wil ik dus via aJaX zo min mogelijk data verzenden. Dit voorkomt bandbreedte. Veel bandbreedte.
Een JSON met daarin wat topicdata kost veel minder serverload en bandbreedte. De JS zet het om op basis van een stel scripts, die ook serverside draaien. Zo kan je een soort thema-script maken en die zowel clientside als serverside laten draaien.
@ Willemjan_z
Dat wil ik dus voorkomen. Ik wil alles direct in 1 taal doen en dan op beide laten werken. Zo heb je prachtige aJaX mogelijkheden en het werkt direct. Zo heb je veel aJaX, snelle pageviews (indien de computer snel genoeg is) en omdat het werkt op zowel de server als de client is het dus NIET VEREIST om via aJaX te laten lopen.
Zowel het verzenden van formdata etc wil ik allemaal via aJaX laten gaan indien de betreffende client dat kan. Indien dat niet werkt gaat het op de normale manier.
Op deze manier:
-is de code valid.
-is de website volledig te lezen met de zoekmachines
-is de website volledig bruikbaar zonder javascript
-is de website volledig bruikbaar zonder ook maar 1 page refresh, indien javascript aanstaat.
Kan eventueel zelfs een soort korte performance test doen voor de betreffende browser (of gewoon kijke welke browser het is) om te kijken of het niet teveel rekenwerk is. Indien JS uitstaat of aJaX werkt niet, dan worden de scripts niet eens ingeladen. Er wordt dan alleen maar 1 script ingeladen: het script met de eventuele kleine performance test of browsercheck en de functie om de scripts te includen NA het weergeven van de pagina.
Zo hoef je ook niet te wachten op de enorme KB's aan JS die binnenkomen.
Natuurlijk houd ik rekening met bokkige browsers die niet altijd werken zoals je verwacht dat ze werken *kuch*Internet Explorer*kuch*
Aan de hand van de reacties heb ik maar besloten het project ietsje uit te werken, kijken hoever ik kom.
Quote:
In dit geval wil ik dus via aJaX zo min mogelijk data verzenden. Dit voorkomt bandbreedte. Veel bandbreedte.
Een JSON met daarin wat topicdata kost veel minder serverload en bandbreedte.
Een JSON met daarin wat topicdata kost veel minder serverload en bandbreedte.
Serverload: dit valt voor een groot deel in je optimalisatie prima op te vangen dmv caching. Iets wat client side een stuk lastiger op te vangen is.
Bij mij gaan gebruikers en gebruikersgemak, en snelheid voor de gebruiker voor, en ik zal niet rucksichlos voor een minder ergonomische oplossing uit ppuur economische redenen kiezen. Hardware en bandbreedte is tegenwoordig zo goedkoop dat dat voor mij nooit de bottleneck mag zijn, maar misschien bevind jij je in een andere positie.
Gewijzigd op 01/01/1970 01:00:00 door Arend a
Deze gegevens moet je ook binnenhalen wanneer je met AJAX werkt, misschien niet met een kleine 3kb (en geloof mij, dat is redelijk veel!) extra aan HTML wat je op moet halen. Ik vraag me serieus af of jij hier echt veel winst mee gaat halen.
Eerst en vooral vind ik dit idee prachtig. Ik ben voor mijn stage en thesis/eindwerk ook aan de slag met een taal die op hetzelfde principe gebaseerd is. Die taal (EGL) genereert op zijn beurt JAVA, COBOL, JS of RPG code.
Zo'n taal die jij nu wil creëren heet een 4GL taal en zou potentiëel bij bedrijven kunnen aanslaan. (Die willen hun tijd namelijk niet verprutsen door alles 2 maal te coderen/scripten.)
Zoals Arend al vermelde is een MVC of een 3Tier logica wel aan te raden bij de opbouw van dit systeem, maar niet per se verplicht. Het kan je helpen en veel dingen simpeler maken enzo. (Bv. dat voorbeeld dat een request naar de server naargelang de soort JSON of gewoon de HTML pagina kan outputten.)
Quote:
Gebruik jQuery of Prototype of Mootools
Als je serieus javascript gebruikt is dit een must.
Als je serieus javascript gebruikt is dit een must.
Niet volledig mee akkoord. Als je heel erg serieus wil werken met JS, dan ga je zelf (enkel) de delen van zo'n framework maken die je nodig hebt. Zo'n framework vind ik goed om de beginselen onder de knie te krijgen. Die frameworks zijn meestal veel te ruim of log omdat ze zo universeel mogelijk zouden zijn. Als je echt wil de JS code gaan optimaliseren naar uw applicatie ga je die frameworks eruit halen en enkel de dingen gebruiken/maken die uw applicatie nodig heeft. En desnoods nog wat verder ge-optimaliseerd ook. (Ben zelf bezig met een JS based game, dus denk wel dat ik redelijk weet waar ik over spreek ivm optimalisatie) Om te beginnen is zo'n framework dus wel goed en ik kan je zeker ook een kijkje naar Dojo aanraden.
Ivm het stukje van serverload.. Als je scripts minder load en bandbreedte genereren kan dat alleen maar ten goede komen bv. als de sites plots veel drukker bezocht worden en zo. Bij grote sites kom je dan uit bij het verschil tussen een paar tientallen servers (Tweakers) of een paar duizenden servers (Hyves).
Caching is dus goed mogelijk. Enerzijds kan je JS bestanden volledig door de browser gecached worden. En anderzijds kan je de data-inhoud ook laten cachen in de locale DB van de browser. Dit is een HTML5 functionaliteit en enkele browsers (WebKit alvast, ik denk Mozilla ook) ondersteunen dit al prima.
Ik hoor graag verder je vorderingen ivm met deze 4GL taal van je ;-)
Quote:
Bij mij gaan gebruikers en gebruikersgemak, en snelheid voor de gebruiker voor, en ik zal niet rucksichlos voor een minder ergonomische oplossing uit ppuur economische redenen kiezen. Hardware en bandbreedte is tegenwoordig zo goedkoop dat dat voor mij nooit de bottleneck mag zijn, maar misschien bevind jij je in een andere positie.
Dit is ook heel gebruikersvriendelijk als je het goed opzet. Je kan prachtige dingen maken zonder page refreshes. Uiteraard maak ik dit systeem ZONDER dat gebruikersgemak achteruit gaat. Het hoofddoel alles blijft natuurlijk de gebruiker. Dit project is om je doel makkelijker te realiseren en daarbij ook nog eens serverload + bandbreedte besparen. Pagina's worden sneller geladen zonder geflits en bij het updaten van bepaald deel van de pagina blijft de rest onaangetast.
Het heeft gewoon geen nadelen. Enige nadeel is de extra javascript die de gebruiker krijgt, maar dit komt pas NA het laden van de pagina. Eerst wordt de pagina opgehaald en dan wordt gecheckt met een kleine JS file of de browser geschikt is voor de grotere JS'jes. zo ja, dan wordt de rest geladen terwijl de gebruiker zn weg zoekt op je website.
Als ik het hele project kan uitwerken zoals ik het in gedacht heb is het echt ronduit perfect. Geen nadelen, besparing in load, veel meer mogelijkheden etc.
Uiteraard blijft het altijd mogelijk om gewoon zonder dit alles te werken, zelfs als het eenmaal opgezet is. Je kan de JS versie gewoon uitzetten en openen in nieuw venster/tab etc gaat moeiteloos.
Dit hele project is puur bedoeld om te verbeteren zonder nadelen. Enige nadeel is de tijd die het kost om het project voor mij te realiseren. (zo'n script-converter is best ingewikkeld, maar heb al een werkend prototype voor de SJP -> PHP)
Persoonlijk vind ik het project gewoon te mooi om waar te zijn. En tot nu toe lijkt het geen fantasie te zijn maar nog uit te werken ook.
Ik zie echt de voordelen van zo'n taal in omdat ik nu met iets gelijkaardigs werk (generatie COBOL of JAVA) en zou als deze af is en redelijk werkt ook voor mezelf willen gebruiken.
Eventueel kan je ergens een svn/git/... opzetten zodat anderen kunnen helpen.
Eerst zul je wel moeten uitdokteren hoe je taal eruit hoort te zien. (welke syntax, datatypes, ... )
http://twitter.com/livphp
LivPHP is de codenaam van het gehele project waar SJP een deel van wordt. Het pakket bestaat uit een serie scripts om een website volledig in aJaX te laten lopen.
Om zoekmachines, oude browsers en mobieltjes bevriend te houden is het echter ook mogelijk dezelfde pagina aan te maken zonder aJaX. Sterker nog: zonder enige javascript. De gehele website KAN dus werken in aJaX, maar werkt ook prima zonder 1 byte javascript.
Dit wordt mogelijk gemaakt met het SJP project: 1 script die zowel op server als client kan draaien. SJP wordt een scripttaal gebaseerd op ECMA/javascript met dezelfde OOP mogelijkheden.
SJP scripts worden eenmalig omgezet in zowel een PHP als JS bestand.
De JS bestanden worden opgehaald door de browser met de on-demand loader. De gebruiker hoeft dus niet op 100en KB's aan javascript te wachten bij het laden van de pagina. Alle javascript bestanden, inclusief het mootols framework, wordt geladen NADAT de pagina is aangemaakt door de server en de client deze heeft omgezet in een zichtbare pagina.
Voor weergave van de pagina is er dus maar 2-3kB aan javascript nodig om die andere 100en KB's te laden.
Dit zorgt voor mooie clientside performance. Omdat de website ook nog eens via aJaX werkt hoeft de pagina niet eens meer opnieuw geladen te worden als deze eenmaal is weergegeven. De data wordt in JSON formaat opgehaald via aJaX en door SJP-based javascript bestanden omgezet in HTML en wordt direct weergegeven.
De server verstuurd zo dus minder data en hoeft het ook nog eens niet om te zetten. Het omzetten in HTML gebeurt in de browser. De serverload en bandbreedte wordt hierbij dus nog eens lager waarbij de laadtijden ook nog eens verlaagt worden.
Om functies als "openen in nieuwe tab", "openen in nieuwe venster" en "koppelingslocatie kopiëren" te behouden wordt er enkel een javascript onclick event toegevoegd in de links nadat de javascript bestanden zijn geladen. Deze javascript onclick zorgt ervoor dat de pagina geladen wordt via aJaX en blokkeert de normale actie bij het klikken op een link: het laden van de pagina. (dit wordt namelijk via aJaX gedaan). Mocht er iets fout gaan, dan wordt er via "try{}catch(){}finally{}" gezorgd dat de link alsnog gevolgt wordt door de href eigenschap van de link te plaatsen in window.location om de pagina op de normale manier te laden.
Omdat alles via aJaX gaat, wordt de vorige/volgende knop ook nutteloos. Er komt een ingebouwde functionaliteit om zelf vorige/volgende/vernieuwen knoppen in de website te bouwen. Ook komt er een url-generator om een url aan te maken zodat de bezoeker een link kan kopieren voor in een chatbericht of e-mail. Dit soort functionaliteiten kan je eventueel in een smalle balk bovenin de pagina doen. Het is niet perfect maar het verminderd de enige nadelen van aJaX-based websites.
Nu je dan een hele website in aJaX heb lopen met enorme prestaties, kan je allerlei leuke dingetjes toevoegen. Zo kan je bijv. een hyves-achtige chat inbouwen met versleepbare venstertjes. Als men dan op een link klikt kan men gewoon doorchatten.
Mogelijkheden als een filmpje uit een forumbericht slepen en zo verder kijken terwijl je andere topics gaat bekijken zijn er ook. Je website wordt hiermee geen website meer maar een complete applicatie.
Om het maken van leuke javascript applicaties wordt er ook een kleine uitbreiding gemaakt op het mootools framework waarbij het maken van meerdere layers, venstertjes met meerdere layers etc mogelijk is. Tevens kan je container divjes aanmaken met een relatieve positie vanaf de linker bovenhoek, rechter bovenhoek etc. Een compleet javascript framework voor het maken van web 2.0 applicaties over je bestaande website dus.
Bij al deze mooie functies en mogelijkheden komt een enorme documentatie met allemaal mooie voorbeelden. Deze documentatie wordt eerst geschreven in nederlands en iedereen is vrij deze te vertalen.
Tot slot wordt dit alles open source en gratis, ook op commercieel niveau.
Volg de voortang van dit mooie project op mijn recent aangemaakte twitter:
http://twitter.com/livphp
Voor vragen, suggesties, opmerkingen etc kan je terecht op
tobyhinloopen_2 [atje] hotmail.com (msn/e-mail)
Gewijzigd op 01/01/1970 01:00:00 door toby hinloopen
