My Geek Memos

Tre estensioni di TYPO3 irrinunciabili

Sat, 11 Apr 2009 08:51:00 -0400

Per quanto completo e potente possa essere TYPO3, capita di imbattersi in qualche sua mancanza che si potrebbe definire banale. Prima ancora di sviluppare soluzioni che integrino tali mancanze, � opportuno verificare se gi� qualcunaltro non abbia provveduto a creare una estensione che arrichisca TYPO3 della feature mancante.
Una volta scovate queste preziose "perle" si finisce per installarle di default in ogni nuovo progetto TYPO3.

Per gestire il layout dei siti in TYPO3 utilizzo Templavoila, vista l'estrema libert� che tale strumento mi permette di avere. Un suo grossissimo difetto per� � la non immediata gestione dello sliding dei contenuti, ovvero la capacit�, da parte di una pagina, di ereditare i contenuti di medesime content area dalla pagina madre. E' il caso di contenuti presenti nelle classiche colonne laterali, aree del sito utilizzate spesso per informazioni di supporto e omnipresenti.
La soluzione ha il nome di una sola estensione: kb_tv_cont_slide. Una volta installata baster� modificare la Data Structure del vostro template, aggiungendo un paio di righe di Typoscript per ogni campo per cui vorrete attivare lo sliding e il gioco � fatto!

Utilizzando Templavoila, a volte capita di dover inserire degli elementi di contenuto basati su codice typoscript (ad esempio per creare dei men�) e quindi di dover prevedere gi� in fase di creazione del template un campo definito proprio come oggetto Typoscript. Aggiungere in un secondo momento altri oggetti Typoscript significa quasi sempre mettere mano al template.
Esiste invece l'estensione tscobj che permette di includere oggetti typoscript in una content area come si farebbe per un comune elemento di contenuto. L'installazione e l'utilizzo sono di una semplicit� impressionante.

Termina il terzetto un'estensione creata dall'ottimo Dmitry Dulepov, dd_googlesitemap, che vi permetter� di creare e "dare in pasto" a Google la mappa del vostro sito al fine di migliorarne l'indicizzazione.

SAP e Unicode: field symbol con casting

Sat, 04 Apr 2009 04:33:00 -0400

Nelle vecchie versioni SAP gli sviluppatori erano soliti utilizzare degli array di caratteri come contenitori per delle strutture costituite da campi con tipi di dati differenti.

DATA:�BEGIN�OF�struttura,
      �� campo1(10)��TYPE�c,
      �� campo2(2)  TYPE�x,
      �� campo3(10)��TYPE�p,
      �� campo4(40)��TYPE�c,
    � END�OF�struttura.
 DATA:�stringa(500)�TYPE�c.
 
 stringa�=�struttura. 

Nelle versioni pi� recenti di SAP una istruzione di assegnazione di questo genere porta ad un errore di compatibilit� con lo Unicode.

La soluzione pi� ovvia sarebbe passare la struttura campo per campo, aiutandosi con delle variabili buffer per poi ricrearla per intero nella stringa. Un modo pi� veloce di risolvere il problema fa uso dei field symbols con l'opzione casting. In pratica si fanno puntare due field symbols rispettivamente sulle locazioni di memoria occupate dalla struttura e dalla stringa e si compie il passaggio di dati fra field symbols.

FIELD-SYMBOLS:�  �TYPE�x,
          � �  TYPE�x.
 
 ASSIGN�stringa�TO��CASTING.
 ASSIGN�struttura�TO��CASTING.
 
 �=�. 

Si fa presente che che i dati nella stringa contenitore non sono adatti ad essere conservati in maniera permanente nel database. Utilizzare quindi questo metodo solo se si � certi che i dati manipolati sono usati in modo temporaneo nell'Application Server.

RealURL facile: parte 1

Wed, 25 Mar 2009 11:48:00 -0400

La gente molto spesso lamenta che RealURL sia difficile da configurare. Credo che questo accada perch� il manuale di RealURL � scritto come una guida di riferimento, non come un tutorial.
Per questo motivo non c'� nulla da cui iniziare per un principiante. Le ultime versioni di RealURL includono una configurazione automatica, che va bene per siti web semplici. E' vero anche che non � abbastanza flessibile. Una configurazione manuale vincerebbe sempre su una automatica. Questo articolo fornisce una semplice guida per una configurazione manuale di RealURL. Non � breve, quindi prendiamo del tempo per leggerlo.

L'intera guida � divisa in diverse parti. La prima parte descrive la configurazione in generale. Le altre parti descriveranno i dettagli, i tip&tricks e le best practices.

Basi

Questa sezione copre i principi generali di RealURL.

RealURLed URL

Prima di partire con la configurazione, deve essere chiaro di che parti sono costituiti gli URLs di RealURL.

Un tipico URL di RealURL consiste di diversi segmenti:

I segmenti sono (in ordine di apparizione):

preVars
Sono anteposti al percorso della pagina. Di solito si tratta di identificatori di lingua. Non dovrebbero essere troppi lunghi.
Page path
Questo � un percorso che porta alla pagina. E' creato attraversando un albero di pagine dalla radice del sito web sino alla pagina di destinazione. Ci sono diversi campi che possono essere utilizzati per creare i segmenti. Di solito si tratta dei titolo della pagina, dell'alias, del sottotitolo e di un campo speciale di RealURL chiamato "Path segment".
fixedPostVars
Sono parametri non prefissati sulla pagina. Sono molto simili al preVars ma vanno dopo la pagina. Di solito sono impostati soltanto per pagine specifiche e non per l'intero sito.
postVars
Sono parametri prefissati sulla pagina. Per esempio, tx_ttnews[tt_news]=5 pu� essere convertito in /news/test-news-item/. Qui �news� identifica tx_ttnews[tt_news] e il 5 � rimpiazzato dal titolo della news.

Ogni segmento (eccetto il page path) pu� avere diverse variabili.

Basi di configurazione

Normalmente la configurazione di RealURL � conservata in un file separato. Questo file � di solito incluso in typo3conf/localconf.php.

La configurazione di RealURL � un array PHP annidato. La configurazione � creata per un singolo sito web. A rigor di logica appare come:

$TYPO3_CONF_VARS['EXTCONF']['realurl'] = array(
  'www.domain1.com' => array(
    ...
  ),
  'domain1.com' => 'www.domain1.com',
  'www.domain2.com' => array(
    ...
  ),
  'domain2.com' => 'www.domain1.com',
);

Ci sono due tipi di inserimenti qui. Un nome di dominio pu� puntare ad un altro nome di dominio o ad un array di configurazione.
Se un nome di dominio punta ad un altro nome di dominio, RealURL prender� la configurazione del dominio puntato. Possono esistere diversi puntatori nella catena.
Se un nome di dominio punta ad un array, questo � la sua configurazione. Approfondiremo a breve.
Se c'� solo un dominio, non c'� bisogno di specificare il suo nome. L'intera configurazione allora pu� sembrare qualcosa tipo:

$TYPO3_CONF_VARS['EXTCONF']['realurl'] = array(
  '_DEFAULT' => array(
    ...
  ),
);

Questo caso � valido anche se domain.com � un alias di www.domain.com.

L'array di configurazione per ogni dominio (or per _DEFAULT) consiste in subarray, chiamati sezioni di configurazione.

Sezioni di configurazione

Esistono sei sezioni di configurazione. Nessuna di loro � obbligatoria ma almeno due sono di solito utilizzate. Di seguito un rapido sguardo alle sezioni:

init
Questa sezione descrive le opzioni generali di RealURL, come le cache, i valori di ritorno degli URL vuoti e delle altre opzioni.
preVars
Questa sezione definisci le preVars (guarda l'esempio di URL sopra!). Molto semplice.
fixedPostVars
Questa sezione definisce le fixedPostVars.
postVarSets
Questa sezione definisce le postVarsSets. Questa � la parte di configurazione pi� delicata.
pagePath
Questa sezione � di solito una sezione copia/incolla. Non cambia molto fra i diversi server. Tuttavia ha un parametro (rootpage_id), che � di fondamentale importanza nella configurazione multidominio.
fileName
Tale sezione permette di terminare gli URLs con qualcosa di simile a "rss.xml" o "print.html". Anche questa � in linea di massima una sezione copia/incolla.

Creare la sezione init

La sezione init normalmente contiene le direttive della configurazione della cache ed alcune altre utili opzioni. Di seguito un breve elenco che si dovrebbe avere nella propria configurazione:

'enableCHashCache' => true
Utilizziamo questa se il sito web non usa nessuna estensione con parametri nell'URL. Dettagli circa cHash possono trovarsi qui e qui.
'appendMissingSlash' => 'ifNotFile'
Questa direttiva aggiunge uno slasj alla fine dell'URL. Appare soltanto pi� gradevole.
'enableUrlDecodeCache' => true
Permette di utilizare la veloce cache basata sul database quando un utente visita una pagina. E' un enorme miglioramento di performance rispetto a quando la cache � disabilitata.
'enableUrlEncodeCache' => false
Come sopra ma per la codifica. E' utilizzata quando si creano i link. Non c'� alcun motivo di disabilitare questa direttiva come quella precedente.

Questo elenco non � completo. Possiamo trovare altre direttive nel manuale di RealURL.

Creare la sezione prevars

La sezione consiste di una o pi� parti. Ogni parte � essa stessa un array e definisce una singola preVar. Esempio:

array(
  'GETvar' => 'L',
  'valueMap' => array(
    'en' => 0,
    'de' => 1,
  ),
  'noMatch' => 'bypass'
),

In questo esempio, preVar � associata con il parametro di URL "L". valueMap dice che L=0 � mappato con /en/, L=1 � mappato con /de/. noMatch dice che qualsiasi altro valore di L sar� ignorato silenziosamente.

E' possibile specificare anche valori di default o fare altre conversioni. Per i dettagli si incoraggia il lettore a guardare il manuale di RealUrl.

Creare la sezione fixedPostVars

Le fixedPostVars sono molti simili alle preVars. Ci sono solo due differenze:

le fixedPostVars sono piazzate nell'URL dopo il percorso della pagina.
le fixedPostVars devono avere o un page id o una keyword _DEFAULT (per tutte le pagine).

Guardiamo l'esempio:

35 => array(
  array(
    'GETvar' => 'tx_myext_pi1[no_comments]',
    'valueMap' => array(
      'no-comments'� => 1
    ),
    'noMatch' => 'bypass',
  )
),

C'� pi� di un array contenitore attorno alla vera definizione della fixedPostVar. Questo array contenitore dice che la pagina con id 35 ha questa fixedPostVar. Quindi la fixedPostVar "no-comments" non sar� applicata alle altre pagine (a meno che non sia aggiunta anche per loro). C'� anche un 'noMatch' per saltare completamente questa variabile quando non ha senso averla.
Nel caso sia necessario avere pi� di una fixedPostVar su questa pagina, questa seguir� la prima, come si pu� vedere:

35 => array(
  array(
    ...
  ),
  array(
    ...
  )
)

Le fixedPostVars appariranno nell'ordine definito. E' importante pensare bene all'ordine e mantenerlo una volta che sia definito o la decodifica non sar� fatta in maniera appropriata.

Creare i set di postVars

I postVarsSets assomigliano alle fixedPostVars ma hanno in pi� dei prefissi che identificano una postVar. Ci� permette di inserire delle postVars in qualsiasi ordine all'interno dell'URL. Permette anche di avere un set flessibile di postVars.

Una postVar nell'URL pu� in realt� definire diversi parametri reali GET. Per esempio:

'_DEFAULT' => array(
  'myparam' => array( // postVar start
    array(
      'GETvar' => 'tx_mext_pi1[p1]',
    ),
    array(
      'GETvar' => 'tx_mext_pi1[p2]',
    ),
  ),  // postVar end, Other postVar definitions may follow
),

Ora immaginiamo un URL non codificato come questo:

domain.com/index.php

L'URL codificato apparir� come:

domain.com/page/path/myparam/12/34/

E' anche possibile convertire i numeri in stringhe se si riferiscono a tabelle di database. Si pu� inoltre utilizzare codice Php per mappare parametri reali GET in parametri codificati e viceversa. Il sistema � estremamente flessibile e permette di fare quasi qualsiasi cosa!

La sezione pagePath

La sezione pagePath � di solito utilizzata per ampliare ulteriormente RealURL. Di default RealURL crea URL come questo:

domain.com/35/myparam/12/34/

Per rimpiazzare il page id (35 nell'esempio corrente) con un percorso reale alla pagina, deve essere inserito il seguente contenuto nella sezione pagePath:

'type' => 'user',
'userFunc' => 'EXT:realurl/class.tx_realurl_advanced.php:&tx_realurl_advanced->main',

Esistono altre direttive. La pi� importante di loro � rootpage_id. Questa direttiva punta alla pagina che � radice (home page) del sito web corrente. Deve essere impostata per configurazioni multidominio e si raccomanda di impostarla anche in configurazioni monodominio (altrimenti RealURL dovr� cercarla). Dimenticare questa direttiva nelle configurazioni multidominio porta ad un comportamento non corretto di RealURL!

Sezione fileName

Saltare questa sezione nella configurazione non � pericoloso. In genere non � necessaria a meno non si voglia creare nell'URL accattivanti parti finali dei nomi file.

Conclusione

In questo articolo abbiamo passato in rassegna la configurazione di RealURL. Nel prossimo articolo mostreremo come rendere questa configurazione efficace. L'articolo mostrer� alcuni tips&tricks che non sono ovvi leggendo il manuale e che si dovrebbe conoscere. Allora, guardate questo sito per il prossimo articolo!

_____________

Questo articolo � una traduzione dell'articolo RealURL made easy: part 1 scritto da Dmitry Dulepov sul suo blog personale.

La traduzione � stata autorizzata dall'autore ed essa come l'articolo originale non ricade sotto licenza Creative Commons al contrario della gran parte dei contenuti di My Geek Memos.

Search Box custom per tt_news

Thu, 19 Mar 2009 12:42:00 -0400

Una delle pi� apprezzate e potenti estensioni di TYPO3 � certamente tt_news, il gestore di news per eccellenza. Il plugin SEARCH di tt_news � quello che mostra in una pagina il form di ricerca delle news e l'elenco dei risultati. Capita a volte di avere l'esigenza di piazzare il box di ricerca delle news in altre aree del sito, che siano magari costantamente visibili come accade ad esempio in questo blog.
La soluzione consiste nel creare un box di ricerca custom e passare l'input che questo riceve al box di ricerca di tt_news. Vediamo passo passo come fare.

Il box di ricerca custom verr� creato come un plugin Typoscript (che possiamo chiamare lib.mysearch), utilizzabile anche con Templavoila. Dichiariamolo come un Content Object Array renderizzato senza usare la cache (COA_INT):

lib.mysearch = COA_INT

Creiamo ora il codice html pi� esterno, ovvero quello relativo al tag html FORM. Per fare ci� creiamo un oggetto di tipo TEXT:

lib.mysearch {
� 10 = TEXT

Costruiamo quindi l'url che valorizzer� il parametro action del tag FORM. Tale url punta alla pagina contenente il plugin SEARCH:

� 10.typolink.parameter = index.php?id=8&no_cache=1
� 10.typolink.returnLast = url

Imbustiamo ora il tutto nel codice HTML:

� 10.wrap = method="post" id="indexedsearch">

Completiamo quindi la codifica del form aggiungengo altri oggetti TEXT per ciascuna porzione di codice. Si sarebbe potuto aggiungere tale codice HTML al wrap dell'elemento 10 prima creato ma per una questione di ordine e leggibilit� preferiamo dividere il codice in pi� elementi.

� 
� 20 = TEXT
� 20.value = name="tx_ttnews[swords]" class="searchbox-sword" type="text" />
 
� 30 = TEXT
� 30.value = �name="search"� value="Cerca" class="searchbox-button" type="submit" />
� 
� wrap = | 

L'ultimo wrap imbusta l'intero array ed ha come effetto l'accodare al suo contenuto il codice di chiusura dei tag aperti per la creazione del form.
Come si pu� intuire, con l'oggetto 20 il testo inserito nel form di ricerca viene acquisito dalla variabile globale tx_ttnews[swords] che sar� poi letta � passata al form di ricerca standard di tt_news nella pagina dove abbiamo inserito il plugin SEARCH.

Non resta che nascondere il search box standard di tt_news cambiato in hidden la tipologia dei suoi campi.

Di seguito il codice typoscript completo:

lib.mysearch = COA_INT
lib.mysearch {
� 10 = TEXT
� 10.typolink.parameter = index.php?id=8&no_cache=1
� 10.typolink.returnLast = url
� 10.wrap = method="post" id="indexedsearch">
� 
� 20 = TEXT
� 20.value = name="tx_ttnews[swords]" class="searchbox-sword" type="text" />
 
� 30 = TEXT
� 30.value = �name="search"� value="Cerca" class="searchbox-button" type="submit" />
� 
� wrap = | 

}

L'ennesimo blog ?

Sat, 14 Mar 2009 07:58:00 -0400

Direi di s�, l'ennesimo blog in una rete sovraffollata di blog ma non potevo restarne fuori: devo bloggare anche io! Il prossimo passo, forse fra un paio di decadi, sar� convincere me stesso ad entrare nel "magico" mondo di facebook, dove tutti sono amici di tutti.
Battute a parte, questo blog nasce da una mia esigenza di memorizzare in maniera pi� strutturata e su un media facilmente raggiungibile i miei "appunti" di lavoro ma anche quelli inerenti una delle mie pi� grandi passioni, il webdesign. Scriver� quindi di SAP e del suo linguaggio principale (ABAP) ma anche di CSS, HTML, grafica, CMS (Content Management System). Per quanto concerne i CMS in realt� i miei articoli saranno, almeno inizialmente, focalizzati su TYPO3, un framework su cui � costruito questo blog e che ho deciso di utilizzare come base per i siti di mia realizzazione. Si tratta di uno strumento estremamente potente che in pochi conoscono in Italia e che � caratterizzato da una potenza e ricchezza di funzioni direttamente proporzionali alla sua complessit�. Lo ritengo il SAP del webdeveloping, e non so se questo sia un pregio o un difetto.
Basta quindi maree di noticine su file di testo, cartelle disordinate di tips e tutorial. Il mio obiettivo � di accentrare il tutto su questo mio blog.

Non solo Geek

In realt� � probabile che non ci saranno solo articoli di informatica ma potrei divagare toccando altre mie passioni. La tentazione ogni tanto di salire sul pulpito e partire con l'invettiva, col predicozzo (un classico di molti blogger) sar� fortissima, anche alla luce di quanto sta accadendo in Italia negli ultimi anni. Mi correggo, di quanto gli italiani stanno permettendo che accada in Italia negli ultimi anni. Eccola qui, l'invettiva che infida stava gi� partendo dalle mie mani veloci sulla tastiera.

Di sicuro non scriver� dei miei affari privati, non trasformer� questo blog in un diario personale da far leggere a chiunque si trovi a passare. I diari una volta erano un qualcosa di estremamente privato, da non far leggere neanche al pi� caro dei conoscenti o da rendere pubblici solo verso la fine di una vita talmente (e realmente) interessante da valere la pena di essere raccontata ad altri.
Ora invece il morbo del Grande Fratello ha attecchito facilmente su un terreno fertile di esibizionismo e vuotezza interiore col risultato che la gente esterna la propria intimit� e racconta la propria vita davanti ad estranei, avendo forse la presunzione che tutto ci� possa risultare interessante e "speciale".
Di nuovo...l'invettiva, dannazione! Devo trattenermi o dovr� ribattezzare questo blog My Geek Invective.