Mapping degli input variabili agli elementi dell'interfaccia utente

Naviga le tue risposte
6

Sfondo

Sviluppo di un sistema per la creazione di eBook. I dati sono altamente normalizzati. I disegni eBook sono confezionati come "temi". I temi possono essere configurati con opzioni per: caratteri, colori, alcuni layout ed elementi tematici (come i quadrati per elenchi di proiettili potrebbero diventare cerchi, esagoni o frecce).

Le opzioni sono strettamente collegate al tema. Ad esempio, un tema potrebbe solo consentire all'utente di selezionare determinati tipi di carattere, mentre un altro tema potrebbe non avere alcun elemento tematico, mentre tutti i temi potrebbero fornire opzioni per modificare il layout del numero di pagina, i colori dei temi e il contenuto per l'intestazione / piè di pagina .

La creazione di eBook è un esempio della classe generale di problemi:

The output depends on configurable options; the available options depend on a particular constraint set.

Problema

Quando un nuovo set di vincoli (ad es. tema eBook) viene creato da uno sviluppatore, le opzioni configurabili devono essere esposte come elementi dell'interfaccia utente. Gli elementi dell'interfaccia utente possono essere associati alle opzioni utilizzando un linguaggio descrittivo o XML. Ad esempio: 

<group id=”page-number”>
  <group id=”text-attribute”>
    <string name=”UserInputPage” default=”# / ##” id=”ui-page” />
    <colour name=”UserColourPrimary” id=”ui-colour-primary” />
    <select name=”UserSelectBullet” id=”ui-bullet”>
      <option id=”ui-select-square” />
      <option id=”ui-select-circle” />
    </select>
    <integer name="UserRandomSeed" min="1" max="50" id="ui-random-seed" />
  </group>
</group>
<text language="en">
  <!-- Tab name -->
  <ref id=”page-number”>Page Number</text>
  <!-- Group name -->
  <ref id=”text-attribute”>Text Attributes</text>
  <!-- Display name for select options -->
  <ref id=”ui-select-square”>Square</text>
  <ref id=”ui-select-circle”>Circle</text>
</text>

L'implementazione del tema sottostante (che sia PHP, Lua, Java o C ++) definirà, esporrà e userà variabili come: 

UserInputPage
UserColourPrimary
UserSelectBullet

Utilizzando XSLT, sarebbe ragionevolmente banale convertire la mappa sopra in widget UI sensibili che corrispondono alla definizione di variabile nell'XML.

Creando questa mappa, gli sviluppatori non hanno bisogno di creare esplicitamente l'interfaccia utente, né preoccuparsi del suo layout o della struttura dei menu. Lo sviluppatore crea una mappa delle variabili di input del software e il computer genera automaticamente l'interfaccia utente. L'interfaccia utente, in questo caso, sarà XHTML, ma potrebbe essere XUL o qualsiasi altra rappresentazione.

Confronto

I framework come Facce JavaServer sono simili a questa idea; I problemi relativi a JSF e ADF includono:

  • Troppo complesso con un sovraccarico eccessivo.
  • Spesso legato a linguaggi di implementazione specifici.
  • Gli input sono legati troppo da vicino alla loro rappresentazione finale.

Ad esempio: 

<h:inputText value="#{helloBean.name}" ... />
<af:selectOneRadio value="#{bindings.x.hints.inputValue} layout="vertical" />

Gli ingressi del pulsante di scelta verticale "selectOneRadio" non devono essere codificati in tutta l'applicazione. Invece, la rappresentazione finale dell'interfaccia utente dovrebbe essere basata su valori predefiniti intelligenti. Nell'esempio XML dalla sezione del problema, l'interfaccia utente dovrebbe generare due pulsanti di opzione perché ci sono due input nell'elemento select . Tre elementi genererebbero un menu a discesa. Un elemento creerebbe una casella di controllo.

Allo stesso modo, <string> potrebbe generare uno di:

Allo stesso modo, <integer> potrebbe generare un cursore o un campo di input semplice. La convalida verrà eseguita altrove.

Con l'HTML, l'aspetto e l'aspetto finali dell'elemento sarebbero guidati dai CSS, proprio come con JSF.

correlati

Parzialmente correlato:

Domanda

Quale approccio prenderesti per creare una definizione di mappa così variabile che possa generare un codice UI?

    
posta Dave Jarvis 06.09.2013 - 18:43
fonte

1 risposta

0

Innanzitutto, sono d'accordo sul fatto che la maggior parte delle soluzioni già disponibili sembra molto complessa e legata a implementazioni concrete. Sebbene tu stia essenzialmente reinventando la ruota, non penso che sia una ruota troppo difficile da reinventare e penso che i benefici che otterrai nel tempo dall'avere una soluzione bella, pulita e semplice saranno sicuramente giustificare l'investimento iniziale.

Il mio approccio sarebbe il seguente:

  • I temi dovrebbero essere in grado di produrre i propri file di metadati. Stavo per suggerire che JSON sarebbe buono come XML per questi file, ma a mio avviso penso che XML sarebbe l'opzione migliore. In ogni caso, non le modificheresti manualmente, quindi ciò che conta è la comodità per il programmatore del tema.

  • Scriverò un validatore separato per convalidare entrambi i file di metadati del tema e la configurazione creata dal generatore dell'interfaccia utente.

  • Vorrei quindi identificare i diversi tipi di controlli di cui hai bisogno e costruirli nelle specifiche del file di metadati del tema. È qui che entra in gioco un pensiero flessibile. Avrei opzioni come "boolean", che verrà visualizzato come checkbox ma per gli elenchi fornirei opzioni "radio" e "dropdown", perché a volte un set di pulsanti radio è più appropriato di un elenco a discesa e viceversa. Fornirei anche un'opzione "regex" in modo che l'interfaccia utente possa eseguire alcune convalide di base ove necessario. Cose come la formattazione del numero di pagine che implementerei includendo un elenco di token con una descrizione del campo, che l'interfaccia utente visualizza all'utente in modo che l'utente sappia che possono utilizzare quei token nel campo. Ad esempio, il campo del formato della pagina potrebbe essere un campo stringa, max 30 caratteri e fornisce i token [page_no] e [total_pages] da includere nella configurazione. Quindi il file dei metadati del tema sarebbe abbastanza flessibile, con elementi contenenti parametri opzionali, informazioni di convalida, elenchi di opzioni, ecc.

  • I file di configurazione del tema risultante utilizzerebbero lo stesso formato (ad esempio XML) e, come detto, dovrebbero essere in grado di essere convalidati da uno strumento autonomo. (Mi rendo conto che si tratta di un dettaglio di implementazione, ma sarebbe il primo posto in cui vorrei iniziare, poiché eseguirò costantemente questo strumento durante lo sviluppo sia come sia il formato dei metadati del tema evoluto).

Il rendering dell'interfaccia utente basato su questo tipo di file non sarebbe poi così difficile su nessuna piattaforma, presupponendo una singola pagina scorrevole verticalmente formattata. Penso che la chiave per fare questo lavoro sia di essere creativo intorno alla definizione dei file di metadati del tema e non di inscatolare il proprio pensiero in un paradigma o in un altro.

    
risposta data 16.09.2013 - 10:15
fonte

Leggi altre domande sui tag

Perché è così difficile rendere C meno incline a bufferizzare gli overflow? Strumenti per la modellazione di dati e flussi di lavoro mediante file di testo strutturato [chiuso]