Un paio di anni fa ho creato IBDOM: http://ibdom.sf.net/ | A partire da dicembre 2009, supporta l'associazione jQuery se lo si ottiene direttamente dal trunk.
$("#foo").injectWith(collectionOfJavaScriptObjects);
o
$("#foo").injectWith(simpleJavaScriptObject);
Inoltre, ora puoi mettere tutti i marcatori "data: propName" negli attributi class = "data: propName altri nomi di classe", così non devi sporcare il contenuto della tua applicazione con quei marcatori.
Devo ancora aggiornare un po 'della documentazione per riflettere i miei recenti miglioramenti, ma ho varie versioni di questo framework in produzione dal 2007.
Agli scettici di questa domanda:
Ai tempi in cui Microsoft inventò con IE5 quello che ora conosciamo come XmlHttpRequest e il pattern "ajax", parte della promessa dietro a questo era di scambiare puramente dati tra un browser web e il server. Quei dati dovevano essere incapsulati in XML, perché nel 1999/2000, XML era semplicemente così caldo. Oltre a recuperare un documento xml sulla rete con un meccanismo di richiamata, il componente MSXML ActiveX di MS supportava anche un'implementazione pre-bozza di ciò che ora conosciamo come XSL-T e XPath.
La combinazione del recupero di HTTP / XML, XPath e XSL-T, ha offerto agli sviluppatori una straordinaria creatività per creare ricchi "documenti" che si comportavano come "applicazioni", puramente inviando e, cosa più importante, recuperando dati dal server.
Perché questo è un modello utile? Dipende da quanto è complessa la tua interfaccia utente e da quanto tieni alla sua manutenibilità.
Quando costruisci un'interfaccia con marcatura semantica visivamente molto ricca con CSS avanzato, l'ultima cosa che vuoi fare è tagliare pezzi di markup in "mini-controller / viste", solo così puoi .innerHTML un frammento di documento nel principale documento, ed ecco perché.
Un principio fondamentale per mantenere gestibile un'interfaccia utente avanzata html / css è preservarne la convalida almeno durante la fase attiva di sviluppo. Se il tuo markup è convalidato, puoi concentrarti sui tuoi bug CSS. Ora, se frammenti di markup finiscono per essere iniettati durante le varie fasi dell'interazione con l'utente, diventa tutto molto ingombrante da gestire e l'intera faccenda diventa fragile.
L'idea era di avere tutti i costrutti dell'interfaccia utente di markup in un unico documento, recuperare SOLO DATI sulla rete e utilizzare un framework solido che per lo meno inietterà semplicemente i tuoi dati nei tuoi costrutti di markup e al massimo replicherà i costrutti di markup che hai contrassegnato come ripetibile.
Questo era possibile con XSL-T e XPath in IE5 +, ma praticamente senza altri browser. Alcuni framework di browser F / OSS si sono dilettati con XPath, ma non è ancora qualcosa su cui possiamo fare affidamento.
Allora qual è la prossima cosa migliore per ottenere tale schema? IBDOM. Ottieni dati dal tuo server, inseriscili nel tuo documento. senza sforzo.