|
Tahaks teiste arvamust teemal - kas panna HTML kokku JS poolel või koostada see serveris ning see kasutajale ette sööta. Eelkõige puudutab see siis AJAXi reponse - ilus oleks nagu korralik JSON saata ning selle põhjal renderdada, samas kohati tundub aga mõistlikum siiski serveri poolel see kokku panna ja hiljem lihtsalt DOMi lükata. stackoverflow.com lehelt leidsin vastuseks, et soovitatakse serveri pool siiski kokku panna:
Miinus on muidugi asjal see, et JS poolel oleks veel erinev syntax lisaks. Millised on teie kogemused/arvamused? |
|
Nagu enamiku tarkvaraarenduse probleemide puhul tuleks siingi lähtuda DRY printsiibist: ära korda ennast. Kui sedasama HTML-i on tarvis toota nii AJAXi läbi lehte uuendades kui lehe staatilise versiooni jaoks, siis on tark hoida selleks vajalikku loogikat vaid ühes kohas. Selleks näen ma kahte varianti:
Enamik veebilehti peaks olema kättesaadavad ka ilma JavaScripti abita, sest sa ju soovid et Google su lehte indekseeriks. Samas JavaScripti-mahuka veebirakenduse puhul, mille staatiline versioon ei omaks erilist mõtet (a'la Google Mapsi peale ehitatud visuaalne tööriist), võid piirduda HTML-i genereerimisega üksnes JavaScripti poolel. Kiiruse argument on, nagu enamasti ikka, teisejärguline - selleks tuleks mõõta kas sinu konkreetsel juhul üks või teine moodus annab kiiruses võitu või mitte. Olenemata kas tegu on "klassikalise" veebi või rakendusega võib need andmed, mida kuvatakse sisseloginud kasutajale (ning mis seetõttu on ka kõige mittestaatilisemad, sest kuvatakse kõikidele kasutajatele eraldi) brauseri poole peal kokku panna - ükski robot neid indekseerima ei pea.
(Nov 09 '11 at 12:13)
Andris
|
|
Klassikalises veebis tuleks üldse võimalikult vähe javascripti kasutada (klassikaline tähendab tavalise sisu näitamist nagu kodulehtedel, foorumid, blogid jms). Juba kasvõi otsingumootorite pärast. Mitteklassikalises veebis (veebiprogrammid, siseveebid, erirakendused jms) on mu meelest just õigem kasutada lähenemist, kus server annab json objekti ja edasi töötleb seda brauser. Satun alatihti olukordadesse, kus tuleb näidata mingit infot näiteks nimekirjas ja kui kasutaja klikkab võib hiirega üle läheb objektist, siis tuleb näidata rohkem infot kui esialgu näha oli. Sellisel juhul tundub ainuõige võtta see täiendav info saadud JSON objektist ning jooksvalt html kokku laduda. Kas poleks võimalik neid kaht lähenemist niimoodi ühendada, et pritsida serverist välja HTML (või XML+XSLT), kus lisainfo on kohe olemas, aga nähtamatu (siis on vähemalt põhitekst saadav kätte ka JS-vaeguritele, sealhulgas otsimootoritele) ja vajadusel kasutatakse JS selle nähtavaks tegemiseks ja taas peitmiseks? Aga ma olen veebiprogrammeerimisega väga vähe tegelenud, nii et see võib olla ka mingi jube häkk, mille puudusi ma väheste kogemuste tõttu lihtsalt näha ei oska.
(Oct 26 '11 at 11:04)
Ahto Truu ♦♦
Saab küll neid ühendada. Nii on tehtud ka pinu avalehel. Ma proovisin leida mõtteid, et miks ma nii tahaksin pigem json-i tõmmata ja seda kasutada, aga liiga hästi ei suuda seda argumenteerida.
(Nov 03 '11 at 10:48)
Kaiko Kaur
Põhjus, miks ma pigem json-it eelistan ja html-i ei taha vastuseks kasutada on ilmselt välja kujunenud mõttemall, et server on server ja brauser on klient. Server peaks pakkuma API-t ja hoidma vajalikke faile kliendi jaoks. Server ei peaks olema liiga spetsiifiline kliendi jaoks.
(Nov 04 '11 at 10:37)
Kaiko Kaur
|
|
Kui plaanid AJAXit kasutada osaliste leheuuenduste (partial page update) jaoks, siis tagastades AJAXi päringu vastusena HTMLi saad taaskasutada seda koodi, mis sul algse lehe genereeris. Minu meelest piisav argument, et igal võimalusel kasutada AJAXi asemel AJAHi (Asynchronous JavaScript And HTML). Ma oletan ka, et HTMLi parsimine brauseri poolt on kiirem, kui JSONi parsimine Javascripti parseri poolt + Javascriptis DOM manipuleerimine. |
|
Ainukese juhusena võib välja tuua olukorra, kus üritad browseri põhist programmi võimalikult reaktiivse ning kiirena hoida. Ehk hoiad ühte WebSocketit lahti ning kannad selle kaudu kiiresti json andmeid + template üle ning paned siis browseri poolel kokku. |
