[AJAX] taal? library? api? of techniek? - Softwareontwikkeling

zondag 5 augustus 2007 06:20

Acties:

Topicstarter

JKVA schreef op maandag 30 juli 2007 @ 08:57:
[...]
Ik neem aan dat hier (ik schat de gemiddelde tweaker vrij hoog in) vrijwel niemand denkt dat AJAX een taal is, maar manier van werken. XMLHTTP is puur een middel om het toe te passen. De taal blijft JavaScript + PHP/Java/ASP......

Op zich was dit nu juist de reden dat ik het topic startte. Ik werk voor Atos Origin en als ik de ontwikkelaars in het gebouw naast ons vertel dat de taal waar ik me het meest mee bezig hou en het best beheers javascript is wordt dat een beetje lacherig weggemoffeld "wij doen niks met javascript". Terwijl de primaire applicatie die we ondersteunen toch echt webbased is en via ajax met zijn java back-end praat. De libraries zijn kennelijk zo uitgebreid dan men zich niet realiseert dat met toch echt met javascript te maken heeft.

Ik probeer altijd voorzichtig te zijn en mijn redenatie aan te passen zodat ik niet tot de conclusie kom dat ik met mijn 21 jaar een beter beeld heb van de talen, methoden en tools dan deze (overigens gerespecteerde) collega's. Maar misschien moet ik niet zo bescheiden zijn

Daarnaast wil ik het volgende toevoegen aan de discussie, een aantal tweakers hoor ik klagen over dat de browser een back-button heeft en favorieten en dat dat hun applicatie in de weg loopt. Ik denk dat als dat je redenatie is, dat je je slecht kunt aanpassen. Je moet dat volgens mij niet als obstakel zien waar je je tegen moet verzetten met alle (return false; ) technieken die je kunt bedenken. Dat is het gegeven waar je vanuit moet gaan, je kunt een applicatie maken waarbij het voor de gebruiker makkelijk is om naar het vorige dialoogvenster te gaan en dialoogvensters die uit ervaring vaak nodig blijken te zijn aan de favorieten toe te voegen. Voor mensen in bijvoorbeeld callcenters voegt dat een stuk usability toe, neem dat niet weg omdat het niet in jou beeld van de applicatie-flow past. Dat beeld is gebaseerd op jou referentiekader van het database-model en de verdere back-end, niet op ervaring met een boze klant aan de lijn die je snel wil helpen.

Met ajax heb je de mogelijkheid om een proces single-paged te houden zodat het niet middenin gefavorite kan worden, dus dingen als (om een duidelijk voorbeeld te noemen) phpBB waarbij je 3 pagina's hebt voor respectievelijk het typen, het plaatsen in de database en het bekijken van een post kunnen in 1 pagina. Als die middels back of een favorite aangesproken wordt moet hij dit gewoon accepteren en het begin van het proces laten zien, dat is het wezen van een webapplicatie imho.

zondag 5 augustus 2007 11:34

Acties:

flowerp

funkwurm schreef op zondag 05 augustus 2007 @ 06:20:
Daarnaast wil ik het volgende toevoegen aan de discussie, een aantal tweakers hoor ik klagen over dat de browser een back-button heeft en favorieten en dat dat hun applicatie in de weg loopt. [...]. Voor mensen in bijvoorbeeld callcenters voegt dat een stuk usability toe, neem dat niet weg omdat het niet in jou beeld van de applicatie-flow past. Dat beeld is gebaseerd op jou referentiekader van het database-model en de verdere back-end, niet op ervaring met een boze klant aan de lijn die je snel wil helpen.

Als je dat denkt dan heb je of de discussie niet goed begrepen, of niet goed gelezen.

Het concept van een back-button is helemaal niet het probleem waar web-developers over klagen. Het gaat om de implementatie hiervan (en de non-support ervoor qua protocol) in de huidige web-browsers.

Bij het gebruik van de backbutton lopen de client en de server uitelkaar, zonder dat de server hier weet van kan hebben. Bij een volgende request vanuit een venster waarin de back-button werd gebruikt, moeten er veel synchronisatie checks plaatsvinden. Dit is een hoop 'gedoe' en werkt lang niet altijd goed als je niet heel goed oplet.

Het hele punt van de discussie was hem nou juist dat al dat 'gedoe' eigenlijk niet had gehoeven wanneer we een beter protocol en/of platform hadden gehad. Ter vergelijking; ik heb enkele plug-ins
voor de Eclipse omgeving ontwikkeld. Voor oa de preferences kent deze ook de back-button. In tegenstelling tot de web-browser werkt het programmeer-model hier gewoon wel goed.

It's shocking to find how many people do not believe they can learn, and how many more believe learning to be difficult.

zondag 5 augustus 2007 14:49

Acties:

funkwurm

Topicstarter

flowerp schreef op zondag 05 augustus 2007 @ 11:34:
[...]
Bij het gebruik van de backbutton lopen de client en de server uit elkaar, zonder dat de server hier weet van kan hebben. Bij een volgende request vanuit een venster waarin de back-button werd gebruikt, moeten er veel synchronisatie checks plaatsvinden.

Als je hier tegenaan loopt dan concludeer ik toch dat je 1 proces in je applicatie over meerdere pagina's verspreid, anders zou synchronisatie niet zo'n issue zijn volgens mij.

Maar als je een voorbeeld kan noemen van iets wat absoluut niet op 1 pagina met ajax-based server-communicatie kan blijven, maar waar je absoluut meerdere volledig nieuwe pagina's nodig hebt om door 1 "taak" van de applicatie te komen, dan kan ik je gelijk geven.

Maar ik kan zo'n voorbeeld niet bedenken, je kunt als het moet de volledige pagina verwijderen en opnieuw opbouwen met DOM-bewerkingen zonder een nieuwe pagina aan te roepen, waarmee die dynamisch gecreëerde pagina nooit plotseling in de history of de favorieten terecht komt. Niet dat ik daar nu voor zou kiezen, maar om even aan te geven hoe mijn redenatie is.

zondag 5 augustus 2007 15:03

Acties:

flowerp

funkwurm schreef op zondag 05 augustus 2007 @ 14:49:
[...]
Maar ik kan zo'n voorbeeld niet bedenken, je kunt als het moet de volledige pagina verwijderen en opnieuw opbouwen met DOM-bewerkingen zonder een nieuwe pagina aan te roepen, waarmee die dynamisch gecreëerde pagina nooit plotseling in de history of de favorieten terecht komt.

Dat ontneem je de gebruiker juist de back-button en dat wilde je juist niet. Ik herhaal: het is niet het concept van de back-button wat broken is maar de implementatie ervan in het huidige HTTP protocol en de huidige web browsers.

It's shocking to find how many people do not believe they can learn, and how many more believe learning to be difficult.

zondag 5 augustus 2007 15:54

Acties:

Verwijderd

flowerp schreef op zondag 05 augustus 2007 @ 15:03:

Dat ontneem je de gebruiker juist de back-button en dat wilde je juist niet. Ik herhaal: het is niet het concept van de back-button wat broken is maar de implementatie ervan in het huidige HTTP protocol en de huidige web browsers.

De back button heeft echt niks met het HTTP protocol te maken. Er wordt nergens in dat protocol iets over geschreven, en is dus niet eens verplicht voor user agents. Logisch ook, want in feite is elke HTTP client een user agent, dus ook spiders van zoekmachines en dergelijke. Waarom zou in dat protocol moeten worden vastgelegd wat een client wel of niet zou moeten bieden aan functionaliteit?

Waarom zou een user agent niet kunnen nagaan of een webapplicatie bepaalde punten heeft waarin de complete state kan worden vastgelegd, waarmee de user agent dus iets met een back button kan? Dat bestaat nu helemaal niet, voor zover ik weet. Maar dat heeft nog altijd niets met het HTTP protocol te maken. Dat gebeurt op een "pagina" die door de user agent is geladen. Of dat nou vanaf de harddisk of via HTTP of via FTP of whatever is gedaan, moet toch niet uitmaken?

Nog 1 keer: het HTTP protocol is echt niet b0rked. De implementatie soms een beetje, maar dat staat los van waar het nu over gaat, en heeft niets te maken met back buttons, waar HTTP terecht geen weet van heeft.

zondag 5 augustus 2007 16:18

Acties:

flowerp

Verwijderd schreef op zondag 05 augustus 2007 @ 15:54:
[...]
De back button heeft echt niks met het HTTP protocol te maken.

Correctie: de back button heeft echt niks met het HUIDIGE HTTP protocol te maken.

Ik heb al een aantal mogelijk oplossingen genoemd die in het HTTP protocol de problemen met de back button zouden kunnen verbeteren, waaronder een sequence nummer, zodat de server weet of een click vanuit de huidige pagina komt, of vanaf een pagina die is bereikt via de back button.

Een andere mogelijkheid is het doorgeven van het gebruik van de back button, als de server hierom gevraagd heeft.

Als ik in Eclipse de back button gebruik dan -weet- mijn code dat ogenblikkelijk en kan ik diverse acties ondernemen. Het HTTP protocol heeft hier geen support voor. Met Javascript kan je soms er om heen werken, maaruh... "gedoe!"....

It's shocking to find how many people do not believe they can learn, and how many more believe learning to be difficult.

zondag 5 augustus 2007 16:29

Acties:

Verwijderd

flowerp schreef op zondag 05 augustus 2007 @ 16:18:

Correctie: de back button heeft echt niks met het HUIDIGE HTTP protocol te maken.

Het heeft niets met welk transport protocol dan ook te maken.

Ik heb al een aantal mogelijk oplossingen genoemd die in het HTTP protocol de problemen met de back button zouden kunnen verbeteren, waaronder een sequence nummer, zodat de server weet of een click vanuit de huidige pagina komt, of vanaf een pagina die is bereikt via de back button.

Een andere mogelijkheid is het doorgeven van het gebruik van de back button, als de server hierom gevraagd heeft.

Als ik in Eclipse de back button gebruik dan -weet- mijn code dat ogenblikkelijk en kan ik diverse acties ondernemen. Het HTTP protocol heeft hier geen support voor. Met Javascript kan je soms er om heen werken, maaruh... "gedoe!"....

De server hoeft helemaal niet te weten of er een back button gebruikt is. Je vraagt een of ander document op, de server zorgt dat je dat krijgt. Als je specifieke informatie mee wilt geven, kun je dat bijvoorbeeld doen via een cookie, of via een query string. Of hoe je dat maar wilt doen. Dat is aan de client. Die kan makkelijk even een cookie meesturen als iemand op een back button heeft geklikt.

Er zijn mogelijkheden genoeg, maar omdat de huidige clients nou niet echt intelligente oplossingen voor dat soort gebruik van applicaties hebben is geen fout van het protocol. Meer van de omgeving waarin de webapplicatie draait. Maar browsers laten het voor zover ik weet niet toe om events te koppelen aan klikken op dergelijke navigatieknoppen. Als dat zou kunnen, was er geen enkel probleem. Wellicht dat het wel kan als je met ActiveX componenten of applets aan de gang gaat. Dat weet ik niet eigenlijk.

zondag 5 augustus 2007 16:54

Acties:

JKVA

Design-by-buzzword fanatic

Verwijderd schreef op zondag 05 augustus 2007 @ 16:29:
[...]

Het heeft niets met welk transport protocol dan ook te maken.

[...]

De server hoeft helemaal niet te weten of er een back button gebruikt is. Je vraagt een of ander document op, de server zorgt dat je dat krijgt. Als je specifieke informatie mee wilt geven, kun je dat bijvoorbeeld doen via een cookie, of via een query string. Of hoe je dat maar wilt doen. Dat is aan de client. Die kan makkelijk even een cookie meesturen als iemand op een back button heeft geklikt.

Er zijn mogelijkheden genoeg, maar omdat de huidige clients nou niet echt intelligente oplossingen voor dat soort gebruik van applicaties hebben is geen fout van het protocol. Meer van de omgeving waarin de webapplicatie draait. Maar browsers laten het voor zover ik weet niet toe om events te koppelen aan klikken op dergelijke navigatieknoppen. Als dat zou kunnen, was er geen enkel probleem. Wellicht dat het wel kan als je met ActiveX componenten of applets aan de gang gaat. Dat weet ik niet eigenlijk.

De server hoeft ook niet op de hoogte gebracht te worden van een back actie van de gebruiker. Als je de URL verandert, zoals door een http://www.mijnURL.nl/#tellerVariabele en steeds de teller ophoogt, wordt bij een back actie de vorige pagina hersteld uit de browser cache. Overigens is dit volgens mij niet echt een waterdichte oplossing, maar goed.

Dat is mijn probleem met dergelijke client side oplossingen. Telkens als je denkt een goede oplossing te hebben, blijk je er weer op een andere manier onderuit te kunnen, bijv door andere browserinstellingen.

Fat Pizza's pizza, they are big and they are cheezy

zondag 5 augustus 2007 16:56

Acties:

flowerp

Verwijderd schreef op zondag 05 augustus 2007 @ 16:29:
[...]
Het heeft niets met welk transport protocol dan ook te maken.

HTTP is geen transport protocol maar een transfer protocol. Een transfer protocol zit bovenop een transport protocol (zoals TCP, of UDP), en bepaalt hoe -informatie- tussen hosts uitgewisseld wordt. Een ander voorbeeld van een transfer protocol is bijvoorbeeld JRMP.

De server hoeft helemaal niet te weten of er een back button gebruikt is. Je vraagt een of ander document op, de server zorgt dat je dat krijgt.

-zucht- we hebben het hier niet over documenten, maar over applicaties.

Ik snap dat het verschil moeilijk is om te begrijpen, maar dat is nu exact waar deze discussie nu over gaat. HTTP is oorspronkelijk bedoeld om inderdaad (hypertext) documenten mee over te dragen. De industrie heeft ons gedwongen om er ook applicaties boven op te bouwen en DAARVOOR missen er een aantal simpele maar essentiële elementen in het protocol.

It's shocking to find how many people do not believe they can learn, and how many more believe learning to be difficult.

zondag 5 augustus 2007 17:08

Acties:

funkwurm

Topicstarter

flowerp schreef op zondag 05 augustus 2007 @ 15:03:
[...]

Dat ontneem je de gebruiker juist de back-button en dat wilde je juist niet. Ik herhaal: het is niet het concept van de back-button wat broken is maar de implementatie ervan in het huidige HTTP protocol en de huidige web browsers.

Nee, dit is geen voorbeeld van het ontnemen van een directe ingang naar de pagina met de gewenste functionaliteit. Jouw bezwaar tegen de huidige implementatie van de back-button is dat je op de server niet weet wanneer deze gebruikt is, is ben opzoek naar een situatie waarin je dat persee zou willen, want ik ben er van overtuigt dat je dat niet hoeft te weten.

De enige reden dat je dat zou willen weten om de synchronisatie server en client gelijk te kunnen trekken is als je 1 logisch proces over meerdere pagina's uitspreid en dat hoeft nu juist niet meer. Dit is een voorbeeld waarbij je middels ajax 1 logisch proces wat nu eenmaal 2 totaal verschillende pagina's nodig heeft (want dat zocht ik immers) toch op 1 pagina kan krijgen. Hiermee elimineer je de mogelijkheid voor de gebruiker om midden in het proces te springen (wat je als gebruiker ook niet snel zou willen, plotseling de vraag "weet je zeker dat je deze bestanden wilt verwijderen?" krijgen terwijl je geen opdracht gaf om te verwijderen) en dus de noodzaak om te synchroniseren, en je zorgt dat het gebruik van de back-button de gebruiker altijd naar een logisch (begin)punt van het proces brengt.

@cheatah: de back-button fired geen ander event dan onunload, maar die fired ook bij andere gebeurtenissen, het is dus inderdaad lastig om de server duidelijk te maken wat de gebruiker gedaan heeft. Maar mijn punt is nogmaals dat je dat ook niet moet willen.

zondag 5 augustus 2007 18:07

Acties:

Verwijderd

flowerp schreef op zondag 05 augustus 2007 @ 16:56:

HTTP is geen transport protocol maar een transfer protocol. Een transfer protocol zit bovenop een transport protocol (zoals TCP, of UDP), en bepaalt hoe -informatie- tussen hosts uitgewisseld wordt. Een ander voorbeeld van een transfer protocol is bijvoorbeeld JRMP.

Achja, ga even in op een kleine doch niet catastrofale verspreking. Het moge duidelijk zijn dat HTTP gebruikt wordt om gegevens te transferren/transporteren/vervoeren/verzenden/hoe-je-het-ook-wilt-noemen.

-zucht- we hebben het hier niet over documenten, maar over applicaties.

In de meeste gevallen worden die als document geserveerd aan de client, maar ok, het zij niet altijd complete documenten, een stuk van een of andere stream kan natuurlijk ook.

Ik snap dat het verschil moeilijk is om te begrijpen, maar dat is nu exact waar deze discussie nu over gaat. HTTP is oorspronkelijk bedoeld om inderdaad (hypertext) documenten mee over te dragen. De industrie heeft ons gedwongen om er ook applicaties boven op te bouwen en DAARVOOR missen er een aantal simpele maar essentiële elementen in het protocol.

En ik probeer uit te leggen dat dat niets met het protocol te maken heeft, maar dat dat alles te maken heeft met de clients. Het is in theorie prima mogelijk om een applicatie te schrijven die zijn eigen user interface definieert, en die van de user agent buiten beschouwing laat. De user agent zou dan bijvoorbeeld eerst goedkeuring van de eindgebruiker moeten vragen om dat toe te laten. Vanaf dat moment zou je de functie van een back button zelf kunnen definiëren. Waarom zou er dan iets aan het HTTP protocol moeten worden gewijzigd of toegevoegd? Ik denk dat je echt een verkeerd beeld hebt van het protocol.

zondag 5 augustus 2007 18:54

Acties:

.oisyn

Moderator Devschuur®

Demotivational Speaker

Ik zie hier een discussie over backbuttons, die compleet voorbij gaat aan het feit dat het botgezegd RUK is dat een webapp in een browser draait met zijn eigen UI, en dat een backbutton je hele webapp nogal in de knoei kan laten gooien. Niet eens vanuit een development-perspectief - als gebruiker vind ik het ook rete-irritant dat als ik per ongeluk op de backbutton druk (ja er zit er een op m'n muis, strontvervelend als ik met mijn hand van toetsenbord naar muis beweeg om mijn post te posten, en daarbij per ongeluk met mijn duim tegen die knop aanstoot), de hele interne state van de webapp ineens compleet lost is.

En dan terug naar het development-perspectief: tegen dit soort situaties kun je je dan wel weer indekken door regelmatig een status-update terug te sturen naar de server, of relevante data in cookies op te gaan zitten slaan, of wat er verder ook mogelijk is, maar feit blijft dat je je wederom in rare bochten moet wringen.

Wat ik persoonlijk liever zie is een gestandaardizeerde UI container die de HTML kan laten zien zoals een browser, maar waar user-interactie beter is geregeld en afgeschermd. Een backbutton is dan prima als je gewoon zelf voor een implementatie van die knop kan zorgen.

[ Voor 32% gewijzigd door .oisyn op 05-08-2007 18:58 ]

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

zondag 5 augustus 2007 20:01

Acties:

Verwijderd

.oisyn schreef op zondag 05 augustus 2007 @ 18:54:

Wat ik persoonlijk liever zie is een gestandaardizeerde UI container die de HTML kan laten zien zoals een browser, maar waar user-interactie beter is geregeld en afgeschermd. Een backbutton is dan prima als je gewoon zelf voor een implementatie van die knop kan zorgen.

Dat ben ik volledig met je eens, maar dan is het nog steeds een issue van de user agent, en niet van het HTTP protocol. Ik denk trouwens dat je een soort XUL applicaties bedoelt of iets dergelijks?