[Ajax/DWR] Forms zonder refresh

[Catscratch]

Ik ben vorige week begonnen als consultant op een nieuw bedrijf. Ik ben momenteel wachtende op een project, dus ze vroegen of ik in de tussentijd een Java ontwikkelomgeving kon opzetten voor interne projecten. Wat ze graag hadden: oa Struts, Hibernate en DWR.

Momenteel draait alles, maar bij het ontwikkelen van een test programma zit ik even vast. Stel je even een heel simpele webpagina voor met 2 divjes. Links vinden we de personeelslijst en wanneer we iemand aanklikken krijgen we rechts een editformpje. Makkelijk toch?

Hoe kan ik de rechtse div vullen met een formpje zonder dat de hele pagina refresht?

Via DWR kan ik wel een java methode schrijven die een String teruggeeft met allerhande HTML tags voor het opbouwen van een form. Maar is het net niet de bedoeling van een MVC architectuur om logica duidelijk van presentatie te scheiden? HTML laten returnen serverside vind ik ongelooflijk vies. Via DWR kan ik ook geen actionclass gebruiken/aanspreken die op zijn beurt forward naar een jsp.

Een andere mogelijkheid is een iframe rechts te plaatsen, maar ik denk dan wel dat ik tegen de regels van de kunst zondig ...

Een laatste mogelijkheid zou zijn om DWR te laten vallen (alleszins voor dit probleem), en gewoon 'manueel' een xmlhttprequest vuren (of een wrapper te gebruiken zoals tw-sack). Maar wordt dan mijn (gegenereerde) javascript ook niet ongeldig daar alles in de innerHTML van de div wordt gegooid? Hoe kan ik dan m'n save ajax call vuren?

Hoe los ik dit probleem volgens de regels van de kunst?

Bedankt!

[SchizoDuckie]

oh leuk jij bent een van die 'consultants' die dingen op moeten lossen waar ze zelf ook niets van weten?

Maar even serieus
Wat jij wil is eigenlijk gewoon een lapje html binnentrekken zonder de hele layout meuk eromheen die je voor de rest van je paginas binnenkrijgt.

Wat ik zelf doe in java (Struts, Tiles, BC4J) is idd gewoon een xmlhttprequest laten afvuren (via Mootools) zodat deze netjes door de struts laag heengaat, en dan vervolgens forwarden naar een speciale tiles page die het complete opmaak framework niet meegeeft.

Zo kan je deze 'speciale' ajax paginas afhandelen op exact dezelfde manier als de rest van je paginas

Gegenereerd javascript in je ajax'ed pagina kan je trouwens eval'en binnen de page scope (Zie bijv. Mootools' evalScript property)

[crisp]

Ik laat de markup meestal door het javascript component genereren en stuur enkel ruwe data over de lijn (JSON). Dat je er in sommige gevallen voor kiest om toch al compete markup met data over de lijn te sturen kan ik me nog iets bij voorstellen, maar behavior meesturen in je data is een dikke no-no dus als je evalScript nodig hebt dan zit je applicatie gewoon niet goed in elkaar.

[Gomez12]

Wat is er mis met het serverside genereren van html code, dit gebeurt standaard ook al.
Zolang je in je serverside code maar wel de scheiding duidelijk hebt lopen. Hoe het naar de client gaat heeft imho niets meer met mvc te maken.

@crisp: Ben nu bezig met een menu wat heel veel verschillende forms / representaties moet kunnen weergeven ( vergelijk het met het hoofdmenu van t.net ). Klant wil perse geen screen refresh. Ik ben niet zo'n superster in JS, maar heb het wel geprobeerd zonder eval ( zoveel mogelijk meesturen met het menu ) maar toen ik uitkwam op 150kb JS om alle mogelijkheden te ondervangen op een menutjes van 5kb ( zonder JS ) heb ik toch maar voor de middenweg gekozen en 35kb JS in menu gestopt en 4 evals als een speciale functie aangeroepen wordt.
Is het dan toch handiger om 150kb over te sturen?

Let wel op dat ik geen ster in JS ben, dus waarschijnlijk is 150kb heel erg goed te comprimeren / anders te schrijven maar op dit moment vind ik dit niet handig in verband met comments / overzicht etc.

[momania]

Als je voor de klant te veel javascript moet gebruiken om alleen screen refresh te voorkomen, ben je de techniek imho verkeerd aan het gebruiken, of je moet iets anders kiezen (Flex oid bv).

Er schijnt echt een hype rond ajax te ontstaan en een fobie voor screen refresh, maar ik snap daar echt niets van. Doe wat simpel is en evengoed werkt

---

Html terug sturen is trouwens verder niks mis mee.

[ Voor 8% gewijzigd door momania op 27-06-2007 00:15 ]

[crisp]

Gomez12 schreef op woensdag 27 juni 2007 @ 00:08:
Wat is er mis met het serverside genereren van html code, dit gebeurt standaard ook al.
Zolang je in je serverside code maar wel de scheiding duidelijk hebt lopen. Hoe het naar de client gaat heeft imho niets meer met mvc te maken.

Als het om zaken gaat die je inderdaad serverside al geimplementeerd hebt om de markup te genereren dan is het inderdaad weinig zinvol om dat clientside nog eens te doen, dus dat is een goed argument.
Voor non-triviale zaken heb je sowieso een non-JS based fallback nodig.

Als voorbeeld kan ik bijvoorbeeld het uitklappen van 'verborgen' reacties noemen op de frontpage; de code die reactiedata omzet naar markup is serverside al aanwezig, dus haal ik bij het 'uitklappen' ook al een complete marked-up reactie op.

Als het gaat om markup ten behoeve van pure JS functionaliteit (zoals bijvoorbeeld de toolbar naast het reactieformulier op de frontpage, of de 'properties' popups voor de tracker waar ook serverside data voor nodig is) dan wil je eigenlijk alles binnen JS houden.

@crisp: Ben nu bezig met een menu wat heel veel verschillende forms / representaties moet kunnen weergeven ( vergelijk het met het hoofdmenu van t.net ). Klant wil perse geen screen refresh. Ik ben niet zo'n superster in JS, maar heb het wel geprobeerd zonder eval ( zoveel mogelijk meesturen met het menu ) maar toen ik uitkwam op 150kb JS om alle mogelijkheden te ondervangen op een menutjes van 5kb ( zonder JS ) heb ik toch maar voor de middenweg gekozen en 35kb JS in menu gestopt en 4 evals als een speciale functie aangeroepen wordt.
Is het dan toch handiger om 150kb over te sturen?

Let wel op dat ik geen ster in JS ben, dus waarschijnlijk is 150kb heel erg goed te comprimeren / anders te schrijven maar op dit moment vind ik dit niet handig in verband met comments / overzicht etc.

Ik kan me daar toch weinig bij voorstellen, maar 150KB aan JS lijkt me echt onnodig veel...

[Gomez12]

momania schreef op woensdag 27 juni 2007 @ 00:13:
Als je voor de klant te veel javascript moet gebruiken om alleen screen refresh te voorkomen, ben je de techniek imho verkeerd aan het gebruiken, of je moet iets anders kiezen (Flex oid bv).

Er schijnt echt een hype rond ajax te ontstaan en een fobie voor screen refresh, maar ik snap daar echt niets van. Doe wat simpel is en evengoed werkt

Ach tja, klant wil geen screen refresh vanuit het menu, maar wel 30 verschillende soorten pagina's gevuld met JS-functies hebben.
Met screenrefresh zou de max-pagina ongeveer 65kb JS meekrijgen, maar door de vraag zonder screenrefresh zit ik met het dilemma of alle JS in het menu stoppen of enkele evals.

En btw de hoeveelheid JS zit dus niet in het ajax-gedeelte, maar meer in dat ik voor 30 soorten pagina's allerhande JS moet meegeven, want het wordt op 2 pagina's uit het menu gebruikt.

En klant heeft geen fobie voor screen refresh, maar wil een mooie compleet geintegreerde website die in wezen als een desktop app reageert en dat effect werkt minder met screen refresh. En flash is net iets over the top voor de doelgroep.

crisp schreef op woensdag 27 juni 2007 @ 00:22:
[...]
...

[...]

Ik kan me daar toch weinig bij voorstellen, maar 150KB aan JS lijkt me echt onnodig veel...

Ach tja, je probeert wat zonder uitgebreide JS kennes, het werkt, je gooit er veeeel commentaar tegenaan, je hebt een klant die het gelijk als vriendendienst beschouwt en die ook weet dat hij niet met een deadline / al te zware eisen moet komen omdat het ook voor mij deels een hobby/leer project is.
Maar zoals ik al zei het kan een stuk kleiner ( simpelweg commentaar schrappen scheelt al 60 kb code, maar vind ik op dit moment niet handig ) en het gaat mij ook meer om het principe dat als ik voor 30 pagina soorten alle JS moet preparen dat ik dan een gigantisch brok JS krijg waarvan een groot gedeelte gewoon maar op 1 of 2 pagina's gebruikt wordt. En dat vind ik zonde.
En ja, ik ben opgegroeid met een 2400 baud modem, dus al heeft iedereen ter wereld breedband, in huidige vorm 150kb JS meesturen vind ik zonde van de bandbreedte

[ Voor 30% gewijzigd door Gomez12 op 27-06-2007 00:39 ]

[curry684]

Gomez12 schreef op woensdag 27 juni 2007 @ 00:30:
[...]

En btw de hoeveelheid JS zit dus niet in het ajax-gedeelte, maar meer in dat ik voor 30 soorten pagina's allerhande JS moet meegeven, want het wordt op 2 pagina's uit het menu gebruikt.

Hier ben je me toch ergens kwijt... kun je dit een keer langzaam en uitgebreid uitleggen?

En ja, ik ben opgegroeid met een 2400 baud modem, dus al heeft iedereen ter wereld breedband, in huidige vorm 150kb JS meesturen vind ik zonde van de bandbreedte

Het feit dat mod_gzip cq. mod_deflate van die 150Kb minder dan 20Kb overlaten is wel relevant in deze. Je kunt beter plaatjes optimaliseren en HTTP/1.1 throttles gaan elimineren meestal voor die laatste seconde performance.

[Catscratch]

Alleszins bedankt voor de reacties ... hier heb ik wat aan

Ik denk dat ik m'n Ajax calls zelf ga schrijven (of een kleine wrapper zoals tw-sack) ga gebruiken om zo m'n form over te halen. De actionclass doet de nodige database calls en forward op zijn beurt naar een jsp. Daar het resultaat van, krijg ik dan als response in m'n javascript binnen. Zo hou ik de HTML/opmaak toch uit m'n java klassen.

Het saven van de form kan op dezelfde manier. Dat lijkt me het cleanst. Of ik kan via DWR wel een java klasse aanspreken en zo gewoon de .save() methode gebruiken. Als response moet ik toch enkel maar een vlaggetje terugkrijgen of de actie geslaagd is of niet.

De javascript omtrent de form steek ik gewoon in het skelet van de pagina waar de divjes in zitten.

Op m'n vorig werk werkte ik aan een 7-8 jaar oude webapplicatie ... daar waren zulke schermen gewoon 2 frames naast elkaar.

[crisp]

Het nadeel van zulke 'geen refresh' oplossingen is meestal dat er niet goed wordt nagedacht over accessibility. Hoe los je het probleem van bookmarken op? Hoe handel je de back en forward functionaliteit van de browser af? Is je site nog wel goed indexeerbaar (zijn alle pagina's wel bereikbaar met een uniek URL)? Heb je non-JS fallback? etcetera...

Voor een interne webapplicatie zal dit wellicht allemaal niet zo spelen, maar het zijn wel zaken waar je rekening mee moet houden als het om een externe website zou gaan.

Verder lijkt me bandbreedte binnen een intranet ook niet zo'n groot probleem. Je kan, zoals curry684 al aangeeft, ook HTTP compressie gaan toepassen. Dat gecombineerd met het feit dat JS files default toch gecached worden door browsers maakt dat ook een minder groot probleem.
Je zou je produktie-versie zelfs nog kunnen minifyen (whitespace en comments strippen, of zelfs echt compressen met bijvoorbeeld Dean Edwards' packer oid)

otoh zou er bij een non-ajax oplossing (gewone page-refreshes) van je 5KB inline menu ook maar bar weinig over blijven bij het gebruik van HTTP compressie

nog wat overpeinsingen:

zorg ervoor dat je bij asynchrone requests die eventueel wat langer kunnen duren ook een busy-wait indicatie aan de gebruiker geeft.

is een iframe eventueel geen oplossing?

al met al vind ik ajax meer een technologie die je toepast bovenop de basis-technologie en niet iets waarmee je die basis moet vervangen...

[ Voor 68% gewijzigd door crisp op 27-06-2007 10:20 ]

[Catscratch]

crisp schreef op woensdag 27 juni 2007 @ 10:06:
Het nadeel van zulke 'geen refresh' oplossingen is meestal dat er niet goed wordt nagedacht over accessibility. Hoe los je het probleem van bookmarken op? Hoe handel je de back en forward functionaliteit van de browser af? Is je site nog wel goed indexeerbaar (zijn alle pagina's wel bereikbaar met een uniek URL)? Heb je non-JS fallback? etcetera...

Het leuke is wel dat dit een testschermpje is om m'n onderliggende frameworks te testen. Maar het zijn inderdaad wel belangrijke punten die je aanhaalt. Ik vraag me nu eigenlijk af of ik niet beter met ouderwetse refreshes zou werken. Tenslotte functionaliteit > design & fantasietjes.

is een iframe eventueel geen oplossing?

Wel als onderliggende database heb ik hier snel Oracle XE geinstalleerd (ze gebruiken hier voor 90% Oracle). Die database kan je administraten via een mooie webapp. Ze gebruikten ook forms zonder refreshes. Heerlijk, maar als ik in de code ging kijken gebruikten ze doodgewoon een iframe.

Ik dacht dat het gebruik van frames uit de boze was? Net zoals het gebruik van tables tegenwoordig ook al aardig afgeraden wordt wanneer je divs kunt gebruiken.

al met al vind ik ajax meer een technologie die je toepast bovenop de basis-technologie en niet iets waarmee je die basis moet vervangen...

Inderdaad, ik had me Ajax iets grootser voorgesteld. En het is een rasechte hype tegenwoordig. Ik denk dat ik Ajax eerder ga gebruiken voor kleine dingen zoals bv een on-the-fly usernamecheck. En daar lijkt die DWR ideaal voor.

Ondertussen ben ik MooTools aan het bekijken wat SchizoDuckie vermelde ... ziet er aardig uit

[crisp]

Catscratch schreef op woensdag 27 juni 2007 @ 10:33:
[...]

Ik dacht dat het gebruik van frames uit de boze was? Net zoals het gebruik van tables tegenwoordig ook al aardig afgeraden wordt wanneer je divs kunt gebruiken.

Frames hebben in meer of mindere mate ook vergelijkbare issues mbt accessibility, maar in sommige gevallen is het een oplossing.

Het tables vs divs verhaal is anders, en je moet divs ook niet zien als een 'vervanging' van tables. Waar het om gaat is dat je opmaak en content van elkaar gescheiden houdt (dus CSS gebruikt) en voor markup die elementen gebruikt die je content het best beschrijven (en dat zijn meestal niet divs).
Divs gebruik je om elementen te groeperen voor je layout.

[...]

Inderdaad, ik had me Ajax iets grootser voorgesteld. En het is een rasechte hype tegenwoordig. Ik denk dat ik Ajax eerder ga gebruiken voor kleine dingen zoals bv een on-the-fly usernamecheck. En daar lijkt die DWR ideaal voor.

Ajax wordt inderdaad te vaak voorgesteld als een soort complete en volwaardige technologie terwijl het gewoon een techniek is binnen de al bestaande technologie.

Ondertussen ben ik MooTools aan het bekijken wat SchizoDuckie vermelde ... ziet er aardig uit

Libraries zijn leuk en hebben wel nut maar je leert er natuurlijk geen javascript van
Zelf ben ik wel aardig gecharmeerd van de benadering die prototype toepast, maar ook niet op alle punten.

[Catscratch]

crisp schreef op woensdag 27 juni 2007 @ 11:54:Libraries zijn leuk en hebben wel nut maar je leert er natuurlijk geen javascript van
Zelf ben ik wel aardig gecharmeerd van de benadering die prototype toepast, maar ook niet op alle punten.

Maar na ettelijke jaren scripten is het ook wel eens een leuke afwisseling
Alleszins heel hard bedankt voor je tijd en moeite!

[curry684]

crisp schreef op woensdag 27 juni 2007 @ 11:54:
Ajax wordt inderdaad te vaak voorgesteld als een soort complete en volwaardige technologie terwijl het gewoon een techniek is binnen de al bestaande technologie.

Die vervolgens ook nog eens zelden volgens z'n originele bedoeling wordt ingezet. Raise hands wie alleen maar asynchrone requests uitzet om XML clientside te parsen?

Ajax is een modewoord voor het toepassen van het XmlHttpRequest object, verder stelt het weinig voor en wordt de term (te) vaak misbruikt voor duizenden andere dingen die al jaren met Javascript kunnen.

@crisp: MooTools leent een aantal charmante dingen van Prototype, en zit tegenwoordig imho erg goed in mekaar.

[crisp]

curry684 schreef op woensdag 27 juni 2007 @ 14:23:
[...]
@crisp: MooTools leent een aantal charmante dingen van Prototype, en zit tegenwoordig imho erg goed in mekaar.

Ik leen ook de charmante dingen van prototype, voor de rest heb ik geen behoefte aan dergelijke libraries