Andrea Gandino

Il primo capitolo di una mini-serie di articoli che trattano gli aspetti in cui Javascript può dare una mano ai fogli di stile, come ad esempio, ed è il caso dell’articolo in questione, il problema di avere tabelle con righe di colore alternato.

Continua …

Ho preso la decisione, neanche poi troppo sofferta, di costruirmi il mio blog da solo e non appoggiandomi più ad applicazioni realizzate da altri. Quando si parla di sistemi di pubblicazione, le scelte non sono poi moltissime, e ho trovato che ognuna di esse non riuscisse a soddisfare appieno le mie richieste.

Continua …

Linee guida molto basilari per l’utilizzo di Javascript senza dimenticarci dell’accessibilità.

Continua …

Il progetto cui sto attualmente lavorando richiede l’utilizzo di PHP come linguaggio di programmazione. Mi è capitato di pensare un paio di cose, riguardo la progettazione e lo sviluppo degli odierni portali. La cosa banale è che lo straordinario successo di Ruby è dovuto a Rails, più che alla straordinaria bellezza del linguaggio in sé; l’altra cosa, forse un po’ meno banale, è che, forse, se non si utilizzassero i framework, probabilmente programmare in PHP non avrebbe più senso.

Tutto questo per introdurre un po’ di quello che penso circa i due framework che si sono contesi le mie preferenze ultimamente, in attesa di dare un’occhiata anche al nuovo Symfony 1.0, vale a dire CakePHP e Code Igniter.

Entrambi, proprio come Rails, portano avanti il concetto di MVC come design pattern per le applicazioni.

Non vi sono troppe differenze, diciamo. I controllers gestiscono tutte le funzioni del sito, delegandole alle singole funzioni. Tuttavia, è bene notare che CakePHP riesce a gestire il tutto in maniera più elegante, permettendo di passare dei parametri alle funzioni, prendendoli direttamente dagli url (Code Igniter fa la stessa cosa, ma ha bisogno di un particolare helper).

La base comune di entrambi i framework, oltre al già citato MVC, prevede l’uso di helpers e librerie predefiniti, ma anche definiti dall’utente.

Diciamo che la cosa che fa ammirare Rails, è la vera e propria magia che gli sta dietro. Gran parte del merito va, secondo me, attribuito alle relazioni tra tabelle, che permettono di prelevare i dati di entità (modelli) correlate tra loro.

Questo è con tutta probabilità il fattore che maggiormente influisce nella scelta tra CakePHP e Code Igniter, dal momento che il primo, generalmente più potente e completo, offre il supporto per dette relazioni, mentre il secondo, più semplice ed immediato, (ancora) non le prevede.

Direi che si può vivere bene anche senza usare le relazioni tra tabelle, anche se, come ovvio, se usata correttamente è una caratteristica estremamente utile.

Le documentazioni sono complete ed esaurienti. Di Code Igniter non ho però trovato tutorial scritti, bensì solo screencast.

Entrambi i framework hanno un eccellente supporto. Di CakePHP potete trovare il relativo gruppo su Google Groups, mentre per Code Igniter potete fare una visita al forum ufficiale, entrambi in inglese.

In generale, CakePHP è più complesso ma più potente di Code Igniter, e probabilmente risulta essere più indicato in progetti più ampi, mentre il secondo, sebbene abbia una flessibilità davvero notevole, è forse preferibile per la creazione di siti un po’ più piccoli (nulla vi vieta di utilizzarlo anche in altre circostanze, comunque).

Quali sono le vostre opinioni a riguardo? Avete provato anche altre alternative?

Un piccolo suggerimento per migliorare l’accesibilità del nostro template di WordPress, implementando una funzionalità altrimenti misteriosamente tralasciata dagli sviluppatori: quella di mostrare alternativamente il riassunto, o il contenuto integrale del post, senza tagliarlo.

Continua …

Una piccola introduzione a Javascript e alle funzioni relative al Document Object Model.

Continua …

Un rapido sguardo ad uno di quei moduli completamente rifatti in XHTML 2.0: l’Edit Module, che consente di ‘marcare’ le modifiche ad un testo, in seguito alla sua pubblicazione.

Continua …

Se c’è una cosa che mi ha sempre affascinato, quella è la tipografia. Ok, è soltanto un’altra voce nella lista di cose che vorrei imparare o almeno conoscere in modo basilare, e per le quali il tempo scarseggia quasi sempre.

Oggi mi sono imbattuto, quasi per caso, in due termini che fanno parte di quello che potremmo considerare come il vocabolario della tipografia. Ad alcuni di voi potranno sembrare ovvi, ma per chi, come il sottoscritto, è a livello -1 quanto a conoscenza dell’argomento non lo sono affatto. Così, giusto per tenere questo articolo anche come riferimento futuro per il sottoscritto, ho deciso di prenderne nota, non sia mai che un giorno possano in qualche modo tornare utili.

Descender

Nient’altro che un carattere che va al di sotto della linea base propria di quel font. Ad esempio, nella parola “gatto” la “g” è un descender. Similmente esiste un altro termine, vale a dire “ascender”, che significa l’esatto opposto, ovvero un carattere che si estende al di sopra della linea mediana del font.

Per valutare quali siano le linee immaginarie che delimitano i descenders e gli ascenders, si prende come modello la lettera “x”, ovviamente minuscola, dal momento che i suoi estremi inferiore e superiore sono equidistanti dal punto in cui le rette che la compongono convergono.

Widow

Una parola rimasta ‘vedova’ è, come forse potrete intuire, una parola che, dopo essere andata a capo, è rimasta con il solo punto a farle compagnia, in quella che altrimenti sarebbe una riga completamente vuota, come nell’immagine che segue.

Un paio di riflessioni circa le due cose.

Innanzitutto, direi una piccolissima nota circa i descenders. Da quando s’è cominciato a parlare di web 2.0, ha preso piede quello stile di design, alla lunga decisamente troppo ripetitivo, fatto di loghi translucidi e di riflessi, come se ogni scritta fosse posta su un tavolino di cristallo.

In realtà, da un punto di vista tecnico c’è poco da eccepire, nel senso che è un effetto decisamente gradevole. Tuttavia, oltre all’abuso spropositato dello stesso, bisognerebbe prestare attenzione a far sì che tale effetto non risulti deleterio per il layout complessivo della nostra pagina.

Ad esempio, ed è qui che entrano in gioco i nostri descenders, è assolutamente sconsigliabile usare quell’effetto su un testo che presenta caratteri che sforano in basso rispetto alla baseline, pena un risultato palesemente poco realistico.

Un’altra osservazione, o per meglio dire un trucchetto, riguarda le parole vedove. Siccome è un pensiero generale che le parole vedove non siano esattamente il massimo a livello stilistico, e siccome il loro presentarsi è dovuto al fatto che sono precedute da normali spazi che conducono all’andare a capo, si può ovviare al problema sostituendo all’ultimo spazio, o in alcuni casi agli ultimi due spazi, due cosidetti non breaking spaces.
Siccome non interrompono la linea, gli spazi caratterizzati dall’entità HTML   forzano le parole cui fungono da separatori a non andare a capo, eliminando di fatto il problema delle vedove.