L'uso eccessivo di tagli personalizzati può interferire con l'esternalizzazione dei designer html?

Question

L'uso eccessivo di tagli personalizzati può interferire con l'esternalizzazione dei designer html?

#1 da (2 voti)
#2 da (0 voti)

4

Ieri io e un amico stavamo parlando dell'uso eccessivo dei tagli personalizzati.

Creiamo tagli per tutto. Creiamo tagli in modo da includere elementi dell'interfaccia utente jQuery (schede, pulsante, ecc.) E altri elementi plug-in. Spesso li avvolgiamo in un unico componente. Usiamo taglibs in un punto che non abbiamo quasi nessun html puro all'interno del tag body.

La nostra domanda è: questa è un'abitudine sana? Immagina due situazioni:

1) Assumiamo un designer html e abbiamo il costo di un mese per imparare tutte queste cose.

2) Vogliamo esternalizzare lo sviluppo HTML, ma nessuna azienda vorrebbe che la nostra libreria taglib imparasse, O diventerebbe più costosa.

Adoriamo i taglibs come se fosse una bella scorciatoia per lo sviluppo di javascipt mentre la scriviamo solo una volta. Quali sarebbero le migliori pratiche in questo senso e cosa suggeriresti? Stiamo cercando una soluzione a prova di futuro (o un argomento che sia d'accordo con la nostra).

java web-development javascript jsp

posta Renato Gama 04.04.2012 - 02:08

fonte

2 risposte

Leggi altre domande sui tag java web-development javascript jsp

Come rappresentereste un oggetto che può essere di più tipi, quando lo memorizzate come documento in MongoDB? Costruisci strumenti per lo sviluppo di applicazioni web php, html, css, js

score 2 · Answer 1

Uno dei tuoi usi di taglibs è incapsulare JavaScript. È possibile farlo con solo un file JavaScript? (oppure un file JavaScript e un div in modo che il file JavaScript possa scrivere qualsiasi codice HTML necessario o un file JavaScript e alcuni normali campi HTML.)

JavaScript è molto potente. Ha oggetti che ti permettono di evitare di inquinare lo spazio dei nomi globale.

E no, come notato nei commenti che scrivono tagli per tutto ciò lo sta portando troppo lontano. È come se avessi scritto la tua lingua di tipo JSF senza i vantaggi della standardizzazione.

score 0 · Answer 2

"We are looking for a future-proof solution"

Suggerirei di esaminare i componenti Web. Questo, con pochi dubbi, sarebbe la direzione in cui è diretto lo sviluppo del lato client e consentirebbe una facile creazione di funzionalità lato client resuable. Sebbene il processo di standardizzazione dei componenti Web sia ancora lontano dal completamento, sono disponibili un paio di librerie, che fungono da poli-riempimenti che consente l'utilizzo del principio dei componenti Web tra i vari browser.

Polymer.js (di Google) è un esempio di questo. Hai anche Brick di Mozilla e Reagisci di Facebook.

Anche alcuni dei framework Javascript attualmente in uso forniscono la stessa idea, sebbene siano implementati tramite meccanismi diversi. In AngularJs, hai Direttive . In EmberJs hai Componenti . Ma la buona notizia è che, almeno questi due, piano per spostare la loro attuazione alle specifiche ufficiali, una volta che diventa uno standard formale. Come indicato nella documentazione per il componente Embers e per AngularJs, come annunciato nel Gruppo Polymer.js.

Tutto sommato, consiglierei di giocare con Polymer.js. Se si desidera che la funzionalità lato client sia così disaccoppiata che sia possibile esternalizzarla facilmente, perché non limitarsi a ridurre completamente la dipendenza da JSP e far sì che tale livello sia implementato utilizzando la tecnologia più adatta a questo. Sono sicuro che una società focalizzata sullo sviluppo di HTML / Client Side non avrà alcun problema a mettersi al passo con esso. È un terreno familiare:)

Potresti voler controllare questo fantastico tutorial: Guida introduttiva con componenti Web e polymer.js