/u/81251/smurflogo.JPG?f=community)
Dat bedoel ik idd.crisp schreef op maandag 22 augustus 2005 @ 12:53:
mwa, als het bijvoorbeeld enkel om een stukje tekst gaat waarom zou je dan geen text/plain terugsturen?
Ik gebruik nog wel eens een vorm van serializen voor bijvoorbeeld arrays. XML heeft dan meestal toch een grotere overhead.
:strip_exif()/u/3333/pumpkin_avatar.gif?f=community){kind=avatar}
:strip_exif()/u/41306/web_anim.gif?f=community)
:strip_icc():strip_exif()/u/92296/sinister.jpg?f=community)
:strip_exif()/u/13214/schanulleke.gif?f=community)
Verwijderd
Is niet crossbrowser mogelijk, heb het nog even nagevraagd
De support is er gewoon nog niet.
Verwijderd
Ik denk niet dat dit een echte issue is. Er zijn genoeg applicaties die op zichzelf ook al niet consistent zijn. Kijk naar een Microsoft Encarta, Microsoft Money, Macromedia Studio MX, die hebben totaal geen enkele consistentie met standaard client applicaties. Dan hebben we het nog niet eens over de interface van Outlook 2003 die op geen enkele manier overeenkomt met de standaard windows applicaties. Zowiezo in de hele Office suite gebruikt men totaal andere controls voor de contextmenu's en de navigatie. Als dat niet inconsistent is dan weet ik het ook niet meer
Dat denk ik dus ook. Daarom, de kosten zullen qua ontwikkeling toch nog steeds aan de hoge kant zijn mits je al een framework hebt die je veel tijd bespaart (zoals ze dit bij MSN Kahuna/FireAnt aan het doen zijn). Er zijn ook maar weinig goede componenten in public te vinden, het meeste spul is van bar slechte kwaliteit. Er is geen enkel goed grid/listview te vinden laat staan dat de componenten die er rondzweven in 99% van de gevallen niet beschikken over een interface die als listener fungeert voor wijzigingen van data en daarop een actie kan uitvoeren.
Daarom zullen ook hier de kosten hoog zijn, want er zal gewoon ontwikkeld moeten worden. Er is namelijk niets/bar weinig op dat gebied te koop.
Maar, wat is dan de oplossing? Alle data als XML binnenhalen en in beide browsers een XSLT eroverheen?:
[...]
Is niet crossbrowser mogelijk, heb het nog even nagevraagd
Klaar voor een nieuwe uitdaging.
:strip_exif()/u/80759/monstermania_small.gif?f=community)
Wat mij betreft zou dat wel een issue moeten zijn. Het feit dat Microsoft zich niet aan eigen standaarden houdt en geen consitente look & feel heeft tussen haar applicaties verdient IMHO zeker geen navolging. In usability kringen is met het er over eens: consistency is king.:
[...]
Ik denk niet dat dit een echte issue is. Er zijn genoeg applicaties die op zichzelf ook al niet consistent zijn. Kijk naar een Microsoft Encarta, Microsoft Money, Macromedia Studio MX, die hebben totaal geen enkele consistentie met standaard client applicaties. Dan hebben we het nog niet eens over de interface van Outlook 2003 die op geen enkele manier overeenkomt met de standaard windows applicaties. Zowiezo in de hele Office suite gebruikt men totaal andere controls voor de contextmenu's en de navigatie. Als dat niet inconsistent is dan weet ik het ook niet meer
Nu weet ik wel dat een "echt" programma dus geensinds een garantie is voor een consistente interface, maar het is in ieder geval mogelijk zo'n interface te maken. Ik zie niet in hoe je met behulp van AJAX een interface kan bouwen die consistent is met de rest van mijn systeem, zeker niet als de gebruiker andere instellingen heeft dan de default.
My opinions may have changed, but not the fact that I am right. -- Ashleigh Brilliant
Verwijderd
Ze mogen het best eens zijn in die kringen, feit blijft dat het toch met open armen wordt ontvangen door gebruikers. Men kan ook te ver doorschieten met consistency, om het consistency zijn ondanks, dat de applicatie vanwege die geforceerde consistency de usability krijgt van een onhandelbaar gedrocht.
Uiteindelijk zeggen we nadat alle gebruiker de applicatie links lieten liggen, "Ja maar het was wel consistent". Consistency is een richtlijn en niet meer dan dat.
Komt bij dat binnen de scope van een applicatie er wel degelijk consistency is, overal werken de toolbars hetzelfde, gebruikt men dezelfde dialogs met tabs, zit over een ok en cancel button en zijn de kleuren overal doorgevoerd. Maar dat is binnen de applicatie, en dat is wat telt voor een gebruiker
Uiteindelijk zeggen we nadat alle gebruiker de applicatie links lieten liggen, "Ja maar het was wel consistent". Consistency is een richtlijn en niet meer dan dat.
Komt bij dat binnen de scope van een applicatie er wel degelijk consistency is, overal werken de toolbars hetzelfde, gebruikt men dezelfde dialogs met tabs, zit over een ok en cancel button en zijn de kleuren overal doorgevoerd. Maar dat is binnen de applicatie, en dat is wat telt voor een gebruiker
:strip_icc():strip_exif()/u/39264/notpingu.jpg?f=community)
Verwijderd
Flash is in elke browser het zelfde en heeft een zeer hoge marktpenetratie. Misschien wel meer dan browsers waar javascript daadwerkelijk aanstaat? 
. Het verschijnt nu zelfs op mobieltjes.Mocht een klant geen flash-plugin hebben en hij wil toch de webapplicatie gebruiken, dan lijkt mij de drempel niet hoog om de plugin dan even te installeren. AJAX heeft als voorwaarde dat javascript aan moet staan.
p.s. bedoelde trouwens browserspecifiek ipv browserafhankelijk, misschien dat dit niet helemaal duidelijk was.
kort samengevat: Het geeft je de mogelijkheid om Rich Internet Applications te bouwen, net zoals je een web- of windowsapplicatie zou bouwen in .NET. (Misschien dat het in de toekomst geïntegreerd is in VS.NET)
Neem even aan dat je bedoelde 'het nut NIET van Flex' en daar ben ik het met je eens (maar dit kan veranderen als ik echt met deze technologie gewerkt heb en blijkt dat het super-eenvoudig is).
[ Voor 6% gewijzigd door Verwijderd op 24-08-2005 15:47 ]
Goeie punten. Bij mij draait die demo lekker vlot, omdat mij fat client ook een fat CPU heeft. Met AJAX of flash clients ben je vaker geneigd client-side lompere dingen te doen, terwijl je juist totaal geen inzicht hebt of de client het allemaal wel aankan.
Het feit dat je met AJAX de meest vertrouwde functionaliteiten in een browser (refresh, stop, address bar en niet te vergeten 'back') praktisch om zeep helpt, is een grote bedreiging voor de user experience, die met AJAX juist zo prettig zou moeten zijn. Dat limiteert voor mij het toepassen van AJAX tot zaken waarbij je er met zekerheid vanuit kunt gaan dat de gebruiker deze nooit met een 'back' ongedaan zou willen maken.
Anderzijds heb ik wel ooit een demo van een applicatie gemaakt met AJAX (toen ik nog niet wist dat dat zo heette), die standaard in een fullscreen browser draaide op geijkte systeem specs. Het eerste wat ik er echter ingebouwd heb is een history stack, een soort van address bar die het pad aangaf, back+forward knoppen en een busy indicator
Verwijderd
Raptorix ik heb met zowel Flex als met de oude situatie ontwikkeld, ik weet dus wel zeker waar ik over praat. Voor Flex hoef je gewoon veel minder moeite te doen om een simpele applicatie te ontwikkelen, dat is ook geen probleem maar dat komt wel met een prijs en de beperkte mogelijkheden. Jij wil toch niet beweren dat je een site als Salesforce op dezelfde snelheid, met dezelfde servers, en met dezelfde traffic kunt laten draaien op een pure Flex oplossing. Ik weet niet hoe jouw ervaringen zijn, maar die van mij waren dat de Flex applicatie het bij een beetje drukte zwaar liet afweten, de requests niet netjes ging afronden, bleef hangen met een loading icon, en de al zware quad cpu server echt een heel moeilijke tijd bezorgde.
Wat Flex dan wel mooi heeft geflikt zijn de histories, dat ben ik met je eens, echter Dynamic libraries worden gecached, idem voor css, dat kan ik niet van Flex zeggen. Bij Flex is er geen enkele manier om de data clientside te cachen buiten de actieve sessie om, serverside legt Flex een cache aan in /web-inf/flex/cache.dep om nogmaals compilation te voorkomen maar dat is ook de enige mogelijkheid die Flex door middel van de cache tags heeft. Zodra de sessie weg is, ben je je cache ook kwijt. De rest van de data wordt telkens opnieuw opgehaald, dat wil je echt niet met veel traffic hebben. Komt nog bij dat alles via de Flex server gaat, een webserver heeft gewoon een veel hogere capaciteit met betrekking tot het serveren van data die niet behandeld hoeft te worden.
Een community, jazeker ik ben ook actief in de FlexCoders list maar je kunt support van een product bij een klant niet verkopen onder de term "community hulp" als er flink wat geld voor betaald moet worden. Dat vind ik echt onacceptabel gezien de licentietarieven. (Al voelen de oude kopers zich helemaal genaaid met hun prijzen nadat de licenties zijn omgegooid .. ).
Flex zal er echt nog wel komen, maar ik heb zelf het gevoel dat ze nog een lange weg hebben te gaan. Het is het gewoon nog net niet. Ik heb nog geen enkele applicatie in Flex gezien die lekker performde, en dat kan ik wel van de "Ajax" kant van het verhaal zeggen waarbij we ook praten over hele grote applicaties die zonder hickup response gaven.
Wat Flex dan wel mooi heeft geflikt zijn de histories, dat ben ik met je eens, echter Dynamic libraries worden gecached, idem voor css, dat kan ik niet van Flex zeggen. Bij Flex is er geen enkele manier om de data clientside te cachen buiten de actieve sessie om, serverside legt Flex een cache aan in /web-inf/flex/cache.dep om nogmaals compilation te voorkomen maar dat is ook de enige mogelijkheid die Flex door middel van de cache tags heeft. Zodra de sessie weg is, ben je je cache ook kwijt. De rest van de data wordt telkens opnieuw opgehaald, dat wil je echt niet met veel traffic hebben. Komt nog bij dat alles via de Flex server gaat, een webserver heeft gewoon een veel hogere capaciteit met betrekking tot het serveren van data die niet behandeld hoeft te worden.
Een community, jazeker ik ben ook actief in de FlexCoders list maar je kunt support van een product bij een klant niet verkopen onder de term "community hulp" als er flink wat geld voor betaald moet worden. Dat vind ik echt onacceptabel gezien de licentietarieven. (Al voelen de oude kopers zich helemaal genaaid met hun prijzen nadat de licenties zijn omgegooid .. ).
Flex zal er echt nog wel komen, maar ik heb zelf het gevoel dat ze nog een lange weg hebben te gaan. Het is het gewoon nog net niet. Ik heb nog geen enkele applicatie in Flex gezien die lekker performde, en dat kan ik wel van de "Ajax" kant van het verhaal zeggen waarbij we ook praten over hele grote applicaties die zonder hickup response gaven.
[ Voor 3% gewijzigd door Verwijderd op 25-08-2005 20:47 ]
Ben ik met je eens Gordijnstok, de performance kan zeker nog wel beter. Overigens kan je gerust de helft van de prijs afpingelen op een flex licentie
Heb je trouwens wel eens met Laszlo gewerkt, niet zo uitgebreid qua componenten als Flex maar wel gratis en opensource, werk er al tijdje mee en zeker als je product beetje kent en de beperkingen ervan is het een goed alternatief.
Begrijp me niet verkeerd, ik been zeer positief over Ajax, kijk naar Gmail en Google personalised, dat zijn mooie voorbeelden.
Je zou eens naar openrico moeten kijken, een zeer aardige library van Ajax widgets.
Heb je trouwens wel eens met Laszlo gewerkt, niet zo uitgebreid qua componenten als Flex maar wel gratis en opensource, werk er al tijdje mee en zeker als je product beetje kent en de beperkingen ervan is het een goed alternatief.
Begrijp me niet verkeerd, ik been zeer positief over Ajax, kijk naar Gmail en Google personalised, dat zijn mooie voorbeelden.
Je zou eens naar openrico moeten kijken, een zeer aardige library van Ajax widgets.
Verwijderd
Maak jij je ook zorgen of de hemel op je hoofd valt?
Ik vind overigens wel dat je deels gelijk hebt in de Flex vs. AJAX discussie. Flex is echt een product gebouwd voor ontwikkelaars. Een taal+IDE+framework die ontwikkelaars in staat stelt (relatief) snel complete Rich Internet Applications te bouwen. AJAX is niets meer dan een techniek die ontwikkelaars mogelijk maakt client-server requests uit te voeren en af te handelen zonder een webpagina te verversen. Verdomd handig, maar op zichzelf niet bepaald indrukwekkend.
Verwijderd
Je kunt uitleggen wat er mis aan is of je reageert domweg niet. Aan dit soort nutteloze opmerkingen heeft niemand wat. Dus leg nou eens uit wat ons allen naar Flex moet bewegen en Ajax links moet laten liggen:
Verwijderd
Het spijt mij dat ik jou elite niveau nog niet heb bereikt.
Of ik nu een compleet gegenereerde flash over een lijntje stuur of dat ik wat geserialiseerde data over een lijntje pomp naar een applet maakt voor het resultaat niet uit. Het resultaat is dus een applicatie draaiende binnen een context van een webbrowser. Maar goed dat hoef ik jou natuurlijk niet uit te leggen want jij stond al een aantal traptreetjes hoger
Lekker niveau hier, maar jij vraagt me naar de voordelen van Flex boven Ajax technologieen, als je met dit soort non argumenten komt ben ik hier zeker weg. Ik wil me zelf geen betweter noemen, maar kan wel zeggen dat ik serieus naar alle type Ria Producten heb gekeken, ik neem de tijd om uit te leggen wat de voor en nadelen zijn. Terwijl jij alleen maar op negativisme uitbent. Typisch voor een hoop programmeurs, bang voor nieuwe technologieen, en te weinig innovatief. Kijk eens met een open vizier naar de mogelijkheden die er zijn, en geef dan je oordeel. De manier waarop jij dingen afbrand is wel heel makkelijk. In dezelfde analogie kan ik net zo goed zeggen dat JSP/PHP/ASP geen voordeel hebben boven HTML, immers de code die het oplevert is niets anders dan statische HTML:
[...]
Het spijt mij dat ik jou elite niveau nog niet heb bereikt.
Of ik nu een compleet gegenereerde flash over een lijntje stuur of dat ik wat geserialiseerde data over een lijntje pomp naar een applet maakt voor het resultaat niet uit. Het resultaat is dus een applicatie draaiende binnen een context van een webbrowser. Maar goed dat hoef ik jou natuurlijk niet uit te leggen want jij stond al een aantal traptreetjes hoger
Verwijderd
Ik vraag inderdaad naar de voordelen, en ik hoop nog steeds op antwoord. Dat lijkt me vele malen constructiever dan het niveau van deze discussie aan de kaak te stellen. Verder wil ik best geloven dat ik non-argumenten lever en dat jij ook precies weet waarom, doch kan ik je heldere uitleg "
" niet geheel bevatten.Daar ben ik blij om, dus dan bij deze nogmaals het verzoek om deze is hier neer te zetten
Ik brand niks af, ik zie het grote voordeel niet. Maar gelukkig geef je in je post aan dat je dat kunt uitleggen en daar ben ik dan weer blij om. Tevens vind ik het geweldig dat je naast een top-programmeur ook een psycholoog bent
Sorry dat ik je beledigd hebt. Zou je alleen voor mij even kunnen aangeven hoe ik je hebt beledigd zodat ik de toekomst deze fout niet nogmaals maak.
[ Voor 12% gewijzigd door Verwijderd op 26-08-2005 14:00 ]
/u/107051/jeroenmadtrix60.png?f=community)
I second that. Een discussie voeren is prima, maar met modder gooien op het persoonlijke vlak is nergens voor nodig. Hou het dus ontopic en op een plezierige toon.
'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.
Verwijderd
De reden waarom ik Flex noemde (zonder er ooit mee gewerkt te hebben ), was puur om het hele pakket\framework. Je hebt een ontwikkelomgeving, controls, geïntegreerd, abstract, etc. Dingen die een programmeur\manager snel en 'makkelijk' producten\projecten laat ontwikkelen.
Dit vind ik in AJAX (nog) niet terug, alhoewel je natuurlijk je eigen controls en frame kan opbouwen, maar dit kost tijd. Maar nu kijkend naar Backbase lijkt dit qua tools en middelen ook veel op Flex (heb de site snel bekijken, dus kan het fout hebben) en dat ziet er ook veel belovend uit. (Ook mooie demo's trouwens).
Voor de opmerking dat Flex traag is (zoals Gordijnstok heeft ondervonden), hopelijk wordt dit bij komende versies verholpen en dat het over een jaar of twee echt goed bruikbaar is.
), was puur om het hele pakket\framework. Je hebt een ontwikkelomgeving, controls, geïntegreerd, abstract, etc. Dingen die een programmeur\manager snel en 'makkelijk' producten\projecten laat ontwikkelen.Dit vind ik in AJAX (nog) niet terug, alhoewel je natuurlijk je eigen controls en frame kan opbouwen, maar dit kost tijd. Maar nu kijkend naar Backbase lijkt dit qua tools en middelen ook veel op Flex (heb de site snel bekijken, dus kan het fout hebben) en dat ziet er ook veel belovend uit. (Ook mooie demo's trouwens).
Voor de opmerking dat Flex traag is (zoals Gordijnstok heeft ondervonden), hopelijk wordt dit bij komende versies verholpen en dat het over een jaar of twee echt goed bruikbaar is.
Tenminste... dat [ denk / zie / weet ] ik... | Javascript obfuscator | foto's en video's uploaden
Verwijderd
Eenvoudige dummie interface: http://83.98.152.28/sampl....mxml?versionChecked=true
Interessant dat meerdere mensen in dit topic soortgelijke dingen roepen, dat Flex niet voor echte applicaties is. En dat terwijl het merendeel van onze klanten het juist voor dit soort zaken toepast, met name op het intranet. Ik denk dat deze verwarring met name komt door het gebrek aan publieke voorbeelden hiervan? (toegegeven, Macromedia heeft voornamelijk guided selling apps te laten zien omdat ze publiek zijn. Veel bedrijven prefereren niet hun intranet applicaties ten toon te stellen).
Overigens staan er grote performance verbeteringen op schema voor Flex 2.0. Hetgeen niet wil zeggen dat huidige Flex applicaties niet performant kunnen zijn, je moet echter wel beter opletten met wat je doet (maar volgens mij is dat bij veel technieken het geval).
Ik heb niet de indruk dat je hier uit ervaring spreekt? Mijn ervaring wijst in ieder geval anders uit (en ja, er is nog een hoop te verbeteren ook). Net als bij javascript zijn er bij Flex vele wegen om een probleem heen.
Dat wat jij de support forums noemt, dat zijn niet de support forums; die zijn namelijk alleen bereikbaar voor klanten. Blocking issues/bugs worden gratis gefixed voor klanten en er worden zelfs klant specifieke releases van Flex gemaakt.
Excuus dat "er niet genoeg resources zijn" ben ik nog niet tegen gekomen, hoe kom je daar aan?
Ook je opmerking over data-caching roept vraagtekens bij mij op; Flex geeft je de keus, je kan zelfs offline je applicatie gebruiken inclusief de data. Hoezo geen cache mogelijkheden?
De discussie van JavaScript vs Flash vs Java kunnen we eindeloos voeren; er zal nooit een eenduidig antwoord komen denk ik. Voor de ene applicatie is JavaScript de beste keus, een ander Flash, weer een ander Java.
:strip_icc():strip_exif()/u/77332/crop5e54ec42433bc_cropped.jpeg?f=community)
Verwijderd
Ik zie die starttijd ook niet zo als een probleem eerlijk gezegd. Als je maar zorgt dat de client merkt dat er iets gebeurt, en daar zorgt de loading bar voor.
Als dit het geval is valt mij hele discussiepunt over clientside cache weg, tenzij ik nog iets over het hoofd zie zoals loadMovie voor elke container
Maar dat lijken me ook niet de zaken die echte vertragingen opleveren. In ieder geval op een Ajax vergelijkbare wijze.Ik ben bekend met je klantgerichtheid in positieve zin.
Ik doelde ook meer op het inzetten van resources voor de public forums voor mensen die echt in de problemen komen te zitten.
Ja, over de ondersteuning aan Macromedia's is nagenoeg geen kwaad woord over te spreken
Blijf het nog steeds jammer vinden dat ik Studio MX opnieuw moest kopen toen ik van Windows naar MacOSX wilde verhuizen
Blijf het nog steeds jammer vinden dat ik Studio MX opnieuw moest kopen toen ik van Windows naar MacOSX wilde verhuizen
[ Voor 3% gewijzigd door alienfruit op 28-08-2005 21:06 ]
Verwijderd
Ik denk dat er op bepaalde punten wel verbeteringen nodig zijn, met betrekking tot de afhandeling van bug requests, de activatie issues in Studio MX (die Waldo dus perfect had aangepakt maar het is jammer dat hij er uberhaupt werk voor moest verrichten), mayor bugs die al jaren aanwezig zijn maar gewoon niet worden aangepakt waardoor functionaliteit onbruikbaar wordt (cfschedule bug in CF MX heb ik het hier over), en de beperkte aandacht voor DWMX fixes (heb hiervoor ook al 3x een lange lijst aan bugs voor ingediend via het formulier). Maargoed, dat valt buiten de scope van deze thread Ik weet ook niet in hoeverre dit actueel is binnen MM.
Ik weet ook niet in hoeverre dit actueel is binnen MM.
[ Voor 8% gewijzigd door Verwijderd op 28-08-2005 22:00 ]
:strip_exif()/u/26499/avatarRHCP6060.gif?f=community){kind=avatar}
Well,
16 - 19 mei is er de XTech conferentie in Amsterdam waar Ajax uitvoerig behandelt gaat worden, evenals Javascript 2, XSLT 2.0 etc.. Als je ziet hoeveel bedrijfjes daar komen, kan je stellen dat Ajax weldegelijk een bodem heeft om op te groeien, maar dat het allemaal nog erg in de kinderschoenen staat. Ik denk deels vanwege de toepasbaarheid en deels vanwege de wat oudere hedendaags algemeen geaccepteerde technieken.
Maar goed, ik weet meer na XTech.
16 - 19 mei is er de XTech conferentie in Amsterdam waar Ajax uitvoerig behandelt gaat worden, evenals Javascript 2, XSLT 2.0 etc.. Als je ziet hoeveel bedrijfjes daar komen, kan je stellen dat Ajax weldegelijk een bodem heeft om op te groeien, maar dat het allemaal nog erg in de kinderschoenen staat. Ik denk deels vanwege de toepasbaarheid en deels vanwege de wat oudere hedendaags algemeen geaccepteerde technieken.
Maar goed, ik weet meer na XTech.
:strip_exif()/u/39469/calvingot.gif?f=community)
Ajax is leuk en handig..
Maar als je je aan de standaard wilt houden mag je geen gebruik maken van innerHTML.
Dus kun je alleen dingen aanpassen met de DOM.
Als je bijvoorbeeld een hele grafische (veel plaatjes) website hebt en hierbinnen foto's wilt laten zien is ajax handig om door de foto's te bladeren zonder alle andere plaatjes te herladen. Probleem is echter als je ook nog commentaar bij die foto's hebt.
Dan moet je dus in je javascript html gaan aanmaken, dit is niet echt netjes..
Maar ja.. de meeste ajax sites gebruiken wel innerHTML.. maar toch.. het is niet echt netjes in z'n geheel
Maar als je je aan de standaard wilt houden mag je geen gebruik maken van innerHTML.
Dus kun je alleen dingen aanpassen met de DOM.
Als je bijvoorbeeld een hele grafische (veel plaatjes) website hebt en hierbinnen foto's wilt laten zien is ajax handig om door de foto's te bladeren zonder alle andere plaatjes te herladen. Probleem is echter als je ook nog commentaar bij die foto's hebt.
Dan moet je dus in je javascript html gaan aanmaken, dit is niet echt netjes..
Maar ja.. de meeste ajax sites gebruiken wel innerHTML.. maar toch.. het is niet echt netjes in z'n geheel
Albert Einstein: A question that sometime drives me hazy: Am I or are the others crazy?
:strip_icc():strip_exif()/u/43250/crop68baa3c257258_cropped.jpg?f=community)
Qua performance doet innerHTML het alleen wel een stukje beter.:
Maar ja.. de meeste ajax sites gebruiken wel innerHTML.. maar toch.. het is niet echt netjes in z'n geheel
Rustacean
/u/92525/me.png?f=community)
Het klinkt opzich wel interesant, maar wel ranzig duur zeg! Voor de toegangs prijs kun je bijna een maand een developper laten werken.:
Well,
16 - 19 mei is er de XTech conferentie in Amsterdam waar Ajax uitvoerig behandelt gaat worden, [...]
Maar goed, ik weet meer na XTech.
It's shocking to find how many people do not believe they can learn, and how many more believe learning to be difficult.
:strip_exif()/u/196/day-of-the-tentacle3.gif?f=community)
Pardon? Een developer kost heel wat meer dan dat hoor:
[...]
Het klinkt opzich wel interesant, maar wel ranzig duur zeg! Voor de toegangs prijs kun je bijna een maand een developper laten werken.
Ik vind de prijs wel meevallen (zeker aangezien het een meerdaags evenement is).
Today's subliminal thought is:
Dan weet ik niet wat jullie je developpers betalen, maar bij ons kun je voor een krappe 1500,- ex BTW toch echt wel een developper met HBO opleiding een maand laten werken.:
[...]
Pardon? Een developer kost heel wat meer dan dat hoor
Het is langzaam aan het bijtrekken, maar zeker de afgestudeerden van 2003 mochten gezien de schaarste van toen blij zijn als ze voor het minimum loon aan de slag konden (onder het motto van alles beter dan thuis op de bank zitten en waardevolle jaren aan ervaring kwijt raken).
Maar goed, die discussie is eigenlijk beetje offtopic hier
It's shocking to find how many people do not believe they can learn, and how many more believe learning to be difficult.
Verwijderd
offtopic:
Wat jammer dat deze discussie hier offtopic is, want ik overweeg nu om klussen 1:1 aan 'jullie' door te schuiven en zelf in een hangmat op een Thais strand te gaan liggen.
edit@flowerp hieronder: Ik overdrijf natuurlijk graag Maar in elk geval is loon van een werknemer totaal iets anders dan loonkosten voor een werkgever. (sociale verzekeringen, werkplek etc.). Het is niet uitzonderlijk dat een werkgever aan een klant 100,- per uur rekent, terwijl de werknemer die het werk uitvoert daar netto 10,- aan overhoud (Mag 'ie nog blij zijn).
Van werken in dienstverband is nog nooit iemand echt rijk geworden.
Wat jammer dat deze discussie hier offtopic is, want ik overweeg nu om klussen 1:1 aan 'jullie' door te schuiven en zelf in een hangmat op een Thais strand te gaan liggen.
edit@flowerp hieronder: Ik overdrijf natuurlijk graag
Maar in elk geval is loon van een werknemer totaal iets anders dan loonkosten voor een werkgever. (sociale verzekeringen, werkplek etc.). Het is niet uitzonderlijk dat een werkgever aan een klant 100,- per uur rekent, terwijl de werknemer die het werk uitvoert daar netto 10,- aan overhoud (Mag 'ie nog blij zijn).Van werken in dienstverband is nog nooit iemand echt rijk geworden.
[ Voor 37% gewijzigd door Verwijderd op 24-04-2006 14:16 . Reden: verduidelijkt + offtopic gemaakt ]
:
[...]
Wat jammer dat deze discussie hier offtopic is, want ik overweeg nu om klussen 1:1 aan 'jullie' door te schuiven en zelf in een hangmat op een Thais strand te gaan liggen.
offtopic:
Is het zo erg? Mischien moeten we er maar een apart topic voor openen Maar helaas, wij komen al om van het werk dus nog meer erbij gaat echt niet lukken. Daarbij, we doen geen externe opdrachten maar bouwen onze eigen (Java EE) software die we verkopen. Maar zo bijzonder kan het loon ook niet zijn, want gedurende de afgelopen +- 3.5 jaar hebben we meerdere solicitaties gehad van zowel informatica HBO als informatica WO afgestudeerden en die kwamen gewoon allemaal werken voor het loon dat geboden werd. De meeste waren al lang blij dat ze uberhaupt aan de slag konden!
Vergeet niet dat 2002/2003 bijna onmogelijk was voor pas afgestudeerden om aan een baan te komen zodat deze mensen eigenlijk voor elk loon wel wilde werken. De komende jaren zal het wellicht wat moeilijker worden om aan personeel te komen die geen absurde loon-eisen stelt, omdat de economie en de ICT sector in het bijzonder weer een beetje aan het bijtrekken is.
Is het zo erg? Mischien moeten we er maar een apart topic voor openen
Maar helaas, wij komen al om van het werk dus nog meer erbij gaat echt niet lukken. Daarbij, we doen geen externe opdrachten maar bouwen onze eigen (Java EE) software die we verkopen. Maar zo bijzonder kan het loon ook niet zijn, want gedurende de afgelopen +- 3.5 jaar hebben we meerdere solicitaties gehad van zowel informatica HBO als informatica WO afgestudeerden en die kwamen gewoon allemaal werken voor het loon dat geboden werd. De meeste waren al lang blij dat ze uberhaupt aan de slag konden! Vergeet niet dat 2002/2003 bijna onmogelijk was voor pas afgestudeerden om aan een baan te komen zodat deze mensen eigenlijk voor elk loon wel wilde werken. De komende jaren zal het wellicht wat moeilijker worden om aan personeel te komen die geen absurde loon-eisen stelt, omdat de economie en de ICT sector in het bijzonder weer een beetje aan het bijtrekken is.
It's shocking to find how many people do not believe they can learn, and how many more believe learning to be difficult.
It's shocking to find how many people do not believe they can learn, and how many more believe learning to be difficult.
Ok, op die manier. Tjsa, dan zou ik het persoonlijk geen web-app noemen maar meer een remote-app. Het probleem tot op heden met deze aanpak was dat je geen makkelijk deployment model hebt. Met een web-applicatie (voor alle duidelijkheid via een browser dus), kun je naar een eenduidige URL surfen en je applicatie 'start' dan (begint een sessie voor jou). Traditionele desktop applicaties die de GUI client-side draaien (met native widgets) en voor business logic contact opnemen met de server hebben veel problemen van de traditionele applicaties zoals installatie en onderhoud.
In dit licht gezien zou het oude X-Window protocol wel interesant zijn (alleen je GUI widgets draaien client-side, alle andere dingen draaien server side) maar dat is helaas niet echt geoptimaliseerd voor een WAN en veel connecties. En daarbij heb je ook niet echt een makkelijke 'start' functie.
Een andere interesante technologie die voor de door jou genoemde werkwijze gebruikt kan worden is java webstart. Dit zorgt voor een eenvoudige deploy methode en zorgt dat je client-side code gesynched is met de nieuwste versies op de server. Wel programmeer je hiermee toch meer een client-side app die (af en toe) contact op neemt met de server. Dit is toch nog net even wat anders dan een 'gewone' server side app waarbij je niet expliciet 2 communicerende systemen schrijft (de client-tier en de server-tier in dit geval), maar waarbij je kort door de bocht de GUI naar de client stuurt.
Dit zie ik ook zeker als een mogelijkheid. Nu wordt er veel tijd gestopt in het proppen van applicatie functionaliteit in een protocol (http) en een markup taal (html) die hier eigenlijk nooit voor ontworpen waren.
Dan heb je me verkeerd begrepen. De voorbeelden (Java web components, dwz JSF en .NET controls) renderden in mijn voorbeeld AJAX. M.a.w. Asynchronous Javascript And XML. Dezelfde web components kunnen met een andere renderkit ook een totaal andere techniek gebruiken. Het zelfde webcomponent in JSF zou ook XUL kunnen renderen en theoretisch zelfs Swing widgets (hoewel dat laatste een theoretische aangelegenheid blijft).
Het punt was dat vanuit het viewpoint van de serverside programmeur die components gebruikt, de onderliggende techniek niet direct zichtbaar is. Binnen de HTML renderkit zou een widget net zo goed een hidden self-refressing iframe kunnen renderen en via dat mechanisme XML ontvangen of eventueel direct tekst of HTML. Dat kun je dan met een mooi naampje HSIX gaan noemen of whatever. Ook hier zal de serverside programmeur alleen zien dat haar methodes worden aangeroepen die ze heeft gebonden aan het serverside component.
Maar met HET XMLHttpRequest object wordt het specificieke object bedoeld wat aangeboden wordt door een browser en waarmee je zowel sync en async via javascript requesten kunt doen. Een heel simpel ding. In essentie is het niet meer en niets minder.
Een generieke XML request over HTTP heet ook wel een webservice
It's shocking to find how many people do not believe they can learn, and how many more believe learning to be difficult.