• Mercatino: Parte 8

    Questa volta ci tocca un po' di teoria ... come facciamo ad aggiungere, al di là delle problematiche grafiche e del template, delle informazioni che riguardano il mercatino? Cosa dobbiamo fare per rendere le informazioni permanenti e nel contempo facilmente accessibili?


    Il mercatino si basa essenzialmente su due strutture, le sezioni del forum speciali e le discussioni. Le discussioni possono essere sia normali che di mercatino, ma sarebbe troppo complicato creare due procedure separate. Sarebbe altrettanto esagerato voler trasformare ogni messaggio in un potenziale annuncio di compravvendita.

    vBulletin ci viene incontro con la struttura delle discussioni, che identifica in modo indiretto anche il primo messaggio. A livello discussione possiamo aggiungere tutti i campi necessari per la descrizione dell'articolo in vendita. Nelle sezioni normali, questi campi non hanno alcun significato. E così è anche spiegato ecco perché era tanto importante contrassegnare le sezioni come parte del mercatino.

    L'aggiunta di nuovi campi avviene a più livelli. In primis sul database, dove verranno impostato le caratteristiche, poi in lettura e in scrittura del campo. vBulletin accede ai dati tramite cosiddetti data manager, che sono classi, ossia insiemi di codice che possono essere gestiti sempre alla stessa maniera dal nucleo del codice (in inglese: core, kernel). Le eccezioni, come nel nostro caso, si gestiranno tramite plugin, che si mettono fra il codice del core e il prodotto finale e modificano il comportamento predefinito in modo mirato. Per evitare che si possano introdurre errori, ci sono diversi luoghi dove intervenire, e comprendere l'importanza è purtroppo difficile, ma è un passo inevitabile.

    Come abbiamo già visto nella modifica della sezione, si devono aggiungere tutti i campi personalizzati nell'evento *data_start, dove verranno inseriti secondo i criteri di controllo e formattazione del record nel database. Sebbene è possibile utilizzare soltanto stringhe, non è consigliabile per motivi di performance. Dato che i plugin sono sempre più lenti di codice integrato nel core, dobbiamo prestare attenzione a ogni virgola di troppo.

    Il campo che abbiamo aggiunto nelle sezioni è:

    $this->validfields['vtp_market'] = array(TYPE_INT, REQ_NO);

    Il nome della variabile è vtp_market e gli attribti sono definiti in un array che contiene il tipo di variabile (in questo caso un integer a 32 bit) e la definizione di controllo. La vera potenza di vbulletin sta nella verifica del contenuto, che può essere facoltativo, obbligatorio oppure definito dall'utente, con ulteriore codice PHP dedicato alla valutazione del campo stesso!

    Nella valutazione del capo inseriremo dunque tutti i vincoli necessari per il salvataggio. Nel file class_core.php troviamo queste definizioni per i tipi di variabili. Qualora il valore non è convertibile, verrà generato un errore:
    Codice PHP:
    define('TYPE_NOCLEAN',      0); // no change

    define('TYPE_BOOL',     1); // force boolean
    define('TYPE_INT',      2); // force integer
    define('TYPE_UINT',     3); // force unsigned integer
    define('TYPE_NUM',      4); // force number
    define('TYPE_UNUM',     5); // force unsigned number
    define('TYPE_UNIXTIME'6); // force unix datestamp (unsigned integer)
    define('TYPE_STR',      7); // force trimmed string
    define('TYPE_NOTRIM',   8); // force string - no trim
    define('TYPE_NOHTML',   9); // force trimmed string with HTML made safe
    define('TYPE_ARRAY',   10); // force array
    define('TYPE_FILE',    11); // force file
    define('TYPE_BINARY',  12); // force binary string
    define('TYPE_NOHTMLCOND'13); // force trimmed string with HTML made safe if determined to be unsafe

    define('TYPE_ARRAY_BOOL',     101);
    define('TYPE_ARRAY_INT',      102);
    define('TYPE_ARRAY_UINT',     103);
    define('TYPE_ARRAY_NUM',      104);
    define('TYPE_ARRAY_UNUM',     105);
    define('TYPE_ARRAY_UNIXTIME'106);
    define('TYPE_ARRAY_STR',      107);
    define('TYPE_ARRAY_NOTRIM',   108);
    define('TYPE_ARRAY_NOHTML',   109);
    define('TYPE_ARRAY_ARRAY',    110);
    define('TYPE_ARRAY_FILE',     11);  // An array of "Files" behaves differently than other <input> arrays. TYPE_FILE handles both types.
    define('TYPE_ARRAY_BINARY',   112);
    define('TYPE_ARRAY_NOHTMLCOND',113);

    define('TYPE_ARRAY_KEYS_INT'202);
    define('TYPE_ARRAY_KEYS_STR'207);

    define('TYPE_CONVERT_SINGLE'100); // value to subtract from array types to convert to single types
    define('TYPE_CONVERT_KEYS',   200); // value to subtract from array => keys types to convert to single types 
    Similmente, il tipo di controllo è definito in parte nel file functions.php come segue:
    Codice PHP:
    define('REQ_NO',   0);
    define('REQ_YES',  1);
    define('REQ_AUTO'2);
    define('REQ_INCR'3); 
    L'array di definizione di variabile può inoltre contenere, come terzo elemento, le definizioni seguenti:
    Codice PHP:
    define('VF_TYPE',       0);
    define('VF_REQ',        1);
    define('VF_CODE',       2);
    define('VF_METHODNAME'3);

    define('VF_METHOD''_-_mEtHoD_-_'); 
    Se è definito VF_METHOD, allora si può aggiungere un quarto campo, che definisce il nome della funzione da chiamare. Se il quarto campo manca, il controllo è del tipo:
    Codice PHP:
    $this->verify_{$nomecampo
    . Se il quarto campo è definito, allora la definizione della funzione è:
    Codice PHP:
    nomefunzione($data$dm
    Bene. Ora che avete tutto capito (no?), possiamo finalmente aggiungere i campi? No, fermi! Questa era soltanto l'introduzione. Eh, se no ... sarebbe troppo semplice.
    Commenti 2 Commenti
    1. L'avatar di Ricsca
      Ricsca -
      Questo mercatino mi incuriosisce sempre più... quanti altri tuotorial mancano per vederlo finito e in azione?
    1. L'avatar di y2ksw
      y2ksw -
      Un bel po'. Mentre scrivo, preparo anche il codice, ma questi giorni sono particolarmente impegnato a far nulla