Harrastin joskus pentuna viimeksi web-sivujen tekoa ja muuta niihin liittyvää. Silloin edes PHP ei ollut vielä vakiinnuttanut asemaansa, joten käsitykseni nykyään käytettävistä olevista työkaluista ovat vajavaiset. Nyt kuitenkin kiinnostus tämän harrastuksen uudelleen herättämiseen on alkanut muodostua. Kuulemma HTML5 ja CSS3 ovat sen verran vahvoja, että ne kannattaa ainakin sisäistää. Mitkäs muut tekniikat ovat niitä tämän päivän sanoja, joihin kannattaa perehtyä? Pikaisella googletuksella en löytänyt kunnon yhteenvetoa aiheesta, joten jos joku voisi heitellä vinkkejä, niin olisin todella tyytyväinen.
Html5 kehitykseen käsittääkseni kuuluu vahvasti mukaan javascript, eli sitä kannattaa ainakin opetella. Html5 ei ole tainnut vielä ihan satasella lyödä läpi, mutta vallalla on mielipide, et se on tulevaisuudessa "se" juttu.
Palvelinpuolen wep-ohjelmointiin on vaihtoehtoja, mutta PHP taitaa olla parhaillaan suosituin. Ruby, python, asp on myös melko suosittuja. Ja jokaisella tietysti oma suosikkinsa :)
No mitenkään pois sulkematta mainitsemiasi asioita, niin jQuery:n käyttö, ja siinä samalla erilaiset ajax-lataukset auttavat saamaan webisivusta enemmän työpöytäsovelluksen tyylisen. Varsinkin ajaxin oikeanlaisella käytöllä saadaan usein käyttökokemus paljon kivemmaksi kuin ainaisella koko sivun uudelleen lataamisella. Käyttäjälle on myös selkeämpää, kun esim. tuotesivulla eriarvoiset tuotetiedot on jaettuna vaikkapa välilehtiin:
http://jqueryui.com/tabs/
Tai että ylläpitotyökaluissa sivujen järjestystä voi vaihtaa sivuja raahaamalla:
http://jqueryui.com/sortable/
edit:
Jonkin verran kannattaa myös paneutua käyttöliittymäsuunnitteluun, sillä vaikka valmiita työkaluja onkin paljon, saa nillä liian helposti käyttöliittymästä luotua erittäin epäselvän.
Eli Lebe:n kertoma ajax tekniikka, vaatii myös jonkinlaista palvelinpuolen koodia. Tiivistettynä nykyajan wep sovellukset osaavat keskustella / vaihtaa tietoa keskenään (selain / serveri) ilman että tapahtuu sivun uudelleen lataamista.
Edit. Ja näistä tiedonvaihdos tekniikoista suosituin (ehkä ainoa, vai miten xml?) on json tietotyyppi.
Runeberg:Ajax ei muuten vaadi minkäänlaista "palvelinpuolen koodia" vaan sillä voi latailla ihan staattisia html/json/xml/yms. tiedostojakin siinä missä palvelinsoftalla luotuja tiedostoja.
Riippuen alla olevasta järjestelmästä niin itse olen käyttänyt ihan valmiiksi (php:lla) muotoiltua html-sisältöä jsonin ja xml:n (jota tietenkin html myös on) sijaan, jolloin samat sisällöt voi liittää helposti ilman ajaxia ja käyttää samalla samaa tapaa myös ajaxin kanssa. Tietenkin tiedonsiirron määrän kustannuksella nipistetään tuotantoajassa.
Lebe80 kirjoitti:
Riippuen alla olevasta järjestelmästä niin itse olen käyttänyt ihan valmiiksi (php:lla) muotoiltua html-sisältöä jsonin ja xml:n (jota tietenkin html myös on) sijaan, jolloin samat sisällöt voi liittää helposti ilman ajaxia ja käyttää samalla samaa tapaa myös ajaxin kanssa.
Tämä, itsekkin olen noin muutamassa hommassa tehnyt ja miettinyt onko tässä mitään järkeä. Perustellut itselleni tämmöisen ratkaisun lähinnä laiskuudella tehdä "kahta eri" tapaa tuoda sama asia esille. Luultavasti tähänkin on olemassa parempia ratkaisuja, mutta koska oma tarve on ollut niin vähäistä tuon osalta niin en ole käyttänyt siihen "turhaa" aikaa vaan antanut ajaxin hakea html:llä muotoiltua sisältöä..
t0ll0 kirjoitti:
Lebe80 kirjoitti:
Riippuen alla olevasta järjestelmästä niin itse olen käyttänyt ihan valmiiksi (php:lla) muotoiltua html-sisältöä jsonin ja xml:n (jota tietenkin html myös on) sijaan, jolloin samat sisällöt voi liittää helposti ilman ajaxia ja käyttää samalla samaa tapaa myös ajaxin kanssa.
Tämä, itsekkin olen noin muutamassa hommassa tehnyt ja miettinyt onko tässä mitään järkeä. Perustellut itselleni tämmöisen ratkaisun lähinnä laiskuudella tehdä "kahta eri" tapaa tuoda sama asia esille. Luultavasti tähänkin on olemassa parempia ratkaisuja, mutta koska oma tarve on ollut niin vähäistä tuon osalta niin en ole käyttänyt siihen "turhaa" aikaa vaan antanut ajaxin hakea html:llä muotoiltua sisältöä..
Lebe80 kirjoitti:
Riippuen alla olevasta järjestelmästä niin itse olen käyttänyt ihan valmiiksi (php:lla) muotoiltua html-sisältöä jsonin ja xml:n (jota tietenkin html myös on) sijaan, jolloin samat sisällöt voi liittää helposti ilman ajaxia ja käyttää samalla samaa tapaa myös ajaxin kanssa. Tietenkin tiedonsiirron määrän kustannuksella nipistetään tuotantoajassa.
Yhtäkkiä asiakas sanoo että haluaa samat tiedot mobiiliin, sitten ohjelmoitte uudet spesifiset palvelinpuolenhässäkät, sen sijaan että olisi valmis XML/JSON- pohjainen tietolähde, mistä saisitte parametrein haettua strukturoitua dataa ja parsittua vaivatta liittymään kuin liittymään.
qeijo kirjoitti:
t0ll0 kirjoitti:
Lebe80 kirjoitti:
Riippuen alla olevasta järjestelmästä niin itse olen käyttänyt ihan valmiiksi (php:lla) muotoiltua html-sisältöä jsonin ja xml:n (jota tietenkin html myös on) sijaan, jolloin samat sisällöt voi liittää helposti ilman ajaxia ja käyttää samalla samaa tapaa myös ajaxin kanssa.
Tämä, itsekkin olen noin muutamassa hommassa tehnyt ja miettinyt onko tässä mitään järkeä. Perustellut itselleni tämmöisen ratkaisun lähinnä laiskuudella tehdä "kahta eri" tapaa tuoda sama asia esille. Luultavasti tähänkin on olemassa parempia ratkaisuja, mutta koska oma tarve on ollut niin vähäistä tuon osalta niin en ole käyttänyt siihen "turhaa" aikaa vaan antanut ajaxin hakea html:llä muotoiltua sisältöä..
Lebe80 kirjoitti:
Riippuen alla olevasta järjestelmästä niin itse olen käyttänyt ihan valmiiksi (php:lla) muotoiltua html-sisältöä jsonin ja xml:n (jota tietenkin html myös on) sijaan, jolloin samat sisällöt voi liittää helposti ilman ajaxia ja käyttää samalla samaa tapaa myös ajaxin kanssa. Tietenkin tiedonsiirron määrän kustannuksella nipistetään tuotantoajassa.
Yhtäkkiä asiakas sanoo että haluaa samat tiedot mobiiliin, sitten ohjelmoitte uudet spesifiset palvelinpuolenhässäkät, sen sijaan että olisi valmis XML/JSON- pohjainen tietolähde, mistä saisitte parametrein haettua strukturoitua dataa ja parsittua vaivatta liittymään kuin liittymään.
Yhtäkkiä asiakkaalle tehdään tuntilaskutuksella muutostöitä.
Näppäränä jamppanahan nuo muotoilisi tosiaan vaikka aluksi css:llä mobiililaitteille erinäköisiksi.
Muutenkin mobiilisivut tuntuvat jo menevän vähän ohitse, varsinkin kun laitteiden näyttöjen tarkkuudet kasvavat jo siihen tahtiin, että mieluummin sitä käyttää jo Samsung Galaxy SIII:lla mieluummin työpöytäsivuja kuin rampautettuja mobiilisivuja.
Lebe80 kirjoitti:
Riippuen alla olevasta järjestelmästä niin itse olen käyttänyt ihan valmiiksi (php:lla) muotoiltua html-sisältöä jsonin ja xml:n (jota tietenkin html myös on)
Html ei ole xml:ää. Xhtml olisi. Xml ja html ovat molemmat sgml:n johdannaisia mutta saman sukupuun eri haaroja.
Lebe80 kirjoitti:
qeijo kirjoitti:
Yhtäkkiä asiakas sanoo että haluaa samat tiedot mobiiliin, sitten ohjelmoitte uudet spesifiset palvelinpuolenhässäkät, sen sijaan että olisi valmis XML/JSON- pohjainen tietolähde, mistä saisitte parametrein haettua strukturoitua dataa ja parsittua vaivatta liittymään kuin liittymään.
Yhtäkkiä asiakkaalle tehdään tuntilaskutuksella muutostöitä.
Näppäränä jamppanahan nuo muotoilisi tosiaan vaikka aluksi css:llä mobiililaitteille erinäköisiksi.
Muutenkin mobiilisivut tuntuvat jo menevän vähän ohitse, varsinkin kun laitteiden näyttöjen tarkkuudet kasvavat jo siihen tahtiin, että mieluummin sitä käyttää jo Samsung Galaxy SIII:lla mieluummin työpöytäsivuja kuin rampautettuja mobiilisivuja.
Uskoisin mobiilisivujen hyödyllisyyden riippuvan ihan siitä, miten hyvin tavallinen sivusto on suunniteltu. Jos se on täynnä turhaa roinaa, hirveän pientä tekstiä ja flash-mainoksia joka reunalla, niin erilliset mobiilisivut on pakko tehdä. Sama pätee myös noihin "upokkeisiin", eli jos niiden rakenne on puhdas, niin tietysti on hyvät tsäänssit voida käyttää niitä muissakin implementaatioissa kuin vain siinä ensimmäisessä.
Lebe80 kirjoitti:
No mitenkään pois sulkematta mainitsemiasi asioita, niin jQuery:n käyttö, ja siinä samalla erilaiset ajax-lataukset auttavat saamaan webisivusta enemmän työpöytäsovelluksen tyylisen. Varsinkin ajaxin oikeanlaisella käytöllä saadaan usein käyttökokemus paljon kivemmaksi kuin ainaisella koko sivun uudelleen lataamisella. Käyttäjälle on myös selkeämpää, kun esim. tuotesivulla eriarvoiset tuotetiedot on jaettuna vaikkapa välilehtiin:
http://jqueryui.com/tabs/Tai että ylläpitotyökaluissa sivujen järjestystä voi vaihtaa sivuja raahaamalla:
http://jqueryui.com/sortable/
JQuery UI on hirveää limapurkkaa. Edes tavallinen button-widgetti ei toimi ilman javascriptiä. Suosittelisin tutustumaan Twitter Bootstrapiin tai johonkin vastaavaan, jotka ovat paitsi paljon JUI:ta kattavampia, niin myös toimivat ilman js-tukea.
Twitter Bootstrapin widgettien ulkoasu on myös vähemmän bloatti. Noiden gui-kehyksien css:n muokkaus voi olla aika työlästä, jos puhutaan muusta kuin yksinkertaisesta värien vaihtamisesta.
The Alchemist kirjoitti:
Html ei ole xml:ää. Xhtml olisi. Xml ja html ovat molemmat sgml:n johdannaisia mutta saman sukupuun eri haaroja.
Html4 ja alaspäin on kyllä SGML:n johdannaisia, mutta HTML5 ei enää ole.
Pythonilla ja jollain sille tehdyllä frameworkilla, esim. Django tai kevyemmällä, kuten bottle.py, ja JS + CSS + HTML5 yhdistelmällä pärjää hyvin melkein kaikessa web-sivustoihin liittyvässä.
Lebe80 kirjoitti:
qeijo kirjoitti:
t0ll0 kirjoitti:
Lebe80 kirjoitti:
Riippuen alla olevasta järjestelmästä niin itse olen käyttänyt ihan valmiiksi (php:lla) muotoiltua html-sisältöä jsonin ja xml:n (jota tietenkin html myös on) sijaan, jolloin samat sisällöt voi liittää helposti ilman ajaxia ja käyttää samalla samaa tapaa myös ajaxin kanssa.
Tämä, itsekkin olen noin muutamassa hommassa tehnyt ja miettinyt onko tässä mitään järkeä. Perustellut itselleni tämmöisen ratkaisun lähinnä laiskuudella tehdä "kahta eri" tapaa tuoda sama asia esille. Luultavasti tähänkin on olemassa parempia ratkaisuja, mutta koska oma tarve on ollut niin vähäistä tuon osalta niin en ole käyttänyt siihen "turhaa" aikaa vaan antanut ajaxin hakea html:llä muotoiltua sisältöä..
Lebe80 kirjoitti:
Riippuen alla olevasta järjestelmästä niin itse olen käyttänyt ihan valmiiksi (php:lla) muotoiltua html-sisältöä jsonin ja xml:n (jota tietenkin html myös on) sijaan, jolloin samat sisällöt voi liittää helposti ilman ajaxia ja käyttää samalla samaa tapaa myös ajaxin kanssa. Tietenkin tiedonsiirron määrän kustannuksella nipistetään tuotantoajassa.
Yhtäkkiä asiakas sanoo että haluaa samat tiedot mobiiliin, sitten ohjelmoitte uudet spesifiset palvelinpuolenhässäkät, sen sijaan että olisi valmis XML/JSON- pohjainen tietolähde, mistä saisitte parametrein haettua strukturoitua dataa ja parsittua vaivatta liittymään kuin liittymään.
Yhtäkkiä asiakkaalle tehdään tuntilaskutuksella muutostöitä.
Näppäränä jamppanahan nuo muotoilisi tosiaan vaikka aluksi css:llä mobiililaitteille erinäköisiksi.
Muutenkin mobiilisivut tuntuvat jo menevän vähän ohitse, varsinkin kun laitteiden näyttöjen tarkkuudet kasvavat jo siihen tahtiin, että mieluummin sitä käyttää jo Samsung Galaxy SIII:lla mieluummin työpöytäsivuja kuin rampautettuja mobiilisivuja.
Kyllä jatkokehitys ilman refaktorointia ja duplikointi on laskutettavaa työtä.
Eikä tämä avaa mahdollisuuksia ainoastaan HTML:llä toteutetuihin mobiilisovelluksiin, vaan myös muihin käyttötarkoituksiin, WP7/8, Androidit etc.
The Alchemist kirjoitti:
Lebe80 kirjoitti:
qeijo kirjoitti:
Yhtäkkiä asiakas sanoo että haluaa samat tiedot mobiiliin, sitten ohjelmoitte uudet spesifiset palvelinpuolenhässäkät, sen sijaan että olisi valmis XML/JSON- pohjainen tietolähde, mistä saisitte parametrein haettua strukturoitua dataa ja parsittua vaivatta liittymään kuin liittymään.
Yhtäkkiä asiakkaalle tehdään tuntilaskutuksella muutostöitä.
Näppäränä jamppanahan nuo muotoilisi tosiaan vaikka aluksi css:llä mobiililaitteille erinäköisiksi.
Muutenkin mobiilisivut tuntuvat jo menevän vähän ohitse, varsinkin kun laitteiden näyttöjen tarkkuudet kasvavat jo siihen tahtiin, että mieluummin sitä käyttää jo Samsung Galaxy SIII:lla mieluummin työpöytäsivuja kuin rampautettuja mobiilisivuja.
Uskoisin mobiilisivujen hyödyllisyyden riippuvan ihan siitä, miten hyvin tavallinen sivusto on suunniteltu. Jos se on täynnä turhaa roinaa, hirveän pientä tekstiä ja flash-mainoksia joka reunalla, niin erilliset mobiilisivut on pakko tehdä. Sama pätee myös noihin "upokkeisiin", eli jos niiden rakenne on puhdas, niin tietysti on hyvät tsäänssit voida käyttää niitä muissakin implementaatioissa kuin vain siinä ensimmäisessä.
My point exactly.
The Alchemist kirjoitti:
Lebe80 kirjoitti:
No mitenkään pois sulkematta mainitsemiasi asioita, niin jQuery:n käyttö, ja siinä samalla erilaiset ajax-lataukset auttavat saamaan webisivusta enemmän työpöytäsovelluksen tyylisen. Varsinkin ajaxin oikeanlaisella käytöllä saadaan usein käyttökokemus paljon kivemmaksi kuin ainaisella koko sivun uudelleen lataamisella. Käyttäjälle on myös selkeämpää, kun esim. tuotesivulla eriarvoiset tuotetiedot on jaettuna vaikkapa välilehtiin:
http://jqueryui.com/tabs/Tai että ylläpitotyökaluissa sivujen järjestystä voi vaihtaa sivuja raahaamalla:
http://jqueryui.com/sortable/JQuery UI on hirveää limapurkkaa. Edes tavallinen button-widgetti ei toimi ilman javascriptiä. Suosittelisin tutustumaan Twitter Bootstrapiin tai johonkin vastaavaan, jotka ovat paitsi paljon JUI:ta kattavampia, niin myös toimivat ilman js-tukea.
Twitter Bootstrapin widgettien ulkoasu on myös vähemmän bloatti. Noiden gui-kehyksien css:n muokkaus voi olla aika työlästä, jos puhutaan muusta kuin yksinkertaisesta värien vaihtamisesta.
Jep, lähinnä tuossa olikin vain nopeat valmiit esimerkit erilaisista elementeistä, joilla saadaan webisivulle työpöytämaisia elementtejä, ottamatta siis kantaa millä ja miten ne olivat tehty.
qeijo kirjoitti:
Yhtäkkiä asiakas sanoo että haluaa samat tiedot mobiiliin, sitten ohjelmoitte uudet spesifiset palvelinpuolenhässäkät, sen sijaan että olisi valmis XML/JSON- pohjainen tietolähde, mistä saisitte parametrein haettua strukturoitua dataa ja parsittua vaivatta liittymään kuin liittymään.
Miksi tekisin kokonaan uudelleen palvelinpuolenhässäkät kun pelkästään esitystapa muuttuu? Mutta toki ymmärrän pointin, varsinkin WP7/8,android etc. kohdassa, nämä asiathan kuitenkin kannattaa mitoittaa projektin mukaan ja väärin arvioidussa projektissa voi olla, että alkuvaiheen laiskuus ampuu silmille myöhemmässä vaiheessa jonka jälkeen _luultavasti_ on oppinut jotain ;)
Hieman tästä jQuery UI -asiasta sivuten: CSS3 pystyy joissakin toiminnallisuuksissa taistelemaan JavaScriptin kanssa. Selaintuki on vielä työpöytäympäristön ulkopuolella tasoltaan hieman heilahtelevaa, mutta periaatteessa yksinkertaisia kuvavierittimiä, välilehtiä ym. on mahdollista tehdä pelkällä CSS:llä. Toisaalta moinen vaatii tietyllä tavalla muotoiltua HTML-rakennetta CSS:n valitsinten rajallisuudesta johtuen (voi viitata vain lapsielementteihin tai saman tason seuraaviin elementteihin), jolloin sukset voi mennä ristiin semanttisen HTML:n kanssa. Toisaalta kun noita JavaScript-kikkareita katselee, niin niistä saattaa semanttisuus olla kaukana.
Minua on tässä lähipäivinä alkanut kiinnostaa Clojure ja ClojureScript. Clojurea voi käyttää palvelimen puolella kun taas ClojureScript käännetään JavaScriptiksi. Netistä löytyy jo esimerkkejä siitä, kuinka ClojuseScriptillä kirjoitettu koodi voi olla lopputulokseltaan nopeampaa kuin jQuery - ja samalla koodi on erittäin lyhyttä ja luettavaa. Ylipäätään juuri tämä funktionaalinen lähestymistapa ("koodi on dataa") viehättää minua huomattavasti enemmän kuin vaikkapa olio-ohjelmointi.
t0ll0 kirjoitti:
qeijo kirjoitti:
Yhtäkkiä asiakas sanoo että haluaa samat tiedot mobiiliin, sitten ohjelmoitte uudet spesifiset palvelinpuolenhässäkät, sen sijaan että olisi valmis XML/JSON- pohjainen tietolähde, mistä saisitte parametrein haettua strukturoitua dataa ja parsittua vaivatta liittymään kuin liittymään.
Miksi tekisin kokonaan uudelleen palvelinpuolenhässäkät kun pelkästään esitystapa muuttuu? Mutta toki ymmärrän pointin, varsinkin WP7/8,android etc. kohdassa, nämä asiathan kuitenkin kannattaa mitoittaa projektin mukaan ja väärin arvioidussa projektissa voi olla, että alkuvaiheen laiskuus ampuu silmille myöhemmässä vaiheessa jonka jälkeen _luultavasti_ on oppinut jotain ;)
Niin minähän peräänkuulutin juuri sitä ratkaisua jossa ei tarvitsisi luoda uudestaan koko palvelinpuolenhässäkkää.
Jos palvelin palauttaa tiedon esimerkiksi HTML taulukon muodossa sisältäen jopa tyylimäärittelyitä ja muuta sälää, niin sehän ei sovellu kovin hyvin muuhun käyttöön. Vastaavasti jos se olisi esim. XML muodossa, niin tätä ongelmaa ei ole.
Merri kirjoitti:
Ylipäätään juuri tämä funktionaalinen lähestymistapa ("koodi on dataa") viehättää minua huomattavasti enemmän kuin vaikkapa olio-ohjelmointi.
Sama täällä. Tutustuin Clojureen kuukausia sitten, mutta olen taas palannut siihen. Clojurella kirjoitettu sivusto toimii huomattavasti nopeammin kuin esim. PHP:llä tehty. Ja tosiaan funktionaalinen ohjelmointi on mukavan erilainen lähestymistapa ohjelmointiin kuin esim. olio-ohjelmointi tai perinteinen imperatiivinen C-ohjelmointi.
Clojurelle pitänee jossain kohtaa perustaa oma keskustelunsa. Haun mukaan tämä mainintani oli vasta toinen kyseiselle ohjelmointikielelle Putkassa. Minulla on opiskelu vasta siinä vaiheessa, että lueskelen tutoriaalia lävitse ja olen vähän leikkinyt netistä löytyvällä REPL-komentorivillä yksittäisten koodirivien kanssa, joten ihan vielä en ole mitään kyhäämässä kasaan (keskustelua tahi ohjelmaa).
Toisaalta Clojure ei ole vielä paras vaihtoehto uudelle opettelijalle, koska HTML5, CSS ja JavaScript tarvitsee tietää ennen kuin Clojuresta on iloa selainpuolen webkehityksessä. Eeppisintä tulevaisuudenkuvaa lienisi natiivi ClojureScript-tuki kaikissa selaimissa...
Clojurella en ole vielä niin paljoa koodaillut, että voisin keskustella paljoakaan asiasta, mutta olen testannut tehdä Clojurelle löytyvällä noir-nimisellä frameworkilla pienen blogin tyyppisen sivuston. Clojurella en ole "perinteisiä" ohjelmia tehnyt ollenkaan, siihenkin voisi kyllä tutustua.
Funktionaalinen ohjelmointi on muuten eri asia kuin "koodi on dataa" -periaate. Jälkimmäistä ominaisuutta nimittävät maailmalla homoikonisuudeksi (engl. homoiconicity). Vaikka Clojure on sekä funktionaalinen että homoikoninen kieli, eivät kaikki funktionaaliset kielet ole molempia.
Tämä ihan vain ystävällisenä vinkkinä, jos tarkasti haluatte asioista puhua. Tässä ketjussa tämä ei ole kovin oleellista, joten ei sitten enempää.
qeijo kirjoitti:
Niin minähän peräänkuulutin juuri sitä ratkaisua jossa ei tarvitsisi luoda uudestaan koko palvelinpuolenhässäkkää.
Jos palvelin palauttaa tiedon esimerkiksi HTML taulukon muodossa sisältäen jopa tyylimäärittelyitä ja muuta sälää, niin sehän ei sovellu kovin hyvin muuhun käyttöön. Vastaavasti jos se olisi esim. XML muodossa, niin tätä ongelmaa ei ole.
Siis, vaikka palvelin palauttaa sisällön html-muodossa niin ei ole ongelmaa vaihtaa sitä toiseen muotoon palvelimen päässä juuri siihen mihin käyttäjä ja sen päätelaite sitä haluaa. Tiedon hakeminen ja sen esittäminen on kuitenkin kaksi eri asiaa. Erona ymmärtääkseni tässä on se kummassa päässä esittämistavan muutos tehdään ja "työ" pitää joka tapauksessa tehdä jommassakummassa päässä..
edit, ja edelleen olen samaa mieltä, että esim XML on laajemmissa projekteissa kätevämpi tapa, mutta käytettävä tekniikka kuitenkin sovelletaan ja mitoitetaan projektin luonteen mukaan sopivaksi.
Nyt kun javascriptin rooli on jatkuvassa kasvussa, pitää kiinnittää enemmän huomiota myös javascript -koodin ylläpidettävyyteen ja arkkitehtuuriin. Itse suosin tällä hetkellä MVVM patternin käyttöä KnockOutJS:llä (ihan tutustumisen arvoinen).
Aihe on jo aika vanha, joten et voi enää vastata siihen.