[Java/JS] Ajax (Direct Web Remoting)

[Cuball]

Ik heb kort eventjes gekeken naar AJAX, meerr in detail de DWR (http://www.getahead.ltd.uk/dwr/) library implementatie (deze heeft zelf ondersteuning om spring beans te gebruiken), en als wat rondneus op de site lijkt met dit in ieder geval wel heel bruikbaar (wel goed de security in oog te houden).


zijn er mensen die hier al wat ervaring mee hebben ? Specifieke problemen ?

[-FoX-]

Het DWR project lijkt me wel redelijk interessant, al is het nog een redelijk jong..
Op JavaWorld - DWR verscheen een paar dagen geleden nog een artikel over DWR. Best wel interessant om eens door te lezen.

Op zich is AJAX wel interessant, maar er komen natuurlijk ook weer een heleboel andere zaken bij kijken, dan bij een applicatie die dit niet gebruikt (bugs, wat bij een timeout, ...).

[aex351]

Er zou een nieuwe taal of een andere type implentatie voor zulke toepassingen moeten komen. Aangezien Ajax niet zo 1 2 3 te maken is.

[Cuball]

aex351 schreef op woensdag 22 juni 2005 @ 22:57:
Er zou een nieuwe taal of een andere type implentatie voor zulke toepassingen moeten komen. Aangezien Ajax niet zo 1 2 3 te maken is.

een nieuwe taal ? hoe bedoel je ?

[crisp]

aex351 schreef op woensdag 22 juni 2005 @ 22:57:
Er zou een nieuwe taal of een andere type implentatie voor zulke toepassingen moeten komen. Aangezien Ajax niet zo 1 2 3 te maken is.

Waar staat die J dan voor?
AJAX is niets meer dan een buzzwoord voor de techniek waarmee je mbv javascript en de xmlHTTPrequest interface 'onderhuids' communiceerd met de server.
Overigens is het niets nieuws; het kon 5 jaar geleden al, en daarvoor waren er ook al soortgelijke mogelijkheden.
De interface zelf is hooguit 10 regels javascript, wat je er verder mee wil doen zal je over het algemeen zelf moeten maken in javascript, of gebruik maken van een 'library' (meestal een verzameling handige functies) zoals DWR.

[ Voor 7% gewijzigd door crisp op 22-06-2005 23:51 ]

[aex351]

crisp schreef op woensdag 22 juni 2005 @ 23:48:
[...]

Waar staat die J dan voor?
AJAX is niets meer dan een buzzwoord voor de techniek waarmee je mbv javascript en de xmlHTTPrequest interface 'onderhuids' communiceerd met de server.
Overigens is het niets nieuws; het kon 5 jaar geleden al, en daarvoor waren er ook al soortgelijke mogelijkheden.
De interface zelf is hooguit 10 regels javascript, wat je er verder mee wil doen zal je over het algemeen zelf moeten maken in javascript, of gebruik maken van een 'library' (meestal een verzameling handige functies) zoals DWR.

Ja het is bijna niet te doen zonder een libary, want met alleen 10 regels code ben je nergens.
Ajax zoals we die nu kennen is gewoon niet efficient, iets wat niet te ontkennen valt. Leuk om er mee te rotzooien maar daar houd het toch echt op.

Het begint nu al wel iets populairder te worden omdat er meer aandacht aan word besteed. Maar zoals je zei het kon 5 jaar terug al, dit geeft al aan waarom het toen al niet poplair was.

Een efficientere manier zal dus moeten worden ontwikkeld

edit: naast drw heb je ook nog jspan. (en waarschijnlijk nog enkele waarvan ik atm de naam niet weet

[ Voor 9% gewijzigd door aex351 op 23-06-2005 01:18 ]

[crisp]

aex351 schreef op donderdag 23 juni 2005 @ 01:15:
[...]

Ja het is bijna niet te doen zonder een libary, want met alleen 10 regels code ben je nergens.
Ajax zoals we die nu kennen is gewoon niet efficient, iets wat niet te ontkennen valt. Leuk om er mee te rotzooien maar daar houd het toch echt op.

Het begint nu al wel iets populairder te worden omdat er meer aandacht aan word besteed. Maar zoals je zei het kon 5 jaar terug al, dit geeft al aan waarom het toen al niet poplair was.

Een efficientere manier zal dus moeten worden ontwikkeld

edit: naast drw heb je ook nog jspan. (en waarschijnlijk nog enkele waarvan ik atm de naam niet weet

Nee, het is een gemis aan (basis)kennis op het gebied van voornamelijk clientside scripting. Serverside programmeurs zijn verwend met IDE's en frameworks waarmee door een zekere mate van abstractie de onderliggende techniek verborgen blijft. Dat zie je met name bij .NET en JAVA programmeurs.

Mijn GoT tracker is geloof ik al 4 jaar oud en gebruikt al Ajax. Daarnaast heb ik over de jaren al talloze examples gemaakt, al dan niet Ajax-based, waarmee onderhuids serverdata opgevraagd kon worden (bijvoorbeeld voor dynamische selects). Ajax is pas echt in de picture gekomen door Google Suggest (hoewel dat niet echt Ajax is geloof ik), maar het was er allang alleen had het nog geen naam en waren serverside programmeurs niet geinteresseerd (ik denk door een aangeboren angst voor clientside technieken).

Nee, er zijn niet echt IDE's of frameworks voor javascript, dus je zult weer echt moeten (leren) programmeren

Overigens zit DRW qua javascript best leuk in elkaar; de gemiddelde kwaliteit wb javascript op het net is vaak om te huilen zo slecht...

[ Voor 9% gewijzigd door crisp op 23-06-2005 01:44 ]

[gvdh81]

AJAX staat voor "Asynchronous JavaScript and XML" Het is een taal "uitgevonden" door de mannen van BackBase.

@crisp: Deze librarys zijn pas sinds kort voor het publiek (na registratie) te downloaden. AJAX is een compleet nieuwe manier van scripten. Voor examples van wat het kan, kun je hier terecht.

[ Voor 17% gewijzigd door gvdh81 op 23-06-2005 09:47 ]

[crisp]

gvdh81 schreef op donderdag 23 juni 2005 @ 09:43:
AJAX staat voor "Asynchronous JavaScript and XML" Het is een taal "uitgevonden" door de mannen van BackBase.

Taal? Het is gewoon een (brakke) naam voor een al lang bestaande techniek. En ik denk niet dat het door de mannen van BackBase is uitgevonden...

@crisp: Deze librarys zijn pas sinds kort voor het publiek (na registratie) te downloaden. AJAX is een compleet nieuwe manier van scripten. Voor examples van wat het kan, kun je hier terecht.

Een nieuwe manier van scripten? Zoals ik al eerder zei: ik gebruikte 4 jaar geleden al xmlHTTP, en DOM scripting is ook niet nieuw...
Misschien dat het voor jou allemaal nieuw is, maar voor mensen die al langer met javascript werken zeker niet...

[ Voor 8% gewijzigd door crisp op 23-06-2005 10:19 ]

[Michali]

AJAX is toch gewoon een verzamel naam voor een paar technologieen? Dan vooral het in combinatie gebruikmaken van XMLHttpRequest, DOM, XML, XSLT en Javascript. Daar is imo niets nieuws aan, en hoe je dit alles in javascript gebruikt ook niet. Je kunt het op een structurele manier oplossen, of wat object georienteerder, maar het blijft gewoon plain javascript.

[Verwijderd]

Even om de nodige desinformatie uit de weg te ruimen:

Ajax is gewoon een naam die door Jesse Warden van AdaptivePath (een partij die praat over usability op het web) verzonnen is voor een combinatie van technieken, die voor de mensen die al wel bekend waren met Javascript al veel langer aanwezig waren. Waarom hij dit verzonnen heeft, imo is het meer een viral campagne geweest voor AdaptivePath, maar dat terzijde.

Ajax is niets meer en niets minder als een naam die wordt gegeven aan de mogelijkheid om zonder een reload van de pagina met behulp van het XMlHttpRequest object informatie uit te wisselen met de server. Door de gigantische onwetendheid van veel programmeurs met betrekking tot Javascript werden ze losgeschud door de mogelijkheden die oa Google liet zien. Zoals Crisp al aangaf, we gebruikten het al jaren voor Google groot werd maar het had een gevestigde naam nodig op het web om mensen eindelijk aware te maken van de sterk verbeterde mogelijkheden van Javascript.

Ajax is dus gebaseerd op
A = Asynchronous; je requests worden simultaan met lopende bewerkingen in de browser uitgevoerd (synchroon, je browser wacht met verdere bewerkingen totdat de data goed en wel binnen is)
JA = Javascript And
X = XML, en je ziet dat toch de meeste huidige applicaties zich niet beperken tot informatie uitwisseling via XML, maar direct de presentatie laag via innerHTML naar de browser zenden. Het is snel maar je gaat dan wel je presentatielaag op zowel server, als clientside vlak bepalen. Imo niet mijn voorkeur.

Wat ik echter jammer vind, is dat het in de hele hype eigenlijk niet draait op de techniek, maar om de toepassingen en resultaten ervan. Echter men focussed teveel op techniek. Men wil de techniek toepassen om de techniek, en niet om de resultaten. Waar het mijnziens om moet gaan is het leveren van een hele nieuwe methodiek in de ontwikkeling van web applicaties, en dat deze methodiek inhoud dat je met behulp van het zgn. Ajax de gebruikers een betere usability kan bieden, en dat de gebruikers de applicatie vriendelijker kunnen gebruiken. Javascript biedt de mogelijkheid, en zeker met de huidige processor kracht bij clients, om op zowel visueel vlak, als op vlak van data entry de gebruiker in zoverre te ondersteunen en te adviseren in een web applicatie dat er een, zoals ze dat noemen, better user experience ontstaat.

Voor een product wat in zijn doelgroep dagelijks ontzettend veel gebruik wordt, is die better user experience erg belangrijk. Het maakt of breekt je product. Er zijn reeds enkele grote namen die dit ook zien en hun producten er momenteel op aanpassen, of al hebben aangepast. Het web heeft namelijk qua applicaties naast de nadelen ook enkele hele grote voordelen, en ik verwacht dat we de komende jaren steeds meer applicaties op het web zien verschijnen.

[RobIII]

AJAX:

code:

function retrieveURL(sUrl) {
    var oReq;
    if (window.XMLHttpRequest) { // Non-IE browsers
        oReq = new XMLHttpRequest();
        try {
            oReq.open("GET", sUrl, false);
        } catch (e) {
            alert(e);
        }
        oReq.send(null);
        return oReq.responseText;
    } else if (window.ActiveXObject) { // IE
        oReq = new ActiveXObject("Microsoft.XMLHTTP");
        if (oReq) {
            oReq.open("GET", sUrl, false);
            oReq.send();
            return oReq.responseText;
        }
    }
}

Voila. That's all there is to it.

Dit stukje code gebruik je om onderhuids een XML document (of andere "tekst" for that matter) op te halen. De rest is een kwestie van tegen deze functie aan schoppen.
Om bijvoorbeeld een DIV (met Id "myDiv") te vullen met bepaalde content:

code:

function getDivHTML(sID, sURL) {
    var oDiv = document.getElementById(sID);
    if (oDiv) { 
        var oRes = retrieveURL(sURL);
        oDiv.innerHTML = oRes;
    }
}

getDivHTML('myDiv','http://www.somedomain.com/somepage.php?action=getmyresults');

Als je een beetje thuis bent in js heb je écht geen libraries nodig...

[ Voor 58% gewijzigd door RobIII op 23-06-2005 11:28 ]

[Verwijderd]

Idee een 10, uitvoer een 3.

Ik vind dit echt pure workarounds om een statefull protocol te ontwikkelen. Het is leuk om aan te kaarten dat een statefull protocol in sommige situaties wenselijk is maar daar is ook alles mee gezegd. Tijd voor een goede nieuwe standaard die, als het even kan, niet voort borduurt op dat adtandse onderdoordachte html en js...

[Verwijderd]

Verwijderd schreef op donderdag 23 juni 2005 @ 11:15:
Idee een 10, uitvoer een 3.

Ik vind dit echt pure workarounds om een statefull protocol te ontwikkelen. Het is leuk om aan te kaarten dat een statefull protocol in sommige situaties wenselijk is maar daar is ook alles mee gezegd. Tijd voor een goede nieuwe standaard die, als het even kan, niet voort borduurt op dat adtandse onderdoordachte html en js...

Hoezo workarounds, dit is gewoon een ingebouwd mechanisme om xml communicatie te gebruiken. Het protocol is hetzelfde als dat je via webservices in een backend informatie binnentrekt of verstuurd. Ik volg je punt niet, wat wil je ermee bereiken met een nieuw protocol? Wat ik me kan voorstellen is dat je zegt, die 2 http connecties simultaan zijn te weinig, maar dan nog zit je met vraagstukken over het voorkomen van attacks. Men moet niet gaan over architecten, er schijnt vooral in de Java wereld een enorme drive te zijn om te doen aan overarchitecting, om zowat alles over te erven terwijl het meestal met composition kan. Het is simpel, en het moet imo ook simpel blijven. De XML communicatie is maar 1% van het geheel, het echte werk komt daarna in je presentatielaag als je echt single paged interfaces wilt gaan creeren.

[ Voor 20% gewijzigd door Verwijderd op 23-06-2005 11:51 ]

[Verwijderd]

ik snap niet waarom je de hele tijd de hele "Java wereld" erbij haalt?
Het feit blijft dat je controllers moet overpompen en zodoende pas iets kan. Functionaliteit die niet gespecificeerd is en dus met deze workaround wordt opgelost.

[Verwijderd]

Verwijderd schreef op donderdag 23 juni 2005 @ 11:53:
ik snap niet waarom je de hele tijd de hele "Java wereld" erbij haalt?
Het feit blijft dat je controllers moet overpompen en zodoende pas iets kan. Functionaliteit die niet gespecificeerd is en dus met deze workaround wordt opgelost.

Je ziet vooral bij de Java kant op de lists dat men graag van Ajax gebruikt maakt, maar dat men maar blijft doorzagen over de meest schone/correcte/verantwoorde manier en daar komt geen einde aan. Ze kunnen maar moeilijk omgaan met de huidige implementatie en moeten kosten wat kost met allerlei nieuwe implementaties en (vaak lekkende) wrappers komen om hun doel te bereiken. Daar doelde ik meer op Dat geld natuurlijk niet voor de gehele club, dat heb ik ook niet gezegd, maar je ziet de discussies veel daarop uitlopen.

Het feit blijft dat je controllers moet overpompen en zodoende pas iets kan. Functionaliteit die niet gespecificeerd is en dus met deze workaround wordt opgelost.

Maargoed, dat is een onderdeel van het web. Het is ook de vraag of je vanuit een controller wilt gaan werken. Het is aan jou om te bepalen of je een opzet kunt verzinnen/aandurft waarbij een gedeelte van de business logic bij de client terecht komt. Je komt anders nooit tot een fat client model, waar dit in principe naar toe gaat. Het ligt eerder bij het doorbreken van een gevestigde manier van werken, dan bij het toepassen ervan. Het is voor veel mensen nog "eng" om een deel van de business logic bij de client neer te leggen. Het hangt ook geheel van jezelf af hoe ver je daarin wilt gaan, en dan moet je gewoon de voor en nadelen tegen elkaar gaan opwegen. Ik denk dat voor de meeste mensen de nadelen momenteel nog groter zijn dan de voordelen, met name ontwikkeltijd en kennis.

De mogelijkheden echter die zijn er wel, je moet er alleen wel mee kunnen omgaan.

[ Voor 16% gewijzigd door Verwijderd op 23-06-2005 12:11 ]

[Verwijderd]

Wanneer ik het nodig zou hebben zou ik het gebruiken, ik heb het nog niet nodig. Verder komt je veel sneller in de regionen van concrete applicaties (dus niet web driven) als je een statefull verbinding nodig hebt. Ik zie dit dus domweg als een tussenstation en misschien een logische eerste keuze, maar verdwijnen zal het ook net zo hard weer.

[Verwijderd]

Wie weet, maar voorlopig zijn er een aantal grote multinationals die er wel een grote toekomst voor zien en er enorm veel geld in investeren, die zijn ook niet op hun achterhoofd gevallen

Een statefull verbinding, dat is een vaak gebruikt argument, maar is maar in een beperkt aantal situaties vereist.

[Verwijderd]

Hoe groter het bedrijf, hoe ouder de techniek. Grote multinationals is verre van een indicatie dat we met een vooruitstrevend product of techniek te maken hebben.

[Verwijderd]

gvdh81 schreef op donderdag 23 juni 2005 @ 09:43:
AJAX staat voor "Asynchronous JavaScript and XML" Het is een taal "uitgevonden" door de mannen van BackBase.

offtopic:
Hohoho, bij Backbase hebben we AJAX zeker niet 'uitgevonden'. Zoals crisp al zei: het is gewoon een nieuw woordje voor een oude combinatie van technieken. De Backbase Presentation Client maakt inderdaad wel gebruik van AJAX technieken maar slechts als één van de basis-ingredienten voor een veel uitgebreider framework. Voor een uitgebreide vergelijking van Backbase en AJAX refereer ik naar Ajax & Beyond (PDF).

[Verwijderd]

Verwijderd schreef op donderdag 23 juni 2005 @ 13:11:
Hoe groter het bedrijf, hoe ouder de techniek. Grote multinationals is verre van een indicatie dat we met een vooruitstrevend product of techniek te maken hebben.

Maar wat probeer je nu te zeggen? Ik bedoel, een SAP bouwt dit niet in haar product voor de grap, en al helemaal niet omdat ze er weinig vertrouwen in hebben. Die risico's kan SAP niet nemen in haar markt. Ik zie ook niet in waarom het voortuitstrevend moet zijn, dat is het niet namelijk, het is gewoon een andere visie met iets wat al jaren beschikbaar is. Dat er nadelen aan kleven, absoluut. Voordelen, wellicht. Maar zoals ik al eerder aangaf, je moet gewoon goed bekijken met geinformeerde personen wat de voordelen en nadelen voor je product zijn.

Dat de mogelijkheden er zijn om een beter product neer te zetten voor de eindgebruiker, absoluut.

Dat je anders moet gaan kijken naar zaken, absoluut. Een voorbeeld hiervan is een collega die terecht de opmerking maakte over een grid in een web applicatie. Als gebruiker A en B een grid openen in hun web browser, en gebruiker A verwijderd een record, dan staat die er bij gebruik B nog steeds in terwijl hij niet meer bestaat. Dat is zeker het geval, maar niets anders dan hoe we vandaag tegen data aankijken. Ajax biedt wat dat betreft zelfs meer voordelen, namelijk het periodiek pollen of een record nog bestaat.

Zelfs zonder lijkt het me niet een issue, want je controleerd gewoon of het record nog bestaat, en zoniet dan geef je de gebruiker de melding dat een andere persoon het record reeds verwijderd had. Geen enkel verschil met hoe vandaag de dag met dergelijke concurrency wordt omgegaan in web applicaties. Dat is nu net het nadeel van een web applicatie. Het is echter de vraag of dit opweegt tegen de velen voordelen van een web applicatie mbt deployment, configuraties, distributie, onderhoud en asp modellen. Dat hangt van je product af.

[ Voor 38% gewijzigd door Verwijderd op 23-06-2005 13:38 ]

[aex351]

daarom, zoals ik al zei. Er moet gewoon een alternatieve manier komen die een gelijksoortige manier van data overdracht moet kunnen bewerkstellingen ipv zo moeilijk te doen.

[Verwijderd]

aex351 schreef op donderdag 23 juni 2005 @ 23:34:
daarom, zoals ik al zei. Er moet gewoon een alternatieve manier komen die een gelijksoortige manier van data overdracht moet kunnen bewerkstellingen ipv zo moeilijk te doen.

Maar wat verwacht je dan, wat is er moeilijk, wat is er niet goed met de huidige aanpak? Wat mis je dat er nu niet beschikbaar is? Net zoals Crisp al aangaf, het mist bij de meesten gewoon aan kennis, en het toepassen ervan wordt zwaar onderschat. Wil je vanuit een framework met standaard builtin componenten dan is Backbase gewoon het product wat je zoekt, period.

Wil je met het handje je eigen complete interfaces in elkaar knutselen (alla Gmail, single paged interfaces) dan kan ik je nu al zeggen dat het voor iemand zonder op zijn minst bovengemiddelde ervaring met zowel markup, browser kennis, css en javascript een totaal niet haalbare zaak is op de korte termijn. Het klinkt misschien zwaar arrogant maar in dit geval weet ik waar ik over praat, en er zal geen enkele doorgewinterde web developer zijn, die werkzaam is op dit gebied, het daarmee oneens zijn.

Wil je gewoon simpel, een form posten met xmlHttpRequest, of kleine dynamische events uitvoeren in een statische interface dan is de huidige xmlHttpRequest specificatie echt supersimpel, en het vereist je een paar regels code.

[ Voor 3% gewijzigd door Verwijderd op 23-06-2005 23:52 ]

[aex351]

neem voor de grap eens de broncode door op backbase.nl , en vertel me dan waarom ik fout zit.

[Verwijderd]

aex351 schreef op donderdag 23 juni 2005 @ 23:52:
neem voor de grap eens de broncode door op backbase.nl , en vertel me dan waarom ik fout zit.

Je bent nu appels en peren aan het vergelijken. Backbase past hier gewoon hun eigen markup language toe, dat is totaal niet relevant itt het Ajax verhaal

En voor de rest, ik zie niet wat er fout moet zijn aan de broncode? Sterker nog, deze is gestructureerder dan menig website van dat kaliber.

[ Voor 17% gewijzigd door Verwijderd op 23-06-2005 23:54 ]

[aex351]

Verwijderd schreef op donderdag 23 juni 2005 @ 23:53:
[...]

Je bent nu appels en peren aan het vergelijken. Backbase past hier gewoon hun eigen markup language toe, dat is totaal niet relevant itt het Ajax verhaal

En voor de rest, ik zie niet wat er fout moet zijn aan de broncode? Sterker nog, deze is gestructureerder dan menig website van dat kaliber.

Nee hoor Backbase is een website die Ajax in overvloede gebruikt. Als je de code eens goed bekijkt, zie je dat totaal een onoverzichtelijke zooi is dat de principe van html tags omver gooit door er via javascript eromheen te bouwen.

want laten we niet vergeten, ajax is gewoon een manier op de websites zoals we die nu kennen meer richting de pc apps qua functies te halen. Doormiddel van er compleet omheen te bouwen

[ Voor 14% gewijzigd door aex351 op 23-06-2005 23:58 ]

[crisp]

aex351 schreef op donderdag 23 juni 2005 @ 23:57:
[...]

Nee hoor Backbase is een website die Ajax in overvloede gebruikt. Als je de code eens goed bekijkt, zie je dat totaal een onoverzichtelijke zooi is dat de principe van html tags omver gooit door er via javascript eromheen te bouwen.

Het lijkt me nogal logisch dat als je een dergelijk framework aanbiedt, je je site ook als kapstok gebruikt om de mogelijkheden live te laten zien - ook al is dat eigenlijk overdone en niet noodzakelijk.
Niet echt een argument dus...

want laten we niet vergeten, ajax is gewoon een manier op de websites zoals we die nu kennen meer richting de pc apps qua functies te halen. Doormiddel van er compleet omheen te bouwen

Nee, dat maak jij er van. Ajax is een bepaalde techniek die je voor allerlei zaken zou kunnen gebruiken; het zegt niets over hoe je het moet gebruiken.
Rule nummer 1 is nog altijd: gebruik het als enhancement, niet als vervanger van. En ja, dan wordt het een soort van extra layer, maar ik zie het probleem daar niet van....

[aex351]

Het is gewoon een feit dat webdesigners maar ook gebruikers steeds meer eisen van een website, en ajax zoals ik al zei is een voorlopig middel is om dat iets extra's te bieden voor die overgang, maar gewoon niet efficient is . Daar valt weinig over te betwijfelen.

dus zoals ik al zei, web applicatie groeien steeds meer naar pc applicaties toe en omgekeerd

[ Voor 25% gewijzigd door aex351 op 24-06-2005 00:32 ]

[crisp]

Wat is er dan niet efficient? Hoe zou het dan moeten?

[aex351]

crisp schreef op vrijdag 24 juni 2005 @ 00:35:
Wat is er dan niet efficient? Hoe zou het dan moeten?

Een optie zou zijn een taal ontwikkelen die ervoor bedoelt is, maar past binnen de html zoals we die nu kennen. Dus het Html in feite uitbreiden en niet er compleet omheen te hoeven bouwen zoals wat nu het geval is.

[ Voor 5% gewijzigd door aex351 op 24-06-2005 00:43 ]

[crisp]

aex351 schreef op vrijdag 24 juni 2005 @ 00:42:
[...]

Een optie zou zijn een taal ontwikkelen die ervoor bedoelt is, maar past binnen de html zoals we die nu kennen. Dus het Html in feite uitbreiden en niet er compleet omheen te hoeven bouwen zoals wat nu het geval is.

Daar is HTML dus niet voor bedoelt. HTML is een presentational layer, behavior hoort daar niet in thuis. Ik zie nog steeds niet waarom javascript niet geschikt zou zijn...

[aex351]

crisp schreef op vrijdag 24 juni 2005 @ 00:48:
[...]

Daar is HTML dus niet voor bedoelt. HTML is een presentational layer, behavior hoort daar niet in thuis. Ik zie nog steeds niet waarom javascript niet geschikt zou zijn...

Ik zie nog steeds niet waarom juist javascript wel goed zou zijn om web applicaties dichter bij de pc applicaties te brengen. Ik geef je voorbeelden waarom de huidige manier niet efficient is maar blijkbaar ben je er niet mee eens, maar je geeft niet aan waarom javascript nou zo efficient is.

Terwijl er tal van artikelen zijn die mijn standpunt volledig ondersteunen.

[Verwijderd]

Kun je die linkjes eens plaatsen dan? En kom niet aan met een Jacob Nielsen want dan ga ik gillen.

Ik volg zowiezo nog steeds niet wat je specifiek verwacht. Zoals al meerdere keren gevraagd, wat mis je, wat is er niet goed, waarom mis je het, waarom is het niet goed. Dat zijn toch redelijk basis vragen die je nog niet hebt beantwoord, je geeft alleen aan dat er een nieuwe taal moeten komen als extensie erop. Maar wat ik dus wil weten, is het waarom? Normaal doe je dat als iets onvoldoende is of problemen oplevert, dat is bij de huidige technieken geen probleem.

[crisp]

aex351 schreef op vrijdag 24 juni 2005 @ 00:54:
[...]

Ik zie nog steeds niet waarom juist javascript wel goed zou zijn om web applicaties dichter bij de pc applicaties te brengen.

Javascript is een volwassen programmeertaal en heeft zo'n beetje alle features die je je maar kan wensen, daar ligt het volgens mij niet aan. Ook biedt javascript genoeg mogelijkheden qua interactie met je HTML (DOM). Misschien vind je HTML niet zo praktisch om een application-like GUI mee te bouwen, maar zoals ik al zei: dat is de presentatielaag en staat los van de logica en van Ajax als techniek.

Ik geef je voorbeelden waarom de huidige manier niet efficient is maar blijkbaar ben je er niet mee eens, maar je geeft niet aan waarom javascript nou zo efficient is.

Ik heb nog niet echt voorbeelden met argumentatie van je gezien. Je wijst naar de site van backbase en roept: 'kijk, inefficient', maar je zegt niet wat er dan in jouw ogen zo inefficient is en waarom.

Terwijl er tal van artikelen zijn die mijn standpunt volledig ondersteunen.

linkjes?

[ Voor 3% gewijzigd door crisp op 24-06-2005 09:16 ]

[gvdh81]

crisp schreef op donderdag 23 juni 2005 @ 10:18:
[...]

Taal? Het is gewoon een (brakke) naam voor een al lang bestaande techniek. En ik denk niet dat het door de mannen van BackBase is uitgevonden...

[...]

Een nieuwe manier van scripten? Zoals ik al eerder zei: ik gebruikte 4 jaar geleden al xmlHTTP, en DOM scripting is ook niet nieuw...
Misschien dat het voor jou allemaal nieuw is, maar voor mensen die al langer met javascript werken zeker niet...

uhm.. AJAX is idd niet nieuw, maar als je op de site van backbase kijkt (en dan naar de demos) is hun implementatie (taal) wel nieuw. Dat wilde ik ff zeggen...

[crisp]

gvdh81 schreef op vrijdag 24 juni 2005 @ 09:54:
[...]


uhm.. AJAX is idd niet nieuw, maar als je op de site van backbase kijkt (en dan naar de demos) is hun implementatie (taal) wel nieuw. Dat wilde ik ff zeggen...

Ja, ze hebben een leuk framework gebouwd waarmee je 'out of the box' leuke dingen kan doen. Ik heb nooit behoefte gehad aan een dergelijk framework, deels ook doordat ik me wel comfortabel voel met javascript, DOM en HTML

[Verwijderd]

gvdh81 schreef op vrijdag 24 juni 2005 @ 09:54:
[...]


uhm.. AJAX is idd niet nieuw, maar als je op de site van backbase kijkt (en dan naar de demos) is hun implementatie (taal) wel nieuw. Dat wilde ik ff zeggen...

Maar zoals ik al eerder aangaf, dat is een geheel eigen implementatie van Backbase die totaal los staat van het Ajax verhaal. Backbase heeft een eigen implementatie gemaakt die, die tags die je ziet transformeert naar full blown UI elementen. Dat heeft dus echt compleet 0,0 met Ajax te maken

[Not Pingu]

crisp schreef op vrijdag 24 juni 2005 @ 09:15:
[...]

Javascript is een volwassen programmeertaal en heeft zo'n beetje alle features die je je maar kan wensen, daar ligt het volgens mij niet aan. Ook biedt javascript genoeg mogelijkheden qua interactie met je HTML (DOM). Misschien vind je HTML niet zo praktisch om een application-like GUI mee te bouwen, maar zoals ik al zei: dat is de presentatielaag en staat los van de logica en van Ajax als techniek.

Hierbij wil ik wel even aantekenen dat DHTML door het bedrijfsleven wel wordt gezien als een techniek waarmee je op korte termijn een website kunt 'upgraden' naar een rijkere interface, maar dat het op de lange termijn wellicht niet de beste oplossing is voor het maken van internetapplicaties.

Punt is gewoon dat je binnen HTML met het paginamodel werkt en dat HTML weliswaar heel geschikt is voor het structureren en overbrengen van informatie, maar dat het maken van webapplicaties in DHTML vaak meer moeite is dan het waard is.

[crisp]

Gunp01nt schreef op vrijdag 24 juni 2005 @ 10:40:
[...]


Hierbij wil ik wel even aantekenen dat DHTML door het bedrijfsleven wel wordt gezien als een techniek waarmee je op korte termijn een website kunt 'upgraden' naar een rijkere interface, maar dat het op de lange termijn wellicht niet de beste oplossing is voor het maken van internetapplicaties.

Punt is gewoon dat je binnen HTML met het paginamodel werkt en dat HTML weliswaar heel geschikt is voor het structureren en overbrengen van informatie, maar dat het maken van webapplicaties in DHTML vaak meer moeite is dan het waard is.

Dat ben ik ook met je eens, maar dat is dus een probleem met de presentatielaag. Feit is wel dat we daar voorlopig gewoon aan vast zitten, en zelfs al komen er alternatieven (Avalon bijvoorbeeld) dan is javascript in mijn ogen nog steeds geschikt om het aan te sturen.

[Verwijderd]

Avalon is geen alternatief, al wil men je doen geloven van wel. Avalon heeft daar de potentie niet voor qua bereikbaarheid. Avalon gaat dezelfde kant op als ClickOnce, dat is ook al geen succes.

Dare Obasanjo (RSS Bandit ontwikkelaar) heeft er een posting aan gewijd, hij snapt het wel;

http://www.25hoursaday.co...e1-4187-bb16-bffe472acdb4

[ Voor 4% gewijzigd door Verwijderd op 25-06-2005 23:45 ]

[Not Pingu]

Is het niet een beetje te vroeg om al te beweren dat je kunt zeggen of Avalon wel of niet iets wordt? Het hangt allemaal af van de marktpenetratie van longhorn, en in mindere mate de aanwezigheid van Avalon plugins voor Windows XP. Als je ziet hoe snel Windows XP ingeburgerd raakte, nog geen 4 jaar geleden, dan zou het met Longhorn ook best wel eens snel kunnen gaan.

Als je het over bereikbaarheid hebt, moet je niet vergeten dat XMLHTTP het ook maar in twee browsers doet: IE en FF. Binnen die groep is IE nog steeds oppermachtig met 90% marktaandeel. Oftewel 90% van de bereikbaarheid komt door 1 browser, en dat vormt meteen de reden waarom het aangedurfd wordt om een general use-site zoals Google Maps gebruik te laten maken van AJAX: er wordt geacht voldoende ondersteuning voor te zijn.

Het zal goed een jaar of 4 duren voordat Longhorn de kritieke massa bereikt heeft, maar XMLHTTP is dan ook al 4+ jaar beschikbaar en toepassingen ervan zijn pas recentelijk verschenen.

[crisp]

Verwijderd schreef op zaterdag 25 juni 2005 @ 23:44:
Avalon is geen alternatief, al wil men je doen geloven van wel. Avalon heeft daar de potentie niet voor qua bereikbaarheid. Avalon gaat dezelfde kant op als ClickOnce, dat is ook al geen succes.

Avalon was ook maar gewoon een voorbeeld dat in me op kwam. Bottomline is dat Ajax nu beschikbaar is en er voldoende ondersteuning voor is aan de client-side; hoe dat gaat worden met Avalon (dan zal de techniek dus crossbrowser/crossplatform beschikbaar moeten komen, en dat is natuurlijk al een groot vraagteken) is nog maar afwachten.

Kortom: dit is gewoon het best haalbare met de beschikbare tools/technieken en ondersteuning ervan.
Je ziet nu dus wel al complete frameworks om Ajax heen beschikbaar komen die in ieder geval de programmeurs al een stuk tegemoet komen (en dus minder in-depth kennis nodig hebben), maar toch zal je een zeker inzicht moeten hebben in deze techniek en clientside techniek in het algemeen om de mogelijkheden (en beperkingen en onmogelijkheden) ervan te kunnen inzien, en het goed te kunnen toepassen.

[aex351]

javascript is ook geen mooie taal, zo ervaar ik dat. Misschien voor de mensen die Java kennen zal het wel iets makkelijker zijn.

[Johnny]

Gunp01nt schreef op zaterdag 25 juni 2005 @ 23:58:
Als je het over bereikbaarheid hebt, moet je niet vergeten dat XMLHTTP het ook maar in twee browsers doet: IE en FF. Binnen die groep is IE nog steeds oppermachtig met 90% marktaandeel. Oftewel 90% van de bereikbaarheid komt door 1 browser, en dat vormt meteen de reden waarom het aangedurfd wordt om een general use-site zoals Google Maps gebruik te laten maken van AJAX: er wordt geacht voldoende ondersteuning voor te zijn.

En Safari, Konquerer, Opera, Camino, Netscape en Mozilla Suite, allemaal niet pas sinds gisteren maar al maanden of zelf jaren lang.

[crisp]

aex351 schreef op zondag 26 juni 2005 @ 00:22:
javascript is ook geen mooie taal, zo ervaar ik dat. Misschien voor de mensen die Java kennen zal het wel iets makkelijker zijn.

Dat is een mening die ik dus niet deel; er zijn talen die ik ook niet 'mooi' vind
Gezien je 2e zin denk ik dat dat dus meerendeels ook te maken heeft met gebrek aan kennis op dat vlak (dat is overigens niet negatief bedoeld want kennis kan je vergaren door ermee te werken).

Johnny schreef op zondag 26 juni 2005 @ 00:27:
[...]


En Safari, Konquerer, Opera, Camino, Netscape en Mozilla Suite, allemaal niet pas sinds gisteren maar al maanden of zelf jaren lang.

Opera pas sinds versie 8 (dan praat je over een paar maanden vwb de officiele release), en Opera 8 heeft nogal last van wat 'kinderziektes' - ook op het gebied van XMLHTTP. De implementatie daarvan is ook nog niet volledig.

[ Voor 57% gewijzigd door crisp op 26-06-2005 00:36 ]

[Verwijderd]

aex351 schreef op zondag 26 juni 2005 @ 00:22:
javascript is ook geen mooie taal, zo ervaar ik dat. Misschien voor de mensen die Java kennen zal het wel iets makkelijker zijn.

Javascript heeft zeker haar eigenaardigheden, net zoals elke andere taal. Er is geen perfect taal. Echter, de diversiteit, de kracht en de mogelijkheden van de taal vind ik persoonlijk enorm, maar dat merk je pas echt als je ermee aan de slag gaat.

[ Voor 29% gewijzigd door Verwijderd op 26-06-2005 00:51 ]

[flowerp]

aex351 schreef op vrijdag 24 juni 2005 @ 00:42:
[...]
Een optie zou zijn een taal ontwikkelen die ervoor bedoelt is, maar past binnen de html zoals we die nu kennen. Dus het Html in feite uitbreiden en niet er compleet omheen te hoeven bouwen zoals wat nu het geval is.

Ik weet niet of ik je 100% begrijp, maar bedoel je nu dat je een page author ajax wilt laten gebruiken zonder haar bloot te stellen aan javascript en dom programmering? M.a.w. dat ze alleen tags hoeft te gebruiken?

Als dat is wat je bedoeld dat zou je eens naar de combinatie van JSF en Ajax kunnen kijken. Ed Burns (spec lead JSF) heeft daar vorige maand wat artikelen over geschreven.

Zie bijvoorbeeld: https://bpcatalog.dev.java.net/nonav/ajax/progress-bar-jsf/
en voor een overzicht van de techniek https://bpcatalog.dev.java.net/ajax/jsf-ajax/

Op deze manier kan een page author een autocomplete input field of een progress-bar (of wat voor component dan ook), op een page neer zetten door alleen een simpele tag te zetten. Uit bovengenoemde links quote ik:

HTML:

 <ajaxTags:completionField 
     size="40" id="cityField" 
     completionMethod="#{AutoCompleteTextfield.completeCity}" 
     value="#{SessionBean.city}" required="true"
 />

Deze tag kan dan gewoon neergezet worden op plekken waar anders een normaal input field zou komen, en kan gewoon met een form verstuurd worden.

Het voordeel in verhouding tot bare ajax is dat je een duidelijke scheiding maakt tussen je componenten schrijver, je business logica mensen, en je page authors. (waarbij dit ook rollen kunnen zijn van dezelfde persoon).

Mensen die javascript goed beheersen zullen in eerste instantie afvragen waarom dit nodig is. Nou, voornamelijk ivm onderhoudbaarheid en uitbreidbaarheid. Ik heb nu 2 keer in de praktijk gezien dat een hele grote web applicatie waar een grote groep van mensen aan werkte of gewerkt had, compleet niet meer beheersbaar was. In 1 geval was dat omdat men in een J2EE applicatie alle business, controller, en presentatie logica dwars door elkaar heen had gezet op JSP pagina's, en daar waren er dan 100'en van. Er bestonden ik weet niet hoeveel 'leuke' functies op afzonderlijke pagina's die telkens weer enorm pagina specificiek waren. Bijna identieke functies werden telkens overal geen gecopy-paste en ge-hacked om op een andere pagina te werken.

De grap was dat in het begin er programmeurs waren die dit juist aanmoedigde. Er werd gezegd dat je niet moest over-architecten en dat je juist snelle en simpele technieken moest gebruiken. Dat ging een jaartje of 2 goed. Na 4 jaar ging iedereen zwaar depressief aan het werk omdat er geen touw meer aan het geheel was vast te knopen vanwege het ontbreken van structuur en herbruikbare componenten.

Het gevoel leeft dat je met Ajax weer die kant op gaat. Frameworks als Struts of JSF zijn nou net een goede stap in de richting om structuur aan te brengen in grote projecten. Puur Ajax zet controller logic weer op de page, maakt het page specificiek, etc etc met alle ellende vandien.

Slechts een kleine laag om ajax heen (zoals bijvoorbeeld het JSF artikel laat zien), maakt het al velen malen herbruikbaarder.

[Verwijderd]

Het voordeel van DWR is mijns inziens dat je client side je business logica op de server kunt aanspreken. En daarbij moet je natuurlijk wel opletten dat je de logica op de server houdt.

En of je dit nou in een JSP pagina of via DWR doet maakt geen ruk uit voor je beheersbaarheid oid. Het is gewoon een keuze die je maakt. Als je vertrouwen hebt in de browsers en de kennis kun je hele mooie client side applicaties maken. Maar houdt je lagen altijd goed gescheiden zodat je later een andere client kunt maken zonder dat je een regel van je business logica hoeft aan te passen.

Verder is er volgens mij niets mis met het manipuleren van een HTML pagina via Javascript, oftewel DHTML. Sterker nog, als je een beetje goed implementeert kun je allerlei controls die je maakt netjes hergebruiken. Wat via een script (server side) ook wel kan, maar toch ook niet echt netjes is. Nouja, wat is netjes? Ik vind het netjes als het goed OO opgezet is. En met javascript kom je daar in de buurt, helaas niet volledig wat ik erg betreur.

[Verwijderd]

Verwijderd schreef op woensdag 29 juni 2005 @ 15:18:
Verder is er volgens mij niets mis met het manipuleren van een HTML pagina via Javascript, oftewel DHTML.

Helaas is er momenteel wel iets mis mee, en dat is dat bijna elke browser memory leaks heeft bij het manipuleren van de DOM tree. in AJAX situaties belast je de browser kwa javascripting en dom manipulatie veel sterker dan ooit eerder gedaan is. Hierdoor verveelvoudigen de problemen zich.

Dit is een zeer complex probleem. De mannen van backbase zijn hier ook van op de hoogte en geven ook toe dat het ERG complex is. (Zie artikel over backbase op theserverside).

[Verwijderd]

Verwijderd schreef op woensdag 29 juni 2005 @ 15:51:
[...]


Helaas is er momenteel wel iets mis mee, en dat is dat bijna elke browser memory leaks heeft bij het manipuleren van de DOM tree. in AJAX situaties belast je de browser kwa javascripting en dom manipulatie veel sterker dan ooit eerder gedaan is. Hierdoor verveelvoudigen de problemen zich.

Ok, dat is idd zo. Maar ik redeneerde vanuit de theorie als tegenhanger voor de gedachte dat het niet netjes is om via javascript HTML te manipuleren.

Overigens kun je als je zelf een soort finalizers, destroyers (geef het een naam) maakt aardig ver komen. Maar het wordt wel erg complex zeker daar de ene browser wel gevoelig is voor een lek en de ander niet, en als ze dan een keer eenzelfde soort lek hebben mag je het op verschillende manieren oplossen.

Hoe zit het eigenlijk met nieuwste Firefox? Ik kan me niet voorstellen dat ze zo dom zijn om daar geen rekening mee te houden in het ontwerp. Ik bedoel een nieuwe browser, nieuwe opzet dan mag je toch wel verwachten dat ze zoiets aanpakken?

[Verwijderd]

Verwijderd schreef op woensdag 29 juni 2005 @ 15:51:

De problemen verveelvoudigen zich als je je als onervaren persoon direct in het diepe gooit met DHTML. Vaak houden developers geen rekening met memory management situaties, omdat men ervanuitgaat dat Javascript aan managed scripting language is. Memory leaks zijn ook niet een probleem van Ajax, maar een probleem van DHTML in het algemeen. Meer nog, een probleem in IE en niet in DHTML.

Dat zijn niet de zaken die je in de algemene Javascript lectuur vind, en de aandacht die er op het web aan besteed wordt is ook zeer beperkt omdat er maar weinig developers zijn die er zo ver in gaan dat het daadwerkelijk de problemen oplevert. Er zijn echter ook voorbeelden te vinden van zeer complexe applicaties waarbij men wel de memory leaks onder controle heeft.

Met een simpele xmlHttpRequest, de basis van Ajax, zul je niet zo snel de problemen tegenkomen, en al helemaal niet omdat (imo) bad practices als het volledig dumpen van een string met source voor innerHTML toepassing steeds meer worden toegepast. Je hebt dan zowiezo al helemaal geen references met de DOM.

Voor echte rich interfaces met DHTML en Ajax heb je gewoon ontwikkelaars nodig die er in thuis zijn. Er komt zoveel bij kijken qua praktijkervaring in markup/known issues/css specs/javascript/transformaties, en weten waar je op moet letten dat het inderdaad een complexe taak kan worden. Het manipuleren van de DOM tree veroorzaakt niet de leaks, het gebruik van zaken als circular references, anonymous eventhandlers, en embedded functions zorgen voor de lekken ... echter deze lekken kun je voorkomen door netjes je objecten op te ruimen met een dispose method en dat is waar het fout gaat bij het gebruik. Het onderkennen van dispose methodes is de eerste stap naar een stabiele applicatie, en tja dat betekend gewoon ouderwets programmeren.

Betreft de cpu usages, de systemen bij clients hebben tegenwoordig zoveel slapende kracht beschikbaar die je heel goed kunt benutten door een deel van de taken gewoon aan de client over te laten. Zodra je problemen gaat krijgen met performance zal het meestal eerder liggen aan de toegepaste code en architectuur. Javascript is snel, heel snel, maar het heeft helaas nog steeds de stempel die Java ook nog steeds vaak krijgt opgedrukt, dat het traag is omdat het vroeger ook zo was.

Betreft circular references, Microsoft heeft een aantal uitstekende stukken uitleg staan op de MSDN.

[Verwijderd]

Hoe je het ook went of keert: het blijft een hack/workaround om het http protocol statefull te maken. Kom op zeg, pollling, onzinnige belasting. Ik vind het niets meer dan een amateuristische hype, het zal wel weer over waaien.

[Verwijderd]

Verwijderd schreef op donderdag 30 juni 2005 @ 10:58:
Hoe je het ook went of keert: het blijft een hack/workaround om het http protocol statefull te maken. Kom op zeg, pollling, onzinnige belasting. Ik vind het niets meer dan een amateuristische hype, het zal wel weer over waaien.

Daar ben ik het dus echt niet mee eens. Op het moment dat ik een applicatie heeft die bijvoorbeeld een aantal gebruikers instellingen heeft. Dan kan ik nu als de gebruiker die wijzigt gewoon via javascript bijvoorbeeld user.setName() doen en vervolgens user.save(). Voor de gebruiker ziet het er allemaal een stukje beter uit, want anders zou de browser een nieuwe pagina gaan laden.
Kortom de gebruiker heeft niet door (of bijna niet door) dat hij op een website zit. En zoals ik het gebruik doe ik het niet om http statefull te maken. En verder doe ik ook niets aan polling hoor. Ik heb een aparte statefull verbinding via Flash die mijn applicatie (aan de client kant) notified als er iets wijzigt.

[Verwijderd]

Goede uitleg van de Gordijnstok. Iemand die een C++ achtergrond heeft zal het een stuk makkelijker hebben met het bijhouden van z'n eigen memory administratie dan wellicht iemand met een Java achtergrond. Toevallig is het zo dat C++ weinig serverside gebruikt wordt, dus of alle serverside programmeurs deze ervaring hebben is maar de vraag.

Of het zo is weet ik niet, maar was er ook niet de issue dat ook al clean je netjes alles, dat er dan toch nog memory problemen kunnen komen bij -zeer- intensieve dom bewerkingen, simpelweg omdat de browser implementatie zelf ook lekt?

Wat betreft het polling, dat is inderdaad jammer. Je zou liever willen dat de server de client 'onthoudt' en wanneer nodig zelf een stukje data naar de client kan pushen. Aan de ene kant kan dit zowel de server, client als netwerk belasting doen afnemen voor situaties waar veel gepolled wordt en data relatief langzaam veranderd. Aan de andere kant, als veel clients een initiele connect doen (wat dan als een register geldt), maar niet het hele process afwachten, dan zal de server een hele grote queue met callbacks hebben staan waarvan de helft allang niet meer geinteresseerd is in die callback.

(voor rss feeds geldt overigens een zelde soort verhaal)

[Verwijderd]

Verwijderd schreef op donderdag 30 juni 2005 @ 11:54:
Daar ben ik het dus echt niet mee eens. Op het moment dat ik een applicatie heeft die bijvoorbeeld een aantal gebruikers instellingen heeft. Dan kan ik nu als de gebruiker die wijzigt gewoon via javascript bijvoorbeeld user.setName() doen en vervolgens user.save(). Voor de gebruiker ziet het er allemaal een stukje beter uit, want anders zou de browser een nieuwe pagina gaan laden.
Kortom de gebruiker heeft niet door (of bijna niet door) dat hij op een website zit. En zoals ik het gebruik doe ik het niet om http statefull te maken. En verder doe ik ook niets aan polling hoor. Ik heb een aparte statefull verbinding via Flash die mijn applicatie (aan de client kant) notified als er iets wijzigt.

Om maar even lekker arogant te doen, er valt weinig niet mee eens te zijn Het is een hack/workaround, je maakt immers van een stateless protocol een statefull protocol d.m.v. polling. In dit soort gevallen moet je je als ontwikkelaar afvragen of je niet beter af bent met een ouderwetse applicatie (of een applet/flash component)

[Verwijderd]

Verwijderd schreef op donderdag 30 juni 2005 @ 11:55:
Goede uitleg van de Gordijnstok. Iemand die een C++ achtergrond heeft zal het een stuk makkelijker hebben met het bijhouden van z'n eigen memory administratie dan wellicht iemand met een Java achtergrond. Toevallig is het zo dat C++ weinig serverside gebruikt wordt, dus of alle serverside programmeurs deze ervaring hebben is maar de vraag.

Das geen ervaring, dat is een keuze. Je moet als ontwikkelaar bezig zijn met het oplossen van cases en het liefst zo min mogelijk met de taal en haar aardig en eigenaardigheden.

[Verwijderd]

Verwijderd schreef op donderdag 30 juni 2005 @ 11:59:
[...]
Om maar even lekker arogant te doen, er valt weinig niet mee eens te zijn Het is een hack/workaround, je maakt immers van een stateless protocol een statefull protocol d.m.v. polling. In dit soort gevallen moet je je als ontwikkelaar afvragen of je niet beter af bent met een ouderwetse applicatie (of een applet/flash component)

Nee dat doe je niet, je spreekt op een gemakkelijke manier je serverside code aan. Zonder AJAX genereert je server een HTML pagina. Nu manipuleert Javascript je HTML pagina. En we hebben het helemaa niet over polling.
Het is toch van de zotten dat als je een naam wijzigt, je een hele html pagina opnieuw moet laden omdat je de naam wilt bewaren en rechtsbovenin de naam moet wijzigen? Nouja, ik bedoel dat kun je toch veel netter doen? Anders moet je server een nieuwe pagina genereren, nu hoeft hij alleen op te slaan. Wat is nou intensiever voor de server?
Ik begrijp je verhaal over polling echt niet. Waarom zou je dit perse willen gebruiken om een statefull verbinding te simuleren? Daar is het volgens mij helemaal niet voor bedoelt, en dus moet je het ook niet zo gebruiken.

[Verwijderd]

waarom zou je het in een webpagina in html moeten weergeven is eigelijk de eerste vraag die je moet stellen. De vraag die alle andere vragen overbodig maakt

[Verwijderd]

Verwijderd schreef op donderdag 30 juni 2005 @ 11:59:
[...]
Om maar even lekker arogant te doen, er valt weinig niet mee eens te zijn Het is een hack/workaround, je maakt immers van een stateless protocol een statefull protocol d.m.v. polling. In dit soort gevallen moet je je als ontwikkelaar afvragen of je niet beter af bent met een ouderwetse applicatie (of een applet/flash component)

Dat sommigen mensen het als een hack zien, zegt meer over de kennis van de techniek zelf, dan de techniek zelf. xmlHttpRequest, is zoals het is, stateless.

Het moet geen ander protocol worden, het hoeft geen ander protocol te worden, het is zoals het is en ik volg werkelijk niet wat de mensen intrigeert om er telkens weer een heel andere werking aan te moeten hangen, en nofi maar heb je dan uberhaupt wel genoeg kennis van de materie of van het ontwikkelen van web applicaties op de client in het algemeen? Er is totaal geen reden voor een realtime verbinding, de techniek is volwassen genoeg om daar mee om te gaan en dat kan zonder allerlei layers door elkaar te slingeren maar je moet wel weten hoe, en dat is hier de bottleneck zoals je dit ook ziet met de projecten die tegenwoordig allemaal keihard complete source via xmlHttpRequest gaanversturen.

Op het moment dat jij in een client applicatie een database wijziging maakt, geef je aan de database door via een adapter dat deze data is gewijzigd en of de database dit voor je wilt verwerken. Exact hetzelfde is xmlHttpRequest. Het is puur een adapter, om in de background data te versturen of te ontvangen, niet meer en niet minder.

[Verwijderd]

Verwijderd schreef op donderdag 30 juni 2005 @ 12:08:
Het is toch van de zotten dat als je een naam wijzigt, je een hele html pagina opnieuw moet laden omdat je de naam wilt bewaren en rechtsbovenin de naam moet wijzigen?

Ik snap wel wat je bedoeld, maar zo heel raar is dat eigenlijk niet. In traditionele gui of andere grafische omgevingen wordt ook wel eens gewoon de hele scene of de hele frame overnieuw opgebouwd. Soms (met name in gui's) kun je dmv "damage controll" alleen dat gene redrawen wat 'beschadigd' is door een verandering, maar dikwijls zorgen overlappingen ervoor dat toch je hele frame overniew getekend wordt. In (3D) spellen zie je dit ook bijvoorbeeld.

Met Ajax kun je een soort van damage redraw op HTML screens doen. Dat is zeker mooi, en ook wel logisch. Het betekent echter dus niet dat het helemaal overnieuw laden ECHT raar is ofzo, want dat gebeurd veel vaker op veel andere gebieden ook.

[Verwijderd]

@gordijnstok
Goed als we beroep gaan doen op mijn kennis om je standpunt te verdedigen betekend het domweg dat je geen geldige argumenten hebt. Ik heb mijn argumenten gepresenteerd zoals ze zijn en daar heb je het mee te doen. Dat jij ze nu als een of andere Ajax jehova naast je neer legt is prima maar het geeft aan dat je de techniek niet normaal kunt aanprijzen.

Je probeert stateless statefull te maken en dan moet bij elke willekeurige ontwikkelaar een belletje gaan rinkelen dat de aanpak misschien niet de juiste is.

[Verwijderd]

Verwijderd schreef op donderdag 30 juni 2005 @ 13:04:
@gordijnstok
Goed als we beroep gaan doen op mijn kennis om je standpunt te verdedigen betekend het domweg dat je geen geldige argumenten hebt. Ik heb mijn argumenten gepresenteerd zoals ze zijn en daar heb je het mee te doen. Dat jij ze nu als een of andere Ajax jehova naast je neer legt is prima maar het geeft aan dat je de techniek niet normaal kunt aanprijzen.

Je probeert stateless statefull te maken en dan moet bij elke willekeurige ontwikkelaar een belletje gaan rinkelen dat de aanpak misschien niet de juiste is.

Nee ik daag je uit om met concrete antwoorden te komen op mijn vragen. Het enige wat jij roept is, we gooien controllers over, het is niet statefull, er moet een ander protocol komen wat dit is niet goed. Jij geeft echter compleet niet aan waarom. Ik vraag me dan, en dat lijkt mij geheel terecht gezien je standpunt mbt het protocol, af of je wel op de hoogte bent van de mogelijkheden van browsers om zonder een realtime verbinding met data om te gaan. Ik geef met het voorbeeld van een SQL adapter ook aan hoe je ertegenaan moet kijken.

Jjij bedoelde met je opmerking over HTML, waarschijnlijk in de richting van binaire data. Maar ook zo moet je er gewoon niet naar kijken. Daarvoor zijn er specifieke oplossingen, xmlHttpRequest is absoluut niet bedoeld als een uitgebreid protocol voor data uitwisseling, het is bedoeld als eenvoudig en lichtgewicht.

Als jij niet met concrete argumenten kunt komen heeft die welles/nietes discussie dan ook helemaal geen zin. Ik leg uit wat de mogelijkheden zijn, en waarom het niet mogelijk is, en jij wimpelt het af met hetzelfde verhaaltje zonder onderbouwing. Wat verwacht je dan als tegenantwoord? Er zijn meerdere mensen in deze thread die vragen, "jongens kom dan met argumenten, situaties, en voorbeelden".

Als jij met een voorbeeld komt, waarin xmlHttpRequest te kort doet en waarbij het essentieel is dat je een statefull verbinding hebt zal ik de laatste zijn die je er ongelijk in geeft. Ik heb al eerder aangegeven, dat het niet overal geschikt voor is.

[ Voor 14% gewijzigd door Verwijderd op 30-06-2005 13:18 ]

[Verwijderd]

jij zegt dingen die ik niet geroepen hebt, dag gordijnstok

[Verwijderd]

Welk gedeelte uit deze quotes heb ik voor jouw ge-edit?

Verwijderd schreef op donderdag 23 juni 2005 @ 11:15:
Idee een 10, uitvoer een 3.

Ik vind dit echt pure workarounds om een statefull protocol te ontwikkelen. Het is leuk om aan te kaarten dat een statefull protocol in sommige situaties wenselijk is maar daar is ook alles mee gezegd. Tijd voor een goede nieuwe standaard die, als het even kan, niet voort borduurt op dat adtandse onderdoordachte html en js...

Verwijderd schreef op donderdag 23 juni 2005 @ 11:53:
ik snap niet waarom je de hele tijd de hele "Java wereld" erbij haalt?
Het feit blijft dat je controllers moet overpompen en zodoende pas iets kan. Functionaliteit die niet gespecificeerd is en dus met deze workaround wordt opgelost.

Verwijderd schreef op donderdag 30 juni 2005 @ 10:58:
Hoe je het ook went of keert: het blijft een hack/workaround om het http protocol statefull te maken. Kom op zeg, pollling, onzinnige belasting. Ik vind het niets meer dan een amateuristische hype, het zal wel weer over waaien.

Verwijderd schreef op donderdag 30 juni 2005 @ 12:13:
waarom zou je het in een webpagina in html moeten weergeven is eigelijk de eerste vraag die je moet stellen. De vraag die alle andere vragen overbodig maakt

[Verwijderd]

inderdaad, jij claimed dus dingen die ik niet geroepen heb.

moeten is iets anders dan tijd voor....

[ Voor 27% gewijzigd door Verwijderd op 30-06-2005 14:00 ]

[Verwijderd]

Verwijderd schreef op donderdag 30 juni 2005 @ 13:59:
inderdaad, jij claimed dus dingen die ik niet geroepen heb.

moeten is iets anders dan tijd voor....

Ow .. oops .. ik had "moeten" en "tijd voor" niet moeten verwisselen, ze betekenen in deze context natuurlijk totaal iets anders. Ja, dat maakt uiteraard de gedachtengang in de discussie helemaal anders.

[Verwijderd]

ja want jij impliceert nu dat ik compleet anti ajax ben, en dat is niet het geval. Ik ben gewoon kritisch, zeker tegenover jehova's.

dus doei

[Verwijderd]

mzzl!

[ Voor 12% gewijzigd door Verwijderd op 30-06-2005 22:03 ]

[Verwijderd]

Verwijderd schreef op donderdag 30 juni 2005 @ 14:18:
ja want jij impliceert nu dat ik compleet anti ajax ben, en dat is niet het geval. Ik ben gewoon kritisch, zeker tegenover jehova's.

dus doei

Nee je bent niet kritisch, je bent niet goed geinformeerd, en dat had je uit de replies van oa Crisp ook kunnen opmerken want ook hij probeert het een en ander nog duidelijk uiteen te zetten. Dat is niet erg, maar als je probeert te discussieren met mensen die wel op de hoogte zijn van de technieken, en met non argumenten gaat komen zoals ik al in mijn eerdere reply aangaf dan kun je verwachten dat er pittige reacties terugkomen op de opmerkingen die je plaatst. Als je vervolgens de vragen niet kunt stellen, kunnen mensen ze ook niet voor je beantwoorden en geloof het of niet, we beantwoorden het graag maar dan moet je wel met een startpunt komen anders dan "Tijd voor een goede nieuwe standaard die, als het even kan, niet voort borduurt op dat adtandse onderdoordachte html en js..."

[ Voor 28% gewijzigd door Verwijderd op 30-06-2005 15:03 ]

[Verwijderd]

Verwijderd schreef op donderdag 30 juni 2005 @ 11:55:
Of het zo is weet ik niet, maar was er ook niet de issue dat ook al clean je netjes alles, dat er dan toch nog memory problemen kunnen komen bij -zeer- intensieve dom bewerkingen, simpelweg omdat de browser implementatie zelf ook lekt?

Dat zou natuurlijk altijd kunnen ja, ik ben ze echter behalve de reeds gedocumenteerde issues nog niet echt tegengekomen. Het kan natuurlijk ook zijn dat men het als geheugenlekken zien omdat ze "deze wel hebben opgeruimd, maar nog niet direct resultaat zien omdat de garbage collector nog niet uitgevoerd is. Als je kijkt naar (en nu pak ik een complex stukje werk met veel dependencies tussen objecten) Bindows, daar is het memory leak gebeuren gewoon onder controle en dat hebben ze gedaan door vanaf scratch goed op hun code te letten. De developers hiervan zijn zich dus ook heel goed bewust van de taal waarmee ze werken, puur omdat ze de ervaring hebben

Als je merkt dat je code lekt maar geen flauw idee hebt waar (en dat is heel goed mogelijk als je 1000 regels javascript hebt staan met evenzoveel references), dan kun je gebruik maken van Drip! waarmee je heel snel ziet welke objecten nu echt lekken

Het is spijtig dat er nog geen goede IDE's (zodat je niet heel je code af hoeft te zoeken naar een method), profilers, debuggers zijn voor Javascript waarmee je dit soort zaken standaard kunt afhandelen. Venkman is een goed begin als debugging/profiler maar ik zou graag meer op de markt zien komen dan alleen Venkman. Dat is een terecht minpunt aan het Ajax verhaal imo, het gemis aan goede tooling.

[ Voor 25% gewijzigd door Verwijderd op 01-07-2005 09:05 ]

[mulder]

Licht offtopic:
Microsoft Atlas

[Verwijderd]

Waarbij Aaron een hele sterke opmerking maakt:

Scott,

Very cool. You guys should definitely take a look at some of the kits already in this space. The one with the scope nearest to what you're trying to build is probably the Dojo Toolkit (dojotoolkit.org).

One thing that concerns me however, is when you say that developers should be able to use this technology without really understanding it (I paraphrase :-)). You should be careful with that. I also have a good deal of experience with ASP.Net and DHTML and as a previous poster said, the server controls that shipped with ASP.Net 1.0 were a complete no-go because they weren't - in a word - webby.

They did not build on the fundamentals of modern web development: structural markup and CSS for presentation, gracefully improving when the right technologies (CSS, DOM) were available. Instead, they tried to detect browsers on the server and send two completely different sets of markup to the client, creating a maintenance nightmare.

I think the reason this was done was the same reason that is being presented here: to make it really easy to get something that jumps and spins onto the page for people that didn't really understand how that's accomplished.

Most technologies MSFT have created recently that really succeed do so because of their clarity, transparency, and consistency -- not because of their drag-n-drop-ability.

Take, for example the .NET BCL. By all means, probably more complex than VB Control or ATL. But wildly popular and successful. Why? I think because once people understand how .NET works at a high level and have the fundamental concepts, they can crack that BCL open and peer all the way down to the very bottom and it all makes sense. It's all self-consistent and plays by the same rules.

Do the same for DHTML. Build on top of the foundation of the real web, not a new one that you layer on top of the real one. That way, when developers are ready to customize and extend those great AJAX tools you give them -- they won't be shocked to find that internally, they're completely different beasts. There will be a smooth learning curve all the way down to the very core. I think that is the way to make this a successful project in the long term.