Come dovrei strutturare la mia app Web per la compatibilità del browser?

Question

Come dovrei strutturare la mia app Web per la compatibilità del browser?

#1 da (1 voti)

0

Vogliamo essere in grado di implementare la compatibilità cross-browser ignorando markup, script e stili solo laddove necessario. Vogliamo evitare di bifare tutto ciò che viene inviato al browser, come è stato fatto in passato!

Questo mi ha portato a una struttura di directory con una cartella per "pagina", con markup "master", file di script e di stile e le relative sostituzioni, una per browser. I nomi dei file, sia master che overrides, sarebbero gli stessi da cartella a cartella, e il codice che li collegava tutti insieme può essere condiviso (tutte le risorse pertinenti possono essere inserite con url relativi).

MyPage(folder)
|--Index.aspx
|--Markup.xsl
|--Markup_ie11.xsl
|--Scripts.js
|--Scripts_ie11.js
|--Styles.css
|--Styles_ie11.js
AnotherPage
|--Index.aspx
|--Markup.xsl
|--Markup_ie11.xsl
|--Scripts.js
|--Scripts_ie11.js
|--Styles.css
|--Styles_ie11.js

Ho un progetto di test con tutto ciò che funziona bene, ma sono molto nervoso riguardo a tanti file con lo stesso nome e il nome del file da solo non dà alcun indizio sul suo scopo. Tuttavia, rispetto alla nostra vecchia organizzazione basata sul tipo di file, saltano fuori alcuni vantaggi: i file su cui probabilmente lavorerai insieme sono archiviati insieme. L'albero delle cartelle è piatto. I nomi delle cartelle sono molto più significativi e ho meno bisogno di cercare. Ci sono 1/8 del numero di percorsi hardcoded nell'applicazione (script, stili e markup vengono inseriti con collegamenti relativi).

Qualcuno può pensare a un motivo per non farlo ???

directory-structure project-structure

posta bbsimonbb 22.07.2015 - 17:24

fonte

1 risposta

Leggi altre domande sui tag directory-structure project-structure

Se tutto dovrebbe essere un oggetto in Java (tranne i tipi primitivi), non è questo in contraddizione con il punto di staticità? [duplicare] Super classe mancante dalle dipendenze potrebbe lanciare NullPointerException java

score 1 · Answer 1

Can anyone think of a reason not to do this ?

Alcuni molto, molto grandi: per prima cosa, i browser non saranno in grado di memorizzare tutti questi file in modo efficace se le tue pagine non fanno riferimento allo stesso URI assoluto.

Vale a dire, se hai:

page1/
  index.htm  -- references script.js as "/page1/script.js"
  script.js
page2/
  index.htm  -- references script.js as "script.js"
  script.js

... entrambi i file .htm si riferiscono solo alle loro copie locali di script.js e ora hai il problema che chiunque venga sul sito dovrà scaricare copie separate di ogni script.js per ogni pagina che visitano .

Questo ti costerà più larghezza di banda, e riempirà la cache del browser degli utenti e spingerà fuori altre cose.

Ma peggiora.

Ora, gestisci più copie dello stesso script in più posizioni. Questo ha un sovraccarico cognitivo e tecnico: se qualcuno viene assunto, non si renderanno conto che ogni copia separata dello script deve essere aggiornata quando vengono apportate modifiche, e si avrà un numero di copie del script nel tuo repository del codice sorgente, che diventerà un disastro solo con il passare del tempo.

Questa è una dozzina di cattive idee.

È anche una cattiva idea mantenere script completamente separati per i principali browser. Questo estende il tuo codice e aumenta i costi di manutenzione, per non parlare del costo aggiuntivo della larghezza di banda di avere un sacco di file di grandi dimensioni da inviare ai browser (che ti causeranno dolore se utilizzi una cache del server locale). Invece, dovresti astrarre tutto il codice specifico del browser in un file singolo (o un numero di file molto piccoli, ciascuno per una determinata unità logica di codice) in cui il codice specifico che gestisce le differenze del browser è vicino al codice che devono eseguire.

Questo è il modo in cui letteralmente ogni framework JavaScript e CSS viene scritto, e per una buona ragione: Riduce al minimo le dimensioni del codice e semplifica la manutenzione, che consente di risparmiare denaro a lungo termine.

Qualsiasi altro approccio è sbagliato.