Query > selfields

Il tag selfields ha il compito di regolare i campi di selezione che l’operatore può esprimere le sue selezioni. Esso regola quindi cosa debba apparire nella finestra che l’operatore vede quando avvia la query:

e, più precisamente, ogni riga di quella finestra è rappresentata da un elemento del tag selfields. Il tag corrispondente alla precedente query è il seguente:

<selfields>
  <field>
    <type>Param</type>
    <paramname>tiposel</paramname>
    <caption>Ordini Aperti/Chiusi/Tutti</caption>
    <queryrole>param</queryrole>
    <defaultfrom>A</defaultfrom>
  </field>  
  <field>
    <type>Param</type>
    <paramname>conprovv</paramname>
    <caption>Comprendi ord. provvisori (S/N)</caption>
    <queryrole>param</queryrole>
    <defaultfrom>N</defaultfrom>
  </field>  
  <field>
    <fieldname>ordacqtes.data</fieldname>
    <caption>Data Ord.</caption>
    <datatype>date</datatype>
  </field>   
  <field>
    <fieldname>ordacqtes.numero</fieldname>
    <caption>Num. Ord.</caption>
  </field>   
  <field>
    <fieldname>coalesce(ordacqrig.dataconsrich, ordacqtes.dataconsrich)</fieldname>
    <caption>Data Cons.</caption>
    <datatype>date</datatype>
  </field>   
  <field>
    <fieldname>ordacqtes.idfornitore</fieldname>
    <caption>Fornitore</caption>
    <viewname>fornitori</viewname>
    <keyfieldname>idfornitore</keyfieldname>
    <txttable>fornitori</txttable>
    <txtfields>ragsoc1</txtfields>
  </field>   
  <field>
    <fieldname>ordacqrig.idcommessa</fieldname>
    <caption>Commessa</caption>
    <viewname>commesse</viewname>
    <keyfieldname>idcommessa</keyfieldname>
    <txttable>commesse</txttable>
    <txtfields>descomm</txtfields>
  </field>   
  <field>
    <fieldname>ordacqrig.codart</fieldname>
    <caption>Cod. Art.</caption>
    <viewname>articoli</viewname>
    <txttable>articoli</txttable>
    <txtfields>codice, descri, desagg</txtfields>
    <txttablekey>codice</txttablekey>
    <keyfieldname>codice</keyfieldname>
  </field>   
</selfields> 

Un campo di selezione semplice

Come primo esempio consideriamo la selezione che, nell’esempio sopra riportato, consente di indicare il numero di ordine. Essa è regolata dal seguente tag:

  <field>
    <fieldname>ordacqtes.numero</fieldname>
    <caption>Num. Ord.</caption>
  </field>   

il quale esprime che il campo da considerare nella sintassi SQL è ordacqtes.numero e che l’etichetta mostrata è Num. Ord.; questo è sufficiente ad ottenere il completo funzionamento del campo.

Analogamente la selezione per data ordine:

  <field>
    <fieldname>ordacqtes.data</fieldname>
    <caption>Data Ord.</caption>
    <datatype>date</datatype>
  </field>   

la quale introduce anche il datatype così che ProOne proponga il calendario come possibile strumento di input da parte dell’operatore e formatti l’input correttamente, indipendentemente da come l’operatore lo scrive.

Un po’ più articolata risulta la selezione per data di consegna:

  <field>
    <fieldname>coalesce(ordacqrig.dataconsrich, ordacqtes.dataconsrich)</fieldname>
    <caption>Data Cons.</caption>
    <datatype>date</datatype>
  </field>  

la quale, oltre al datatype fa uso di un’espressione nel tag fieldname perché, come noto, la data di consegna in un ordine di vendita è espressa dalla riga e, se non indicata sulla riga, vale quella di testata; di qui l’utilizzo della funzione SQL coalesce.

Oltre a quanto sopra ogni campo può esprimere i propri defaultfrom e defaultto che sono i valori pre-impostati che appaiono all’operatore.

Campi con tabella collegata

Nell’esempio sopra riportato, le selezioni per fornitore, commessa e articolo mostrano il pulsante […] a fianco delle caselle. Questo perché vi è una tabella collegata. Un primo esempio di tag con quella struttura è il seguente:

  <field>
    <fieldname>ordacqtes.idfornitore</fieldname>
    <caption>Fornitore</caption>
    <viewname>fornitori</viewname>
    <keyfieldname>idfornitore</keyfieldname>
    <txttable>fornitori</txttable>
    <txtfields>ragsoc1</txtfields>
  </field>   

che, rispetto ai precedenti, introduce:

• viewname: la vista da evocare per la ricerca;
• keyfieldname: il nome del campo chiave della vista;
• txttable: il nome della tabella di riferimento;
• txtfields: il campo (o i campi) che si intende utilizzare per meglio rappresentare il dato (vedi esempio nell’immagine seguente)

Analogamente il campo di selezione dell’articolo è definito nel modo seguente:

  <field>
    <fieldname>ordacqrig.codart</fieldname>
    <caption>Cod. Art.</caption>
    <viewname>articoli</viewname>
    <txttable>articoli</txttable>
    <txtfields>codice, descri, desagg</txtfields>
    <txttablekey>codice</txttablekey>
    <keyfieldname>codice</keyfieldname>
  </field>

che, rispetto al precedente, esprime anche il tag txttablekey resosi qui necessario in quanto non vi è omonimia tra il campo oggetto di selezione (codart tratto dalla tabella ordacqrig) e il campo chiave della tabella collegata (che si chiama codice nella tabella articoli).

Una semplificazione: lookupclass

Quando si fa uso di tabelle collegate, come abbiamo visto, sono molteplici i tag necessari. Una semplificazione è offerta dalle lookupclass le quali definiscono, a priori, il comportamento della tabella collegata. L’ultimo nostro esempio quindi, con l’intervento della lookupclass, diviene:

  <field>
    <fieldname>ordacqrig.codart</fieldname>
    <caption>Cod. Art.</caption>
    <lookupclass>articoli</lookupclass>
  </field>

essendo tutte i tag viewname, txttable, txttablekey, txtfields, keyfieldname definiti nella lookupclass.

Per un utilizzo ancora più versatile ogni singolo tag definito nella lookupclass può essere sovrascritto nel tag della query per cui sono ammissibili soluzioni quali:

  <field>
    <fieldname>ordacqrig.codart</fieldname>
    <caption>Cod. Art.</caption>
    <lookupclass>articoli</lookupclass>
    <viewname>articolicommerciali</viewname>
  </field>

la quale presuppone l’utilizzo della lookupclass “articoli” ma impone l’utilizzo di una vista differente, in deroga a quanto definito nella lookupclass stessa.

Uso delle classificazioni

Molto spesso le tabelle collegate sono le classificazioni di ProOne. In questo caso l’utilizzo è ancora più semplice in quanto il tag va costruito semplicemente indicando il codice della classificazione da impiegare:

  <field>
    <fieldname>ordacqrig.vencl3</fieldname>
    <codclassif>VE03</codclassif>
  </field>

dove, come si vede, è possibile omettere anche i tag relativi alla caption e ogni altro tag in quanto la classificazione già li determina automaticamente.

Utilizzo di parametri

Sino ad ora abbiamo considerato il caso in cui la selezione operata dall’utente vada ad impattare direttamente nella clausola where della query imponendo la selezione dei soli record corrispondenti al criterio indicato. Vi sono casi in cui, invece, l’operatore deve poter esprimere una circostanza come, ad esempio, nella prima e nella seconda casella della query più sopra rappresentata.

Qui l’utente dice se intende considerare gli ordini aperti, quelli chiusi oppure tutti; dice inoltre se considerare o meno i provvisori.

Questi due campi di selezione sono definiti nel modo seguente:

  <field>
    <type>Param</type>
    <paramname>tiposel</paramname>
    <caption>Ordini Aperti/Chiusi/Tutti</caption>
    <queryrole>param</queryrole>
    <defaultfrom>A</defaultfrom>
  </field>  
  <field>
    <type>Param</type>
    <paramname>conprovv</paramname>
    <caption>Comprendi ord. provvisori (S/N)</caption>
    <queryrole>param</queryrole>
    <defaultfrom>N</defaultfrom>
  </field>  

e si differenziano da tutti i casi precedenti in quanto non fanno riferimento ad uno specifico campo della query (non è presente il tag fieldname). Anzi essi esplicitano di essere dei “parametri” mediante:

• il type impostato a Param
• il queryrole impostato a param
• ciascuno un proprio paramname

L’impiego dei parametri della query avviene secondo la sintassi SQL e, sempre con riferimento all’esempio precedente, essi appaiono nella clausola where nel modo seguente:

<strwhere><where ordacqtes.codoac = ‘OA01’ and (ordacqtes.numero is not null or :conprovv = ‘S’)  and ((:tiposel in (‘A’, ‘T’) and (ordacqrig.saldato = 0 or ordacqrig.saldato is null)) or (:tiposel in (‘C’, ‘T’) and ordacqrig.saldato = 1))</strwhere>

Parametri con elenco a discesa

Nei casi sino a qui espressi i parametri prevedevano l’inserimento manuale da parte dell’operatore (il quale avrebbe potuto anche inserire valori privi di significato rispetto al costrutto SQL sottostante). Un buon modo per migliorare questa operatività è quello di inserire nel tag del parametro anche le informazioni per consentire una selezione da elenco anziché una digitazione manuale. Il primo dei due parametri sopra rappresentati, con l’inserimento dell’elenco a discesa diviene:

  <field>
    <type>Param</type>
    <paramname>tiposel</paramname>
    <caption>Ordini Aperti/Chiusi/Tutti</caption>
    <queryrole>param</queryrole>
    <defaultfrom>A</defaultfrom>
    <values>
      <value>
        <keyvalue>A</keyvalue>
        <displayvalue>Solo ordini aperti</displayvalue>
      </value>
      <value>
        <keyvalue>C</keyvalue>
        <displayvalue>Solo ordini chiusi</displayvalue>
      </value>
      <value>
        <keyvalue>T</keyvalue>
        <displayvalue>Tutti gli ordini</displayvalue>
      </value>
    </values> 
  </field>