Hmm, vi verkar inte vara på samma bana. Jag försöker förklara lite mer konkret.
Citat:
Ursprungligen postat av randis
(Inlägg 20399867)
Ja man får väl väga de 100-delar man tjänar på ett normalstort dokument jämfört med enkelheten att underhålla och införa ändringar när man har det med samma mallar som övriga siten.
|
Mitt förslag var aldrig att skapa en ny mall för Ajax-anropen utan att använda den befintliga Html-koden som levereras av servern när man går in på sidan. Låt oss säga att vi har sidan /messages, i Html:n finns fliksystemet och om vi väljer ut en av flikarna skulle innehållet i den kunna se ut såhär:
HTML-kod:
<h3>Skickade meddelanden</h3>
<ul id="sent-messages">
<li class="template">
<span class="date"></span>
<span class="title"></span>
[...]
</li>
</ul>
Man kan också tänka sig att servern skickar med dom n senaste posterna när man går in på /messages om man vill använda progressive enhancement för SEO-syften till exempel. Jag har inte sett någon nämna det i den här tråden men det är hur som helst möjligt.
För att fylla sidan med meddelanden anropar vi servern med ett Ajax-anrop. När svaret levererats fyller vi vyn med innehåll och det gör vi genom att klona templaten, loopa igenom svaret och för varje post använder vi klonen genom att lägga till innehåll i respektive placeholder (.date, .title etc). Sedan lägger vi till klonen i en container som inte är kopplad till DOM-trädet. Först när loopen är klar lägger vi till containern på sidan. Ja, klienterna får jobba lite mer. Fördelarna är som jag skrev förut att man kan ändra struktur i vyerna, använda olika templates på olika ställen men fortsätta använda samma metod som hämtar data utan att behöva ändra i nån logik. Den här lösningen passar kanske inte för alla scenarion men det är det inte mycket som gör. Så länge det inte finns några särskilda krav tycker jag att det här är en bra lösning.
Citat:
Ursprungligen postat av randis
(Inlägg 20399867)
Vad du inför genom att låta javascript hantera data är ytterligare än felkälla då du först ska låta serversidan hantera och formater datan, och sedan ska den hanteras ytterligare en gång på klienten med javascript.
|
Servern hanterar inte datan förutom att göra den till JSON. Använder man en JSON-serialiserare behöver man inte tänka på den biten. Man kan låta en Html-sida, Flash, Silverlight eller ngn annan form av app anropa servern om den bara returnerar data. Det är så jag vill ha det. Bakas Html in i svaret blir det mycket krångligare att hantera det. Antar att man kan säga att jag ser Ajax-metoderna som en WebService där det brukar vara upp till frågeställaren att bestämma hur svaret ska formateras/presenteras.
Citat:
Ursprungligen postat av randis
(Inlägg 20399867)
Jag kan inte föreställa mig när JSON-data innebär fördelar när innehållet i en hel div ska bytas ut. Ett tu tre vill du ha en flik som heter almanacka eller något som inte passar med de satta UL-listorna med satta klasser. Då måste du arbeta på flera ställen istället för att bara skapa en ny controller och template för serversidan som genererar hela innehållet åt dig. Nya javascript och jobbig logik på klientsidan behövs inte. Bara en ny flik som gör en korrekt httprequest behövs.
|
Jag ser Ajax som ett sätt att transportera data och gärna så koncist som möjligt så ja, det stämmer. Någon tipsade om ett Mustache tidigare och det såg ju ut att vara smidigt.
Citat:
Ursprungligen postat av randis
(Inlägg 20399867)
Du skapar dessutom möjligheter för de som inte har javascript att komma åt sidan genom att göre en include på serversidan.
|
Se ovan (progressive enhancement). Det är inte ett problem. |
