Client-side webapp MVC structuur, hoe met DOM omgaan?

[0fbe]

Bij standaard MVC applicaties is het gebruikelijk dat de View het Model query-t voor de huidige status en die status weergeeft. Dat werkt prima voor server-side webapplicaties omdat je dan toch elke keer de hele "View" (de html pagina) doorgeeft.

Bij Client-side webapplicaties (voornamelijk Javascript) bestaat het probleem dat je niet bij elke wijziging aan je model de hele DOM wilt verversen, dat geeft een te grote performance hit. Ik ben dus opzoek naar een oplossing voor dit probleem, hoe kan je een Javascript MVC app maken die efficiënt met de DOM omgaat en alleen de wijzigen in het model in de DOM doorvoert?

Een optie zou zijn om gebruik te maken van een grote hoeveelheid views waardoor je kleine stukken van de dom maar hoeft aan te passen. Maar dit levert nog steeds wel behoorlijke obstakels op: Stel je hebt een lijst met elementen welke een gebruiker kan sorteren. Hoe zorg je er dan voor dat niet de gehele lijst gedrawt moet worden als de ordening verandert?

Een andere optie zou zijn om de view kennis te geven over de precieze wijzigingen die zijn doorgevoerd. Zodat in het vorige geval in de DOM alleen de sortering aangepast hoeft te worden. Dit heeft echter wel als gevaar dat je moet oppassen dat je model en je view consistent blijven.

Zijn er nog andere, betere oplossingen om dit te bereiken?

[Grijze Vos]

ASP.NET MVC kent daarvoor partial views. Komt neer op een form wat je inlaadt in een container in je DOM en wat zelfstandig zijn interactie met de server afhandelt.

[Danot]

Je verdeelt het scherm in onderdelen. Bij een wijziging laat je alleen een bepaald onderdeel vullen. Dit kan door middel van JSON of gewoon html die je inlaadt.
Ordenen kan vaak geheel client side, door een javascript die bijvoorbeeld de tr's in een table in een andere volgorde zet. Met jQuery kun je eenvoudig de DOM aanpassen.

[0fbe]

Danot schreef op dinsdag 05 april 2011 @ 16:22:
Je verdeelt het scherm in onderdelen. Bij een wijziging laat je alleen een bepaald onderdeel vullen. Dit kan door middel van JSON of gewoon html die je inlaadt.
Ordenen kan vaak geheel client side, door een javascript die bijvoorbeeld de tr's in een table in een andere volgorde zet. Met jQuery kun je eenvoudig de DOM aanpassen.

Het gaat in mijn geval niet zozeer over een Javascript app die communiceert met de server-side. De applicatie zelf heeft client-side ook een model en als daarop aanpassingen worden gedaan zouden die in een view weergegeven moeten worden. Als je dan dus alleen een bepaald onderdeel opnieuw vult is dat onderdeel dus een view (en komen we op mijn eerste oplossing).

[Makkelijk]

Als je weet wat je gaat vullen kun je met bijvoorbeeld jQuery de .text() methode gebruiken, dat is razendsnel. Ik werk als het echt om performance gaat vaak met DOM templates die ik onload uit de DOM haal, opsla en zo vaak kloon als ik zeker weet dat ik ze nodig heb. Tabelrijen bijvoorbeeld. Het is een beetje vies, maar het is wel snel.

[Noork]

Je zou eens kunnen kijken naar iets als backbone.js. Dat is geschikt als 'backone' voor een mvc applicatie. Volgens mij is dit niet iets wat je wilt oplossen door tig selectors en spaghetti te moeten maken in jQuery.

[Makkelijk]

Noork schreef op zondag 10 april 2011 @ 13:24:
Je zou eens kunnen kijken naar iets als backbone.js. Dat is geschikt als 'backone' voor een mvc applicatie. Volgens mij is dit niet iets wat je wilt oplossen door tig selectors en spaghetti te moeten maken in jQuery.

Backbone.js doet veel, maar lost nou net zijn probleem niet op. De render functie van de view moet je nog steeds zelf implementeren. Voorbeeld uit de documentatie:

code:

var Bookmark = Backbone.View.extend({
  render: function() {
    $(this.el).html(this.template(this.model.toJSON()));
    return this;
  }
});

Op die manier implementeren wil hij nou juist niet!
Verder is backbone.js natuurlijk wel geniaal.

[ Voor 3% gewijzigd door Makkelijk op 10-04-2011 13:34 ]

[Verwijderd]

Onlangs heb ik een clientside app opbasis van het MVC principe gemaakt en uiteindelijk hield ik een groot aantal compacte 'widgets' over van max 25 regels code per stuk. Het is jammer dat er op het internet nog niet zoveel over clientside mvc te vinden is want het is een erg fijne manier van ontwikkelen. In de meeste voorbeelden wordt de data in de dom zelf opgeslagen als strings (yuck), of via een hack als jquery.data aan een dom element gekoppeld. Als oo programmeur voelt dit allemaal wat raar aan, de dom is immers enkel een presentatie van het datamodel. Een adres object heeft bv mogelijk twee representaties: een set divs voor het tonen en een form voor het wijzigen. Dit zijn dus twee losse widgets welke beide worden gevoed met de zelfde data.

Je geeft zelf de beste oplossing dus eigenlijk al weer, door zowel de granulariteit van de views en modellen te verhogen hoef je enkel de dom nodes te updaten welke beïnvloed worden door de betreffende model wijziging. Let wel, een hoge granulariteit betekend ook extra overhead tgv het event systeem, het blijft dus altijd een afweging. Een model voor elke karakter in string zou in meeste gevallen zot zijn, doch als je een wysiwyg teksteditor maakt zou het mogelijk nodig kunnen zijn.

Als ik het mij goed herinner geeft backbone.js je de mogelijkheid om te achterhalen welke attributen van een model gewijzigd zijn. Dit geeft je wat meer opties dan enkel een changed event. Zo hoef je bv. niet de hele lijst op nieuw te generen als de ordening is gewijzigd. Hoe je de dom wijzigt is maar net wat je zelf fijn vindt, er zijn zoveel opties (createElement, innerHTML, jquery, etc).

[ Voor 12% gewijzigd door Verwijderd op 13-04-2011 04:25 ]