mithras schreef op woensdag 10 maart 2010 @ 18:35:
Het ligt toch heel erg aan de applicatie zelf of die goed in een webapplicatie is te vangen? Natuurlijk zijn er nadelen, maar even zoveel voordelen.
Daarnaast lijkt me dat je best af kan stappen van de native look&feel om zo wel responsive widgets te kunnen inzetten (kijk naar simpele dingen als jQueryUI of ext.js). En deployement op één server lijkt me handiger dan een tool waarmee je op je clients alles moet deployen (ook al is dat erg gemakkelijk).
Agreed, maar in mijn ogen moet je iets niet een webapplicatie noemen als het op allerlei manieren de Windows look-and-feel moet benaderen, maar dan geskind. Er worden allerlei controls gebruikt, zoals tabbladen, comboboxen, datepickers, treeviews, en vrij veel dingen gaan steeds naar de server. Requests waar meer dan 500 KB aan HTML over de lijn gaat zijn helaas niet uitzonderlijk.
Ik heb jQuery er überhaupt geïntroduceerd, daarvoor werd alles gedaan danwel door DevExpress-controls, danwel door UpdatePanels. Dit wérkt wel, maar het is niet snel te noemen.
Dus het zo zwart/wit stellen lijkt me ook niet de juiste manier. Niet dat ik je ongelijk geef, maar enige nuance is wel nodig.

Je hebt ook gelijk, maar als je per sé een webapplicatie wilt bouwen moet je in mijn ogen ook breken met het WinForms-principe, en je applicatie anders vormgeven. We lopen nu gewoon steeds tegen problemen aan, omdat we een in principe stateless protocol om willen vormen tot iets wat states ondersteunt.
Met ViewState en SessionState kom je wel een eind, maar ideaal is anders. SessionStates verlopen en de ViewState bedraagt al 250 KB (don't ask), nog zonder dat er volledig geserialiseerde objecten instaan met collections waar honderden items onder kunnen vallen.
Devices zijn op dit moment nog niet nodig, maar ik kan me een moment bedenken dat men dit wel wil. Bijvoorbeeld om iets uit te kunnen printen. SQL Reporting Services gebruiken is dan ook niet ideaal. Lokale storage is iets wat nu nog niet nodig is, maar waar ik wel potentie inzie, bijvoorbeeld voor 'disaster recovery'-files.
De huidige webapplicatie bevat een menubalk met daaronder een reeks 'tabjes', onder ieder tabje valt een iframe. In dat iframe wordt een pagina geladen, zoals een klant. Omdat niet iedereen zomaar alles moet kunnen wijzigen, wordt standaard de hele pagina in alleen-lezenmodus getoond. Als je wil wijzigen moet je dit expliciet aangeven, en ook een reden.
Op dit moment is dat als volgt geïmplementeerd:
- Klik in de menubalk (buiten het iframe) op 'Wijzigen'
- Een javascript-actie wordt afgevuurd: het script zoekt de huidige actieve pagina op (foreach door de pagina en degene pakken die visible is), en roept op de ClientDocument weer een script aan. Als er geen script bestaat wordt een alert getoond.
- Dit script toont een in-page popup met daarin de benodigde vragen
- De gebruiker vult de vragen in en klikt op 'Bevestigen'
- De actieve tab wordt gesloten, en een nieuwe wordt geopend, met een paar andere parameters.
Als de gebruiker in de tussentijd (dus na het klikken op 'Bevestigen') een andere tab opent, wordt niet de oorspronkelijke tab gesloten, maar de tab die op dat moment openstaat. Hiervan komt niet eerst een bevestiging, het kan zijn dat de gebruiker dan dus werk kwijtraakt.
Ook bij het sluiten van de browser wordt er géén melding getoond. Ik weet dat het kan (onbeforeunload), maar ik vind dat allesbehalve een nette oplossing omdat je weinig controle hebt over wát er gebeurt. Je kunt weinig met de alert die getoond wordt, vanuit een UI-perspectief.
Daarnaast is de applicatie in z'n huidige vorm simpelweg traag, dit is niet gek als je je bedenkt dat er soms honderden script zijn. Een aantal wordt ingeladen adhv scriptfiles (die zijn goed te cachen), maar een hoop komt ook uit WebResource.axd-files (dynamisch gegenereerd dus), en een hoop andere scripts staan inline of worden zelfs ge'eval()d. De CSS is een zooitje en de HTML zit inmiddels ook vol trucs om alles goed geskind te hebben.
Men is het erover eens dat er iets moet gebeuren... of webbased een volledige rewrite, men heeft ASP.NET MVC gezien en dat performt als een malle*, of Silverlight, maar ik begin steeds meer te neigen naar WinForms + webservices voor de backend.
Ohja, trouwens: er zijn geen stresstests uitgevoerd op de webserver(s). De ontwikkelaars werken voornamelijk op localhost en dat schiet soms al niet op, maar straks moet er misschien wel 50 man tegelijk mee gaan werken, en er is geen enkel idee hoe de servers zich dan gaan houden.
*Ook met MVC kun je het traag maken, maar je hebt niet allerlei gare dingen zoals ViewStates e.d. wat al enorm scheelt.