AJAX oproepen vanuit AJAX?

[Verwijderd]

Beste mensen,

Ik heb drie pagina's:
Pagina A (layout/hoofdpagina)
Pagina B (layout voor toolbox-layer)
Pagina C (roept het weer op middels xml)

Op Pagina vul ik een vierkantige DIV met de inhoud van Pagina B middels een AjAX HTML Request (om precies te zijn middels de AjaxRequest Library van www.ajaxtoolbox.com).*

Dit gaat prima zolang pagina B statisch is. Echter, Pagina B heb ik zo geprogrammeerd dat deze middels dezelfde AjAX procedure de inhoud van Pagina C oproept.. Echter dat werkt niet bij mij, wat ik ook probeer... Is AjAX in een door AjAX gegenereede pagina onmogelijk ?????

Of doe ik iets verkeerd ?

EDIT: www.ajaxtoolbox.com link was incorrect...Nu gecorrigeerd.

[ Voor 5% gewijzigd door Verwijderd op 15-08-2006 11:36 ]

[Janoz]

Voor zover ik kan zien zijn er een paar mogelijke problemen:
1. Je leest de xml data van paginaB in en voegt deze toe aan de domtree binnen de div. In dat geval wordt de pagina alleen in de tree gezet en worden de scripts hierin niet geevalueerd. Javascript wordt in dat geval dus niet uitgevoerd.

2. Je voert meerdere ajax requests uit zonder rekening te houden met synchronizatie issues. Je tweede request roep je al aan terwijl de eerste nog bezig is. waardoor het eerste request uiteindelijk de handler van het tweede request gebruikt.

Afgaande van je beschrijving vermoed ik echter dat het gewoon om puntje 1 gaat. Waarom laad je de content eigenlijk in via AJAX? In principe zou een IFrame toch ook goed zijn?

[RM-rf]

ik vermoed inderdaad dat als je binnen een gegenereerde pagina weer scriptblocken wilt plaatsen die geparsed en uitgevoerd worden, het niet op de standaard methode via innerHTML gaat....

Waarschijnlijk moet je de opzet van je code veranderen

[marko77]

Ik heb dit voorheen ook wel eens geprobeerd en het is mij ook niet gelukt om via een ajax request opnieuw wat javascript te genereren.

Is dit überhaupt wel mogelijk ? Of is de methode van janoz (wat niet altijd wenselijk is omdat er idd sync problemen bij komen kijken) de enige manier?

[crisp]

hier heb ik een ranzige oplossing voor dat probleem omschreven

Overigens zou ik Ajax beperken tot data-overdracht. Arbitraire javascript-objecten kan je mooi verpakken in JSON.

[ Voor 30% gewijzigd door crisp op 15-08-2006 09:48 ]

[Verwijderd]

Janoz schreef op dinsdag 15 augustus 2006 @ 09:39:
Voor zover ik kan zien zijn er een paar mogelijke problemen:
1. Je leest de xml data van paginaB in en voegt deze toe aan de domtree binnen de div. In dat geval wordt de pagina alleen in de tree gezet en worden de scripts hierin niet geevalueerd. Javascript wordt in dat geval dus niet uitgevoerd.

2. Je voert meerdere ajax requests uit zonder rekening te houden met synchronizatie issues. Je tweede request roep je al aan terwijl de eerste nog bezig is. waardoor het eerste request uiteindelijk de handler van het tweede request gebruikt.

Afgaande van je beschrijving vermoed ik echter dat het gewoon om puntje 1 gaat. Waarom laad je de content eigenlijk in via AJAX? In principe zou een IFrame toch ook goed zijn?

Het is inderdaad puntje 1, en je hebt inderdaad gelijk, ik heb de methode waarmee pagina B wordt opgeroepen vervangen door IFRAMEs.. Dat werkt ook prima ! Hier hoefde ik inderdaad helemaal geen AJAX te gebruiken. Ik heb echter al zo lang niet meer met IFRAMEs gewerkt - de laatste keer is een aantal jaren geleden en toen was dit element nog niet helemaal cross-browser compatible ..
Maar nu werkt het prima !!!!

Thnx allemaal !

[Anders]

marko77 schreef op dinsdag 15 augustus 2006 @ 09:42:
Ik heb dit voorheen ook wel eens geprobeerd en het is mij ook niet gelukt om via een ajax request opnieuw wat javascript te genereren.

Is dit überhaupt wel mogelijk ?

Ja, maar of het via de genoemde AjaxRequest library lukt weet ik niet. Ik gebruik zelf in een huidig project Scriptacolous, waarbij je met een eenvoudige evalScripts-parameter javascript kan laten uitvoeren in je Ajax-pagina's. Ik maak zo moeiteloos gebruik van viervoudig geneste Ajax-grappen.

Voorbeeldcode:

code:

<a href="#" 
  onclick="new Ajax.Updater(
    'AB_SubFrame', 
    '/ajax_speedmenu_dossiers.php', 
    {evalScripts:true}
  ); return false">Dossiers</a>

/edit - handig, zo'n topic. Ik zie net dat vandaag een nieuwe versie van de Scriptaculous-library is uitgebracht. Had ik anders nooit gezien

[marko77]

He, dat is grappig, scriptaculous gebruik ik ook

De evalscripts functie had ik nog niet gezien, maar de documentatie is nu ook niet écht je van hét

[Yo-han]

Anders schreef op woensdag 16 augustus 2006 @ 04:15:
[...]


Ja, maar of het via de genoemde AjaxRequest library lukt weet ik niet. Ik gebruik zelf in een huidig project Scriptacolous, waarbij je met een eenvoudige evalScripts-parameter javascript kan laten uitvoeren in je Ajax-pagina's. Ik maak zo moeiteloos gebruik van viervoudig geneste Ajax-grappen.

Voorbeeldcode:

code:

<a href="#" 
  onclick="new Ajax.Updater(
    'AB_SubFrame', 
    '/ajax_speedmenu_dossiers.php', 
    {evalScripts:true}
  ); return false">Dossiers</a>

/edit - handig, zo'n topic. Ik zie net dat vandaag een nieuwe versie van de Scriptaculous-library is uitgebracht. Had ik anders nooit gezien

en de de Scriptaculous-library gebruikt voor die Ajax.Updater funcionaliteit weer prototype . Prototype heeft wel meer van die leuke functies die het scripten in Javascript een stuk versnellen ziet hier.

marko77 schreef op woensdag 16 augustus 2006 @ 11:51:
He, dat is grappig, scriptaculous gebruik ik ook

De evalscripts functie had ik nog niet gezien, maar de documentatie is nu ook niet écht je van hét

Ook hiervoor kan je beter de documentatie van Prototype doorkijken. Wordt het een stuk beter en duidelijker uitgelegd.

[ Voor 15% gewijzigd door Yo-han op 16-08-2006 11:54 . Reden: toevoeging ]

[crisp]

dayoman schreef op woensdag 16 augustus 2006 @ 11:53:
[...]
Prototype heeft wel meer van die leuke functies die het scripten in Javascript een stuk versnellen

Totdat je tegen de bugs aanloopt

[marko77]

Als er geen bugs zouden zijn dan hebben we niets meer te doen als devvers

[Yo-han]

crisp schreef op woensdag 16 augustus 2006 @ 12:53:
[...]
Totdat je tegen de bugs aanloopt

Zijn er libs zonder bugs? Zo ja, vertel.... ik ben geintereseerd!

En ondanks eventuele bugs, prototype is een bestand van 48 kB. Scriptaculous is bij elkaar genomen ruim 150 kB. Bij een goed aantal bezoekers gaat dit toch in de kijker spelen.

[crisp]

dayoman schreef op woensdag 16 augustus 2006 @ 14:27:
[...]


Zijn er libs zonder bugs? Zo ja, vertel.... ik ben geintereseerd!

En ondanks eventuele bugs, prototype is een bestand van 48 kB. Scriptaculous is bij elkaar genomen ruim 150 kB. Bij een goed aantal bezoekers gaat dit toch in de kijker spelen.

Nee, er zijn geen libs zonder bugs, beperkingen en/of tekortkomingen
Punt is dat door technologie te gaan abstraheren je potentiele problemen verbergt. De mensen die ermee gaan werken hebben immers vaak de ballen verstand van javascript, en als ze dan tegen zo'n probleem aanlopen dan kunnen ze het zelf niet fixen.

Prototype is wel 1 van de betere libs maar is ook zeker niet perfect. Ik zal het zelf nooit gebruiken en ik zou mensen die nog weinig verstand hebben van javascript eerder aanraden javascript te gaan leren dan gebruik te maken van een library gemaakt door mensen die vinden dat javascript op Ruby moet lijken

[Anders]

crisp schreef op woensdag 16 augustus 2006 @ 15:25:
Nee, er zijn geen libs zonder bugs, beperkingen en/of tekortkomingen
Punt is dat door technologie te gaan abstraheren je potentiele problemen verbergt. De mensen die ermee gaan werken hebben immers vaak de ballen verstand van javascript, en als ze dan tegen zo'n probleem aanlopen dan kunnen ze het zelf niet fixen.

Dit vind ik een non-argument. Op die manier kun je elk CMS wel diskwalificeren (als je niet weet hoe HTML in elkaar zit...), elke front-ends (phpMyAdmin en consorten) en zo ongeveer elk product ter wereld for that matter. Een keukenmachine kopen? Niet aan beginnen: als je niet weet hoe-ie in elkaar steekt kun je 'm zelf niet fixen. Gebruik liever een aardappelschilmesje.

[Yo-han]

crisp schreef op woensdag 16 augustus 2006 @ 15:25:
[...]

[...]

Prototype is wel 1 van de betere libs maar is ook zeker niet perfect. Ik zal het zelf nooit gebruiken en ik zou mensen die nog weinig verstand hebben van javascript eerder aanraden javascript te gaan leren dan gebruik te maken van een library gemaakt door mensen die vinden dat javascript op Ruby moet lijken

Waarom zou je het nooit gebruiken? Je hebt je eigen herbruikbare code? of zijn er libs die minder op ruby lijken

Anders schreef op woensdag 16 augustus 2006 @ 15:42:
[...]

Dit vind ik een non-argument. Op die manier kun je elk CMS wel diskwalificeren (als je niet weet hoe HTML in elkaar zit...), elke front-ends (phpMyAdmin en consorten) en zo ongeveer elk product ter wereld for that matter. Een keukenmachine kopen? Niet aan beginnen: als je niet weet hoe-ie in elkaar steekt kun je 'm zelf niet fixen. Gebruik liever een aardappelschilmesje.

Ben het gedeeltelijk met je eens, maar nu gooi je ook iets teveel een grote hoop.

Volgens mij zit er namelijk wel degelijk een groot verschil tussen een CMS, Front-end/libs en keukenaparatuur. Een cms is voor mensen die geen technische opleiding hebben genoten maar wel een website moeten onderhouden. Dit wordt door technici gebouwd en onderhouden, niet door de gebruiker.
Bij een PHPMyAdmin of een Prototype lib is de gebruiker ook de techneut. Daarbij is het dus handig dat hij vakkennis heeft en niet hier en daar wat functies achter elkaar zet of een tabel maakt met tig kolommen om daar vervolgens een heel cms mee te maken (zie prachtige datamodeleer voorbeelden dagelijks in het GoT prog forum.)
Weer anders is keukenapparatuur. Hierbij is de gebruiker ook de 'techneut' maar dit is puur een form van luxe. Er is geen diepgaande kennis voor nodig om een schilmes of blender te hanteren in tegenstelling tot het pragmatisch en succesvol programmeren of scripten.

[Wolfboy]

dayoman schreef op woensdag 16 augustus 2006 @ 15:56:
[...]


Waarom zou je het nooit gebruiken? Je hebt je eigen herbruikbare code? of zijn er libs die minder op ruby lijken

Ik vermoed dat Crisp z'n eigen herbruikbare code wel heeft, persoonlijk schrijf ik in ieder geval alles (op wat veelvoorkomende basisfuncties na) per site aangezien ik een verschrikkelijke hekel heb aan al die bloated libraries.

[crisp]

Anders schreef op woensdag 16 augustus 2006 @ 15:42:
[...]


Dit vind ik een non-argument. Op die manier kun je elk CMS wel diskwalificeren (als je niet weet hoe HTML in elkaar zit...), elke front-ends (phpMyAdmin en consorten) en zo ongeveer elk product ter wereld for that matter. Een keukenmachine kopen? Niet aan beginnen: als je niet weet hoe-ie in elkaar steekt kun je 'm zelf niet fixen. Gebruik liever een aardappelschilmesje.

Een CMS of een front-end is natuurlijk niet echt te vergelijken. Punt is dat browser-omgevingen niet homogeen zijn en daar ligt 'm het probleem. Als ik zo door de prototype-code heenloop zie ik bijvoorbeeld een aantal zaken waarvan ik weet dat het in IE < 6 niet gaat werken, en ook zaken die in specifieke gevallen problemen op kunnen leveren in andere browsers.
Als jij als ontwikkelaar zonder enige kennis van javascript met een dergelijke library aan de slag gaat en tegen deze problemen aanloopt dan heb je ineens een heel groot probleem want wie gaat het dan voor je oplossen?

[SchizoDuckie]

Wat ik altijd doe:

HTML:

<script>
Function ditEnMeDat()
{
alert('blaat');
}
</script>

en dan bij de onComplete van mn request ditEnMeDat aanroepen

ik gebruik trouwens moo.ajax

[ Voor 4% gewijzigd door SchizoDuckie op 16-08-2006 16:21 ]

[Yo-han]

it's a small world

eerste 2 regels uit moo.ajax

//based on prototype's ajax class
//to be used with prototype.lite, moofx.mad4milk.net.

[crisp]

En ik zie al 4 potentiele problemen in dat stukje moo-code

[marko77]

Het argument dat het niet in 'alle' browsers zou werken is iets dat imo niet opgaat.

Als je besluit om javascript te gebruiken beperk je je doelgroep al, dus alle browsers is dan al niet meer haalbaar. Het is sowieso een illusie om te denken dat je een website kunt maken die bij 'iedereen' goed draait en er exact hetzelfde uitziet.

Ik ben het wel eens met de opmerking dat mensen zonder goede kennis van javascript een probleem hebben zodra er in een specifieke browser een probleem optreedt.
In de praktijk is het volgens mij vaak zo dat als de applicatie/website goed draait in FF en IE (5.5+ meestal) dat het probleem dan geen prio krijgt, simpelweg omdat dat tijd én geld kost.

Maar je kan ook niet álles hebben

[crisp]

marko77 schreef op donderdag 17 augustus 2006 @ 09:45:
Het argument dat het niet in 'alle' browsers zou werken is iets dat imo niet opgaat.

Dat zeg ik ook helemaal niet, ik zeg alleen dat ik in prototype potentiele problemen zie als je ook IE5 en/of IE5.5 moet ondersteunen hetgeen tegenwoordig helaas vaak nog het geval is...

[marko77]

point taken

maar ik denk dat het gebruik van prototype niet je grootste probleem is als je moet devven voor IE5

[Anders]

Ik blijf het een zwak argument vinden. Tegen compatibilityproblemen loop je vrijwel altijd op, of je nou een library gebruikt of je eigen javascript-code from scratch ontwikkelt. Het aardige is dat het gebruik van een library een hoop tijd kan schelen - je hoeft niet telkens zelf opnieuw het wiel uit te vinden - en dat veel libraries bovendien een flinke community kennen die je kunnen helpen een probleem op te lossen.

Met eigen code kun je dat laatste al snel vergeten als je het niet in een paar regels duidelijk kunt maken. Niemand die 20 kB onbekend javascript voor je gaat doorspitten.