Qualunque tipo di funzione/effetto e/o trasformazione del DOM di una pagina web può essere incorporata in un plugin jQuery con lo scopo di migliorare l’organizzazione del proprio codice Javascript.
Invece di un’accozzaglia di istruzioni generiche avremo il riferimento ad un set ordinato di plugins.

http://jsbin.com/apojah/14/edit/

Wrapper jQuery:

Il primo accorgimento utile è incorporare il codice del plugin in un oggetto wrapper il cui scopo è duplice:

1. isolare il codice del plugin dallo spazio degli script della pagina
2. utilizzare $ come riferimento interno a jQuery in modo sicuro

0
1
2

;(function($){
... qui va il codice del plugin ...
})(jQuery);

Tutte le variabili dichiarate mediante la sintassi “var” saranno locali al plugin mentre rimane possibile accedere a variabili globali dichiarate esternamente.

Passare la variabile “jQuery” al wrapper rende possibile l’utilizzo della funzione $ tipica di jQuery all’interno del codice del nostro plugin anche in presenza di altri framework esterni (es MooTools).

Struttura base del plugin:

Un plugin è un’estensione di jQuery che agisce su di un contesto formato da un elenco di nodi DOM identificati da una query xPath.

$('p').hide();

La precedente istruzione identifica un elenco di nodi DOM composto da tutti i paragrafi (p) presenti nel documento HTML e passa tale contesto alla funzione hide() di jQuery. Tale funzione restituisce il contesto stesso rendendo possibile la concatenazione di più plugins:

$('p').hide().fadeIn();

Per questo motivo il codice base del nostro plugin sarà:

0
1
2
3
4
5
6
7
8

$.fn.customPlugin = function() {
 
  $(this).each(function(){
    ... azioni sul singolo elemento DOM ...
  });  
 
  return this;
 
};

Viene eseguito un ciclo applicando una funzione ad ogni elemento del contesto. Successivamente il plugin restituisce il contesto stesso per consentire la concatenazione dei plugins come accennato sopra.

Ottimizziamo il ciclo sul contesto:

E’ importante capire che in Javascript ogni function() è trattata come un oggetto.
Il codice di questo esempio, seppur molto diffuso, crea un nuovo oggetto per ogni elemento di contesto quindi incide significativamente sulla memoria e sulla prestazioni del plugin stesso.

Possiamo ottimizzare il tutto spostando la logica applicata al singolo elemento in una funzione esterna locale al wrapper del plugin:

0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

;(function($){
 
  /**
   * Metodo locale utilizzato dal plugin jQuery sugli elementi DOM
   *
   */
  var __loop = function() {
 
    $(this).fadeOut().fadeIn();
 
  };
 
  /**
   * Plugin - Estensione jQuery
   */
  $.fn.customPlugin = function() {
 
    // Applico la logica agli elementi del contesto (DOM)
    $(this).each(__loop);
 
    // Mantengo la possibilità di concatenare plugins.
    return this;
 
  }; // EndOf: "customPlugin()" ###
 
})(jQuery);

In riga #19 applichiamo la funzione __fn() che è definita esterna al plugin ma localmente al wrapper creato. In questo modo Javascript utilizzerà sempre il medesimo oggetto passando di volta in volta dati differenti.

Questo concetto è estremamente importante in quanto con jQuery è utilizzo comune passare nuove funzioni come parametri di metodi applicati ad elementi DOM. Aver cura di definire tali funzioni (solitamente callback) in modo esplicito nel wrapper del plugin è fondamentale per migliorare le prestazioni del nostro codice.

Configurazione del Plugin:

Praticamente il 100% dei plugins jQuery utilizzano il primo parametro passato come oggetto di configurazione interna.

0
1
2
3

$('p').customPlugin({
speed:'fast',
color:'red'
});

Una configurazione classica consiste in un oggetto le cui proprietà sono utilizzate dalla logica interna al plugin stesso per personalizzare le funzionalità erogate secondo diverse esigenze.

L’utilizzo di un oggetto di configurazione fa nascere alcune problematiche di organizzazione del codice quali:

• necessità di applicare dei valori di default per opzioni non rese esplicite
• necessità di passare l’oggetto di configurazione alla funzione __loop()

0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

$.fn.customPlugin = function() {
 
  // Proprietà di configurazione interna.
  var cfg = false;
 
  // Estendo la proprietà di configurazione con l'oggetto di
  // configurazione contenuto nel primo parametro del plugin.
  if ( !arguments.length || $.isPlainObject(arguments[0]) ) {
 
    cfg = $.extend({},{
      color: 'black'
    },arguments[0]);
 
  }
 
  // Applico la logica agli elementi del contesto (DOM)
  $(this).each(function(){ __loop.call( this, cfg ); });
 
  // Mantengo la possibilità di concatenare plugins.
  return this;
 
};

Come prima cosa si noti l’aggiunta di una proprietà locale al plugin cfg la quale è instanziata a false e successivamente estesa da un oggetto contenente la configurazione di default del plugin stesso. (riga #3 -> #13)

La configurazione è contenuta nel primo parametro tra quelli passati al plugin, inoltre il valore di cfg viene modificato solamente se tale parametro è un oggetto. Questo condizionale è la base di una semplice tecnica per utilizzare il medesimo plugin con tipi di input differenti come avviene in quasi tutti i widget di jQuery UI.

$('#foo').dialog({ .. config .. }).dialog('open');

Utilizziamo le Closures:

Anche la riga #16 è cambiata: abbiamo dovuto aggiungere una closure per consentire il passaggio della configurazione alla funzione locale __loop().

L’utilizzo della closure è un compromesso di ottimizzazione.

Cerchiamo di isolare tutta la logica possibile in una funzione esterna che verrà invocata con parametri diversi dal codice interno alla closure. La closure verrà invece creata per ogni elemento DOM del contesto causando un leggero spreco di memoria.

Mantenere essenziale il codice delle closure demandando tutta la logica a funzioni esterne è importantissimo per garantire buone performance al nostro codice!

Rispondere a diversi tipi di input:

Abbiamo accennato a jQueryUI ed a come metta a disposizione una serie di widget la cui caratteristica comune è erogare comportamenti diversi in base a tipi di chiamate diverse:

0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80

(function($){
 
  /**
   * Logic methods
   */
 
  var __loop = function( cfg ) {
 
    $(this).data( 'customPlugin', cfg );
 
  };
 
  var __colorize = function() {
 
    var cfg = $(this).data('customPlugin');
 
    $(this).css( 'background-color', cfg.color );
 
  };
 
  /**
   * Plugin - Estensione jQuery
   */
  $.fn.customPlugin = function() {
 
    // Proprietà di configurazione interna.
    var cfg = false;
 
    // Estendo la proprietà di configurazione con l'oggetto di
    // configurazione contenuto nel primo parametro del plugin.
    if ( !arguments.length || $.isPlainObject(arguments[0]) ) {
 
      cfg = $.extend({},{
        color: 'black'
      },arguments[0]);
 
    }
 
    // Inizializzazione Plugin:
    // Applico la logica agli elementi del contesto (DOM)
    if ( cfg !== false ) {
      $(this).each(function(){ __loop.call( this, cfg ); });
 
    // Azioni su plugin intanziato:
    } else if ( arguments.length ) {
 
      switch ( arguments[0] ) {
 
        case 'colorize':
          $(this).each(function(){ __colorize.call( this ); });
          break;
 
      }
 
    }
 
    // Mantengo la possibilità di concatenare plugins.
    return this;
 
  }; // EndOf: "customPlugin()" ###
 
})(jQuery);
 
/**
 * Codice eseguito al caricamento della pagina
 */
$(document).ready(function(){
 
  // Inizializzazione del plugin
  $('p').customPlugin({
    color:'red'
  });
 
  // Esempio di utilizzo delle azioni del plugin
  $('input').click(function(){
 
    $('p').customPlugin('colorize');
 
  });
 
});

In questo esempio applichiamo il nostro plugin a tutti paragrafi (p) del documento (riga #69). Questa operazione andrà ad attivare il metodo locale __loop() la cui logica è salvare la configurazione del plugin all’interno del DOM del nodo interessato.

Successivamente sfruttiamo il click su di un bottone per invocare il metodo “colorize” del plugin stesso. In questo caso entra in scena il metodo local __colorize(). Questo è reso possibile dal controllo sul tipo di dato effettuato sul primo parametro passato al plugin. Rispettivamente in riga #30 e poi in riga #46.

Seguendo la struttura esposta nell’articolo il codice del plugin è diviso in due macro sezioni: un “router” di azioni ed un certo numero di metodi interni.

Il router è gestito nella funzione che estende jQuery. Controlla il tipo di input e si occupa di stabile che tipo di azione è richiesta.

I metodi interni si occupano di dar seguito alla decisione del router e devono “fare la magia”. Solitamente i metodi interni sono invocati per ogni elemento DOM identificato dal contesto del plugin come nei precedenti esempi.

Il passo successivo è massimizzare l’ottimizzazione dei metodi interni!

Ottimizzare con le Variabili Cache:

Ogni metodo locale di logica riceve come contesto il riferimento ad un preciso nodo DOM facente parte dell’xPath su cui è stato lanciato il plugin. Nel nostro esempio significa che il codice $(this) all’interno dei metodi __loop() o __colorize() è il riferimento ad un singolo paragrafo.

Sempre all’interno di questi metodi potremo aver bisogno di effettuare nuove ricerche su nodi:

$(this).find('strong')

a cui applicare vari metodi jQuery oppure altri plugin a cascata.

Ogni volta che si utilizza jQuery per effettuare una ricerca viene impegnata memoria e CPU. Noi possiamo agire e salvare i risultati di una query in una variabile locale così da alleggerire il carico del computer client. Vediamo il codice di __colorize():

0
1
2
3
4
5
6
7
8

var __colorize = function() {
 
  var $this = $(this);
 
  var cfg = $this.data('customPlugin');
 
  $this.css( 'background-color', cfg.color );
 
};

In riga #2 viene creata la variabile locale $this con riferimento al nodo DOM.
Nelle righe #4 e #6 riutilizziamo questa variabile per applicare metodi jQuery.

Questo è ovviamente un esempio banale ma possiamo immaginare l’impatto positivo di questo accorgimento quando la logica comincia a complicarsi un po’!

Conclusioni:

In questo articolo abbiamo raccolto le basi per la costruzione di un plugin jQuery versatile e prestazionale.

Grazie a questa struttura diventa semplice realizzare strumenti complessi che contengano configurazione e azioni.

Nel prossimo articolo studiamo in dettaglio alcune linee guida utili alla realizzazione di un “widget” ovvero un plugin complesso che mette a disposizione un controllo di interfaccia facilmente riutilizzabile in progetti differenti.

Al momento in cui scrivo il progetto di “widget collection” jQuery più affermato è sicuramente jQueryUI il quale mette a disposizione controlli di interfaccia evoluti quali dialog window, date picker, sortable list, etc.

Noi impareremo a creare componenti “custom” il cui utilizzo sia però ispirato alle linee guida di jQueryUI, fino ad arrivare alla creazione di nuovi widget completamente compatibili con jQueryUI e le sue linee guida.

Segnala presso:

L’argomento:

Queste versioni di Internet Explorer non supportano le Media Query (nè HTML5… anzi, non supportano nulla!) ma fortunatamente esistono delle librerie che – via javascript – risolvono il problema.

• css3-mediaqueries-js - supporto esteso alle media query CSS3
• respond.js – supporto ottimizzato alle media query CSS3 per il “mobile first” responsive design

Io utilizzo respond.js perchè mi interessa solamente intercettare le dimensioni dello schermo ed agire di conseguenza sulla presentazione della pagina web ed è proprio su questa libreria che si concentra l’errore segnalato in questo post.

L’errore:

Questa libreria va in errore quando il foglio di stile contiene delle regole vuote:

body {}

La soluzione:

La semplicissima soluzione consiste nell’inserire almeno uno spazio all’interno delle parentesi graffe:

body { }

Conclusioni:

Molti di voi sostengono – a ragione – che questo tipo di istruzioni non dovrebbero esistere in un foglio di stile in quanto sono un semplice spreco di spazio e di tempo di caricamento. Sono pienamente d’accordo!

Tuttavia in piena fase di sviluppo molti sviluppatori usano scrivere il set completo di “css handler” per definire le regole interne in un secondo momento. In questo caso – in progettazione – questo bug può far perdere tempo prezioso e la soluzione proposta in questo articolo diventa utilissima!

Segnala presso:

1. Compatibilità cross-library
2. Configurazione globale del plugin
3. Separazione delle API dal codice funzionale del plugin stesso

1. Definizione di uno Scope anonimo:

/**
 * jQuery Bacheca
 * Plugin Dimostrativo
 */

;(function($){
  // Plugin's code goes here
})( jQuery );

2. Configurazione Globale del Plugin 

$.bacheca = {

  // Versione ed altre info eventuali.
  version: '1.0,
  author: 'Marco Pegoraro',
  doc: 'http://www.documentazionedelplugin.com',

  // Configurazione globale del plugin.
  defaults: {},

};

Questa istruzione estende jQuery e aggiunge una nuova proprietà chiamata con il nome del plugin stesso.

NOTA: I dati qui collezionati saranno pubblici ed accessibili da qualunque porzione di codice abbia accesso al namespace jQuery. Questo è un fatto importante perchè chi utilizza il nostro plugin potrà scrivere istruzioni simili alla seguente per configurare a livello globale il comportamento del plugin stesso.

$.bacheca.defaults.var1 = "foo";

Qualunque istanza del plugin bacheca riceverà questa variabile nella configurazione locale (a meno che non venga sovrascritta dalla configurazione dell’istanza stessa!)

Può essere molto utile poter controllare, a livello di pagina, se un determinato plugin è caricato o meno con un’istruzione simile a questa:

if ( $.bacheca ) { /* plugin exists */ } else { /* plugin missing */ }

3. Il Plugin

Il plugin vero e proprio è semplicemente una funzione che estende la collection di jQuery aggiungendo nuove funzionalità.

$.fn.bacheca = function() { /* plugin logic */ }

Molti sviluppatori implementano le funzionalità direttamente nel codice logico del plugin ma io trovo sia più corretto organizzare il plugin come un metodo pubblico di accesso ad API  private.

Questo significa che tutta la logica del plugin è inaccessibile da codice globale e la possiamo utilizzare solamente attraverso il plugin stesso mediante istruzioni simili a:

$('#bacheca').bacheca({ bgcolor: "#eee" });
$('#bacheca').bacheca( "write", "Nuova frase in bacheca" );
$('#bacheca').bacheca( "clear" );

Come si può vedere da questo esempio stiamo utilizzando sempre il plugin “bacheca” il quale avrà comportamenti differenti in base alla tipologia del primo parametro. nel caso il primo parametro venga riconosciuto come nome di una API essa verrà invocata ricevendo tutti i parametri aggiuntivi.

Il codice da utilizzare per implementare quanto esposto è:

// Collezione di metodi di interfaccia (API)
apis = {};

// Definizione del plugin
$.fn.bacheca = function( method ) {

  // Cerco il metodo richiesto tra le API esposte.
  if ( apis[method] ) {
    return apis[ method ].apply( this, Array.prototype.slice.call( arguments, 1 ));

  // Lancio il metodo di inizializzazione in presenza di un oggetto di configurazione.
  } else if ( typeof method === 'object' || ! method ) {
    return apis.init.apply( this, arguments );

  // Lancio un'eccezione jQuery in caso il metodo API non sia trovato.
  } else {
    $.error( 'Method "' +  method + '" does not exist on jQuery.bacheca' );

  }
}

Come anticipato il plugin non contiene logica funzionale ma è solo un “passa carte” verso metodi elencati in un array chiamato “apis”.

L’oggetto “apis” viene definito all’interno dello scope del plugin e risulta quindi essere un oggetto “privato” il cui utilizzo è riservato al codice del plugin stesso.
In questo modo possiamo esporre funzionalità all’esterno garantendo che esse non siano modificabili da altro software (altri plugins, etc).

4. API Collection

Il plugin definito nel paragrafo precedente non fa altro che cercare metodi all’interno della collezione delle API.

Il nostro lavoro di sviluppo del plugin consiste proprio nell’estendere queste API a partire dal metodo “init()”, che riceverà la configurazione del plugin stesso, proseguendo poi per i metodi di azione.

5. Bacheca::init()

apis.init = function( cfg ) {

  // Estendo la configurazione di default con la configurazione locale
  var cfg = $.extend( {}, $.bacheca.defaults, cfg );

  // Ciclo gli elementi identificati dal selettore
  return $(this).each(function(){
    $bacheca = $(this);
    $bacheca.html( cfg.content );
    if ( cfg.bgcolor != null ) $bacheca.css( 'background', cfg.bgcolor );
  });
}

Questo metodo riceve la configurazione locale applicata all’istanza del plugin. Ogni istanza del plugin (ogni suo utilizzo) può essere configurato a piacere ed è importante che queste configurazioni siano mantenute isolate le une dalle altre.

In questo primo e semplice plugin la configurazione è utilizzata semplicemente per definire il contenuto iniziale della bacheca ed il suo colore di sfondo. Gli altri metodi API non fanno uso di questa configurazione dunque non ci siamo occupati di gestirla al meglio (lasciamo l’argomento ad un articolo dedicato).

6. Bacheca::write(), Bacheca::clear()

apis.write = function( word ) {
  return $(this).append('<p>'+word+'</p>');
}

apis.clear = function() {
  return $(this).html("");
}

Questi due metodi API esposti dal plugin sono estremamente semplici e consentono di manipolare il contenuto della bacheca.

7. Utilizzo del plugin:

<!-- Codice HTML -->
<div id="bacheca"></div>

// Codice Javascript globale:
$(document).ready(function(){
  $('#bacheca')
    .bacheca({ bgcolor:"green", content:"Test Contenuto" })
    .bacheca('clear')
    .bacheca('write','Il mio nome è Marco')
  ;
});

Segnala presso:

JuniorCMS è utilizzato con pieno successo in moltissimi siti e progetti web di alto livello per strutture che fondano il loro business sulle vendite on-line e sul webmarketing.

Abbiamo realizzato gestionali operativi su scala nazionale (Gruppo Volkswagen) e abbiamo realizzato micro-gestionali per la bottega sotto casa.

Stiamo realizzando il progetto AdessoWEB che consente di avvicinarsi al business on-line con un prodotto professionale ma estremamente semplice ed intuitivo.

Ora vogliamo andare avanti.

Ciò che in questi anni non abbiamo realizzato è una community di sviluppatori che utilizzano questo prodotto.

FroggleCMS nasce per risolvere questo enorme problema e creare una soluzione di gestione contenuti basata sul concetto di sviluppo veloce (RAD).

Powerfull Plugins

Alla base del progetto abbiamo messo il concetto di “plugin” inteso come “raggruppamento logico di software e risorse atto a risolvere una precisa necessità“.

Le necessità che un plugin può risolvere sono anch’esse tipizzate in:

1. libreria: condivisione di librerie e framework
2. servizio: definizione di servizi condivisi all’applicativo
3. applicativo: definizione di software gestionale utile
4. estensione: intervento di modifica e/o estensione di altri plugins
5. custom: insieme di applicativo ed estensione ove inserire il codice personalizzato sul singolo progetto.

Il plugin di estensione o custom permettono di modificare in modo approfondito sul comportamento dei livelli ingeriori per implementare soluzioni specifiche senza creare fork del progetto.

Life Cycle Guarantee

Anni di esperienza nella progettazione di applicativi ci hanno insegnato l’importanza del ciclo di vita del software.

Molte piccole web agency (l’Italia ne è piena) si trovano a sviluppare progetti in velocità per sopravvivere sul mercato.

La creazione di soluzioni realmente riutilizzabili è molto difficile in quanto, di progetto in progetto, nascono nuove necessità, ottimizzazioni, verticalizzazioni.

Di fatto ci si trova quasi sempre a creare piccoli fork di progetti preesistenti con il triste risultato di produrre decine di sub-versioni incompatibili di un progetto inizialmente coerente.

Il nostro devTeam è stato a lungo vittima di questo processo!

La soluzione proposta da FroggleCMS consente di isolare qualunque software in plugins che possono essere migliorati e versionati come un qualunque software commerciale.

Nel momento in cui un particolare progetto richiede una particolare modifica ad un plugin esistente è possibile definire un plugin di estensione che apporta modifiche dall’esterno senza modificare le logiche esistenti.

Questa architettura è già implementata con successo su JuniorCMS e da oltre un anno ne godiamo i benefici per creare customizzazioni quali:

• aggiunta di campi personalizzati a strutture dati esistenti
• modificare l’interfaccia utente esistente per adeguarla al progetto
• inserire o modificare logica di controllo
• inserire o modificare logica di cooperazione tra plugins (es servizi di sincronizzazione)

Spaghetti Coding Proof:

Ecco le fasi di realizzazione di un Tipico Spaghetti Project:

1. Creazione in velocità di un plugin di gestione rassegna stampa con titolo e file allegato per un cliente.
2. Un nuovo cliente mi chiede la rassegna stampa ma ha bisogno di un campo abstract.
3. Copio il plugin già creato e lo modifico per il nuovo cliente.

Questo tipo di sviluppo lo vedo ogni santo giorno in qualunque realtà aziendale e la triste conseguenza (già citata sopra) è la proliferazione di micro plugins incompatibili tra loro.

La conseguenza più pericolosa è che se il “plugin madre” ha un grosso bug il tempo impiegato per correggere tutti i derivati è semplicemente apocalittico!

Ecco le fasi di realizzazione di un Froggle Spaghetti Project:

1. Creazione in velocità di un plugin di gestione rassegna stampa con titolo e file allegato per un cliente.
2. Un nuovo cliente mi chiede la rassegna stampa ma ha bisogno di un campo abstract.
3. Creo un nuovo plugin che estende la rassegna stampa aggiungendo il campo su db, l’interfaccia e la logica necessaria senza modificare la logica preesistente.

Questo tipo di sviluppo ha enormi vantaggi:

• mi permette di creare soluzioni veloci che possono essere migliorate e redistribuite in tempi più rilassati
• mi permette di gestire la sicurezza del software per singolo plugin senza preoccuparmi delle sue estensioni (che ereditano la sicurezza)
• mi permette di abbattere il numero di versioni incompatibili creando invece “catene di estensione” che possono essere facilmente versionate e mantenute
• mi permette di utilizzare e personalizzare qualunque plugin esistente (anche commerciale) senza violare licenze sul codice o simile.

Sviluppo di FroggleCMS:

1° Ottobre 2010: il devTeam di JuniorCMS da vita allo sviluppo dell’infrastruttura di FroggleCMS (CakePOWER).

1° Novembre 2010: viene rilasciato CakePOWER che implementa su CakePHP l’architettura presentata in questo articolo assieme ad altre architetture di importanza minore.

1° Dicembre 2010: viene rilasciato il plugin “froggle” che contiene l’interfaccia di base di FroggleCMS e la gestione utenti. Questo plugin è destinato ad essere frequentemente aggiornato con l’aggiunta costante delle funzionalità “core”.

1° Gennaio 2011: viene rilasciato il primo pacchetto auto-installante di FroggleCMS pronto per essere utilizzato in attività commerciali.

A questo punto daremo il via ad un programma di sviluppo plugins per coprire in breve tempo le principali esigenze di gestione contenuti on-line quali:

• gestione albero pagine sito web
• gestione news
• gestione rassegna stampa
• gestione calendario eventi
• gestione photo-gallery
• gestione prodotti generici
• gestione pagamento con carta di credito
• organizzazione dei prodotti per categorie
• gestione di un carrello elettronico complesso
• e-commerce (unisce precedenti plugins aggiungendo gestione sconti, gestione coupon, offerte, tasse, valute, magazzino, etc)

Il mercato di riferimento per questo prodotto è il nostro bel paese dunque tutta la documentazione sarà inizialmente prodotta in italiano mentre i commenti del codice sorgente cercheranno, per quanto possibile, di essere scritti in un decente spaghetti-english.

Ciao a tutti e buona fortuna al DevTEAM!

Segnala presso:

In questo articolo spiego come è possibile utilizzare dei layout contenuti in uno specifico plugin utilizzando quindi il concetto stesso di plugin per re-distribuire contenuti grafici oltre alle funzionalità contenute in helpers e components.

All’interno di un metodo di controller, appena prima del render (o della conclusione del metodo) è sufficiente specificare plugin e layout che si desidera utilizzare per il rendering della richiesta:

...
$this->plugin = 'Myplugin';
$this->layout = 'my_layout';
...

Questo tipo di codice produce la richiesta del file: “/app/plugins/myplugin/views/layouts/my_layout.ctp” da utilizzarsi come layout per la richiesta in corso.

Segnala presso:

L’autore ha la necessità di estrarre da un campo di testo un numero limitato di caratteri utilizzando l’operatore SQL LEFT:

LEFT(Table.field, len) as new_field_name

La soluzione proposta (e testata) consiste nell’utilizzo dell’operatore direttamente nell’elenco dei campi da estrarre come parametro aggiuntivo dell’operazione find().

$list = $this->User->find( "all", array(
  fields = array(
    'id',
    'username',
    'left(User.username, 5) as short_username'
  )
));

Questo comando di estrazione genera come output la seguente struttura associativa:

array(
  0 => array(
    [User] => array(
      [id] => 1
      [username] = Marco Pegoraro
    )
    [0] => array(
      [short_username] => Marco
    )
  )
)

Si può dunque notare come il campo ottenuto mediante operatore SQL sia stato erogato fuori dal raggruppamento del modello e inserito sotto ad un indice numerico.

Ho fatto alcuni test utilizzando le relazioni tra i modelli (belongsTo) e ho estratto campi da più modelli definendo campi elaborati da più modelli. Tali campi vengono sempre proposti sotto l’indice 0.

Al momento in cui scrivo la discussione è in attesa di una soluzione per modificare in modo esplicito il nome del raggruppamento di questi campi prodotto di un operatore SQL.

Alcune risorse utili:

• http://groups.google.com/group/cake-php/browse_thread/thread/f823cc7f168cd619?hl=en
• http://teknoid.wordpress.com/2008/09/29/dealing-with-calculated-fields-in-cakephps-find/
• http://i-love-cake.pastebin.com/f78d0639a (MySql Dbo variant)

Segnala presso: