Utálom, amikor CSS-el kell szívnom órákon át...

Arra ott vannak a jó CMS és template megoldások, van számos, és értem én, hogy nem natív, de ezen már túlléptünk, a weben nincs szabván, lehet válogatni a megoldások közül, vanank jól működőek, és mégjobban működőek is, meg persze szarok is, de azt nem kell használni.

________________________________
blog: http://horvathjanos.wordpress.com

Mivel ez egy JS keretrendszer, így nem csoda ha JS témában találsz róla infót ha rákeresel.

Röviden: ez egy JS keretrendszer. Struktúrált vázat, egy gerincet (ezért is az a neve, hogy backbone) ad a webes alkalmazások fejlesztéséhez. Mindezt úgy teszi, hogy lehetőséget nyújt modellek definiálására, melyek kulcs-érték párok szerint tárolnak adatokat, ezenkívül a modelleket collection-ökbe tudjuk rendezni, ezek úgymond modell listák. Lehetőséget ad nézetek, View-k definiálására. Ezek a View-k olyan objektumok melyeknek minden esetben van egy render metódusa. Ha egy nézetet renderelünk, eredményként egy HTML, potosabban DOM elemet kapunk. A view-ban definiálhatunk egyedi eseménykezelőket, kapcsolhatunk a nézethez HTML templat-et, stb. stb.
Az egész modell, collection, view hármas összekapcsolódik, olyasmi módon kell elképzelni mint egy MVC rendszert.

Az egész keretrendszer arra épít, hogy a háttérben működő szerveroldali API-hoz tudjuk kapcsolni és azzal RESTful JSON interfészen keresztül tudjuk az adatokat küldeni/fogadni, st. stb.

Hogy egy példát is mondjak, vegyünk egy ToDo alkalmazást példának:

Van modell ugye: egy teendő
Létrehozol collection-öket, pl. teendők listája, ez tárolja a modelleket.
Ilyen collection lehet több is, de most elég ez.

Van egy olyan view, hogy listaelem, ami egy modellt reprezentál a DOM-ba, pl. egy LI listaelem, ez lesz a teendő modelljének HTML megfelelője, aminek a template-je kb így néz majd ki: <li><%=name%></li>
Kell egy másik view is, amelynek egy sima <ul> a template-je. Ez csak annyit tesz, hogy a render metódusában példányosít annyi modellt, vagyis li objektumot amennyit átadunk neki egy collection-ben. Nyilván ezek a modellek a szerver oldalról érkező JSON alapján születnek meg.
Egy collection is és egy modell is tárol magában egy URL attribútumot, ez az a "cím" ami felé a REST-es kérések mennek. Lehet hívni GET, PUT, POST, DELETE kéréseket ahogy megszokhattuk.

Egy collection-re hívott fetch() metódus pl. külde egy GET kérést a szerveroldal felé, onnan pedig gondoskodni kell, hogy egy JSON objektum jöjjön vissza, amely egy listát ír le, amelyben az egyes elemek majd a modellek adatai lesznek kliens oldalon.

Na de abbahagyom, mert nem vagyok jó a magyarázásban, mutatni könnyebb lenne, meg biztos zavaros így ahogy leírtam. Lényeg, hogy nagyon jó cucc, gyorsan és szépen lehet vele dolgozni és nem lesz spagettikód a vége, hanem átgondolt rendszerezett és logikus felépítésű és jól skálázható, hordozható, átalakítható kódit kapunk, amit könnyű olvasni és X év után ránézve is könnyű felismerni, hogy mi mit csinál és miért. Számos előnye van, nincs idő meg elég hely, hogy leírjam, és szubjektív is a dolog, mert számos konkurens keretrendszer létezik, nem mindenki referálja a Backbone-t, van aki mást választ, ízlések és pofonok, és persze feladatfüggő stb.

Olvass utána, annyi tutorial van a neten a témában, hogy sosem érsz a végére!
________________________________
blog: http://horvathjanos.wordpress.com

Szakemberke, legalább ne pofázz a felnőttek dolgába, ha értelmesen egyébként sem vagy képes megnyilvánulni!

Engem a cikk különösebben nem is érdekelt, nem olvastam el.
Csak azt látom, hogy hozol itt egy ősrégi cikket és fikázol embereket, akik talán már akkor dolgoztak, amikor te még bőven a pelenkádba szartál.

"...van a mobil alkalmazás meg van a desktop alkalmazás és aki össze meri mosni a határokat..."

Amúgy gyakorlatilag ez lenne a preferenciám :) Ahelyett, hogy egy nem megfelelő eszközt pofozgatunk, hogy megoldjuk azokat a problémákat, amikre évek óta tökéletes megoldás van, inkább gyárthatnánk natív appokat, a webet meg fő irányvonal helyett megtarthatnánk failbacknek. De akkor szerencsétlen PHPistikék, akik nem tudnak komolyabbat a gányoláson kívül, sajnos csak a munkanélküli segélyért állhatnának sorba :(

Manapság már az se állja meg a helyét, hogy nem lehet up-to-date tartani a natív programokat, míg a webappok állandóan frissek, hiszen ott vannak a platform-specifikus alkalmazásboltok, amik folyamatosan terítik a frissítéseket.

És igen, én nem szeretem az ennyire gyorsan változó dolgokat, nem szeretem, ahol nincs best practice, mert ott csak káosz és fejetlenség van, és nem egy nagy élmény egy ilyen kódban túrkálni. Játszani, szórakozni jó, de nem véletlen, hogy komoly webappok alatt pl. Javát (.Net-et) szokás használni, ami kiforrott, van egy csomó know-how, irgalmatlan mennyiségű tool.

hogyan? van ket oldalad fooldal.htm meg aloldal.htm, mind a kettoben hasznalni akarod ugyanazokat a menuelemeket. Szerintem a menu.js-s be tudja tolteni mindketto. menu.htm-bol meg nem tudsz adatot kinyerni DOM-mal?