Devo creare una quantità di nodi (dai 25 a 100) con contenuto che richiede blocchi personalizzati per 5 - 20 gruppi. Per esempio: per nodi in gruppo 1 bisogna visualizzare blocchi A e B, per gruppo 2, A e C, gruppo 3, D e E, ecc. I blocchi possono essere di testo fisso, o di un menù specifico, ecc, ecc.
Stavo pensando ad usare un vocabolario, ma qualcosa mi dice che un campo CCK sarebbe meglio.
In un progetto precedente ho creato n tipi di contenuto, e finchè n < 10 la cosa funzionò, ma aggiungendo condizioni di accesso al nodo rendeva la tabella permessi mostruoso. Il più grande problema era quando l'utente scriveva contenuto usando il tipo di contenuto sbagliato.
Quindi, sto pensando a creare una lista di gruppi, usando un campo CCK. L'utente può scegliere solo uno (o nessuno) dal gruppo. Secondo il valore di questo campo, verrano visualizzati (o non) una serie di blocchi. Per tipi di contenuto privo del campo, il valore sarà 'nessun gruppo'. Questo significa usare un test PHP per ogni blocco (o forse no?). Cercando di rimanere DRY, userò una chiamata ad una funzione, passando il nome del blocco.
Sfortunatamente, c'è poco informazione a disposizione per il test (mi sembra), e non voglio caricare il nodo per ogni blocco. Sto pensando ad un variabile global, che carico una volta solo (caricando il nodo una volta solo).
Qualcuno ha già fatto qualche sperimentazione lungo questa strada? Idee migliori?
Fra parentesi, mi piacerebbe capire la sequenza di lavoro di Drupal mentre costruisce tutti i pezzi del puzzle, per esempio quando carica i blocchi? Già dopo il nodo? I parametri disponibile al template page e node sono anche disponibile altrove? Qualsiasi dritta archittetturale sarà il benvenuto...
John
P.S. Happy new year (and decade)
ciao John, auguri!
non ho capito bene lo scenario, in ogni caso mi sembra che context possa esserti di aiuto.
Il modulo funziona in modo simile a trigger/action:
una volta impostate delle condizioni (un campo cck, una vocab o termine, un utente, un ruolo, etc)
ti permette di selezionare nelle "reactions" quali caratteristiche siano o meno visibili (ad es, blocchi).
Se raggruppi le caratteristiche di visualizzazione in features, la cosa è ancora più straightforward.
Ripeto, però ch3e non ho compreso bene lo scenario, quindi magari mi sbaglio....
Certified to Rock
Io ho fatto una cosa del genere usando un singolo nodo (story) la tassonimia, views e cck.
Ho creato un vocabolario sezioni e nei termini il nome delle sezioni con dei sottotermini chiamati "blocco in evidenza", "colonna destra", "colonna sinistra" ecc.
Con cck ho creato un campo nel caso debba essere inserito un breve testo introduttivo differente dal testo base e dal teaser.
Poi ho creato le viste per ogni termine in base alle esigenze della sezione. Per la "home" di ogni sezione ho usato il percorso della vista del termine base base (devi attivare la vista taxonomy_term).
In questo modo se es. bisogna inserire un testo nella sezione pincopallino se il testo deve andare nella posizione standard l'utente seleziona pincopallino se deve andare nel "blocco in evidenza" della sezione pincopallino seleziona "blocco in evidenza" di pincopallino ecc.
Sono stato deliberatamente vago nella mia descrizione del problema, perchè cercavo soluzioni generici. Devo ammettere che mi limitavo ad un collegamento fra nodi e blocchi. I blocchi possono contenere pubblicità, o un menù ristretto, o semplice testo/immagini.
@krima soluzione interessante, specialmente dato che non aggiunge moduli. Forse non ho capito molto bene, ma i blocchi sono dei views (con meccanismo views per la visualizzazione o non del blocco?), sarà più complesso avere blocchi con testo, menù, o un ad?
@bohz auguri anche a te, Carlo. Context mi sembra uno di quei moduli "eureka" - bisogna fare un salto mentale (paradigm shift) per capirlo bene. Ho passato un pò di tempo a leggere qualche blog, e vedere un video. Sembra che ci siano parecchi entusiasti in giro. Certi consideranno context importante quanto CCK e views - un grande complimento. Ho notato che anche tu hai dato peso a questo modulo più di una volta.
Grazie a tutti e due. Al rischio di investire un pò di tempo ad imparare ad usarlo, penso che context è molto interessante. Se non mi arriva il momento "eureka", posso sempre usare la tecnica di krima.
Più imparo, più dubito.
Sto sperimentando con Context, ma ho qualche dubbio... Drupal 6.15, Context 6.x-2.0-beta7
La pagina UI mi offre come condizioni: Node pages, User pages, Sitewide context, Path, Menu trail, e Views
Not for me. Niente campo CCK, vocab, termine, ruolo. Eri un pò troppo ottimista? Questione di altri moduli predisposte per Context? Versione di Context diverso?
Ho dato un occhiata al codice, trovando che (
context/context_contrib/context_contrib.module) Context si interfaccia con Nodequeue, Views, e CSS Injector. Poi ho trovato un articolo su come estendere Context per taxonomy terms: http://www.computerminds.co.uk/extending-drupal-context-module-allow-con...Yep, quello funziona benissimo.
Cioè convertire la 'configurazione' in un modulo - codice PHP. Okay.
A questo punto mi sembra che devo o (a) 'estendere' Context per un campo CCK, o (b) usare un Nodequeue, o (c) creare un tipo di contenuto aposto per ogni 'contesto' che mi interessa. Dato che ho solo 2 o 3 contesti, sono molto propenso di optare per soluzione (c).
Mi manca qualcosa? (oltre ad una quantità sufficiente di materia grigia)
John
Più imparo, più dubito.
my bad.
sono stato superficiale...scusami se ti ho fatto perdere tempo!
hai ragione tu, non ho controllato bene ed ho confuso le funzionalità di rules/conditional actions di ubercart con quelle di context.
Sorry, anche la mia materia grigia è quello che è...
sono d'accordo con la soluzione c) anche se views potrebbe essere usato come meta-filter ed invece di 2 o 3 content types, potresti creare altrettante views. dipende molto da quello che devi fare.
un'altra strategia potrebbe essere l'uso di path specifici.
ancora: con nodequeue si dovrebbero poter impostare delle "smartqueues" che raggruppano i nodi automaticamente in base ad un vocabolario o termine.
Leggendo un commento recente di vermario, mi è sovvenuto che anche panels ha una sua funzione di contesto (anche se non la conosco bene) e che quindi, in uno scenario = mostrare tanti blocchi specifici in base ad una condizione, forse (dico forse) anche panels potrebbe essere una soluzione.
per le integrazioni con altri moduli, l'unico che mi viene in mente è spaces, ma offre solo user space e group space. quest'ultimo dipende da OG
faccio qualche prova anche io...
Certified to Rock
Confermo che panels ha una serie di condizioni per specificare il context. Se fai l'override di un tipo di contenuto, hai poi a disposizione l'id del nodo come contesto, che puoi dare in pasto alle viste che inserirai come panel-pane in una delle regioni del pannello.
Per esempio qua:
http://codiceedizioni.it/catalogo/autori/marcello-cini
è una pagina fatta con panels come override del tipo di contenuto autore. a destra e sotto sono due viste che hanno come argomento appunto l'id dell'autore che si sta visualizzando. Il sito era con Drupal5, ora drupal6 e panels3 hanno parecchie opzioni in più.
Spero ti sia stato utile, buona giornata!
Mario
Mario Vercellotti (Vermario)
Freelance
http://www.verdevelop.com
Sì i blocchi sono delle views, ho avuto delle difficoltà iniziali per ideare il meccanismo ma poi la cosa è abbastanza semplice da gestire. Per ogni categoria di blocchi ho creato una vista specifica, ad esempio per tutti i blocchi che vanno a sinistra c'è una vista chiamata blocchi_sinistra. La vista ha delle caratteristiche base comuni poi personalizzo i filtri per ogni sezione.
In pratica una volta impostate le viste base che ti servono il resto è molto veloce da impostare con dei semplici override su ogni blocco.
Grazie Carlo per la risposta lampo...
Nessun problema. E non ho perso tempo.
Ah. Aspetta un momento. Io ho guardato la pagina Context per Views che dice "Set this context when displaying the page of one of these views", quindi ho concluso che la condizione è "siamo in una pagina views". L'idea di meta-filter mi renderebbe la vita più semplice, ma non vedo la connessione... Sto pensando a creare un Nodequeue (che non lo conosco per niente, neanche scaricato) costruito da una vista - è fattibile? Mi sono accorto che saranno più vicino a 5-10 content types. Forse meglio usare http://www.computerminds.co.uk/extending-drupal-context-module-allow-con... come esempio per filtrare secondo un campo CCK...
Si, ma se setto il pathauto per ogni content type, c'est la même chose - ma ho capito l'idea.
Come detto sopra, mi domando se si può fare un nodequeue per un (valore di un) campo CCK? Altrimenti penso che seguerò questa strategia o l'estensione Context (per taxonomy) citato sopra.
Si, ma sono quasi sicuro che si tratta di un 'context' diverso. Non c'è stato ancora un integrazione fra questi due moduli...
Alto la! Spaces richiede Features e PURL. Nella prossima vita (quella con tanto tempo libero) mi dedicerò anche a studiare questi. Ma per il momento sono limitato nel avere solo 24 ore in un giorno...
Grazie per le elucidazioni - a buon rendere
Grazie Mario, confermi anche che non si tratta di context nel senso del modulo context, ma di qualcosa di Panels?
Grazie krima, mi sento meglio con un piano B alle spalle. Tecnica C&B (cintura e bretelle)...
John
Più imparo, più dubito.
Ciao John.
ho fatto diverse prove:
1. context + nodequeue
- set 3 queues
- aggiunto (manualmente) nodi alle queues
- impostato context per ciascuna queue
pro: semplice e pulito, è possibile aggiungere/rimuovere i nodi dalle queues da una flag sul nodo
contro: l'aggiunta alle queue non è automatica (anche per le smartqueues basate sulla tassonomia), quindi questo sistema va bene se: i nodi devono essere aggiunti alle queue in modo completamente arbitrario E se sono inseriti da chi amministra le queue.
Per l'automazione si può usare rules (rule:add to nodequeue), ma è yet another module...
2. context + views
sulle views hai ragione tu. non possono fungere da filtro poichè limitate al display=page.
tuttavia views è utile perchè il contesto basato su nodetype/queue/taxonomy non è attivo nelle pagine di sommario (taxonomy/term per esempio). Usando la view appropriata nel contesto aiuta a mantenerne la consistenza
3. context + context_taxonomy (link che hai citato)
è senz'altro la soluzione più semplice e funziona benissimo, so far.
Serve sempre qualche view per mantenere il contesto nelle pagine di sommario.
4. Rimangono da investigare i contesti basati sui percorsi di menu
per spaces: ok, basta moduli. hehe
Certified to Rock
Anch'io Carlo - o almeno un pò di googling. Ho trovato questo: http://www.opensourcery.com/blog/jonathan-hedstrom/roll-your-own-contexts che descrive come creare un context per certi valori di un campo CCK. Non è generico, bisogna ripetere i valori del campo nel codice, ma va benissimo per il mio utilizzo. Molto simile a quello per taxonomy.
Quindi posso creare un tipo di contenuto, con campo single selection (o radio button) e una lista di 'sotto tipi'. Per ogni valore del sotto tipo creo un context, et voilà, mes amis.
Interessante le tue osservazioni:
1. Pensavo che sarebbe stato manuale anch'io. Va benissimo per un set eterogenico di nodi. Adesso aggiungo Rules alla lista 'to study'...
2. Cosi sia. Puoi anche usare path credo.
3. Si penso che è molto flessiile. In questo caso punto 2 va benissimo per coerenza, oppura path.
4. Mah. Non ho capito l'utilità. A me bastano tre modi (o quattro se leggi il link sopra)
Grazie per le tue prove, con questi risultati posso (finalmente) creare una soluzione semplice (non proprio elegante) ma potente ed abbastanza flessibile - aggiungendo una ventina di righe di codice.
Domani metto tutto alla prova.
Certo che context sembra proprio una bella pensata... Sarebbe interessante usarlo insieme a Features da progetto in progetto. Il talk di Mavimo mi ha convinto di features, credo che insieme questi due moduli saranno una bella copia...
John
Più imparo, più dubito.
ottimo link, grazie!
guarda anche questa patch: http://drupal.org/node/629756
(testing now)
[EDIT: testato con context 6.x-2.0-beta7. funziona "like a charm" con qualsiasi CCK field con allowed values. Unico problema: nella lista delle conditions compare direttamente il nome del campo, quindi se si hanno molti campi di questo tipo l'UI di context può diventare incasinata.]
Facci sapere come evolve la situazione, se possibile...
Buona giornata
Certified to Rock
Regola #1: leggi gli issues. Ho applicato il patch, e funzione perfettamente. Il codice e anche molto generico ed elegante, oltre che DRY - molto meglio del mio link.
Quindi per riassumere brevamente:
Beh, per il momento. Bisogna testare che la visibilità dei blocchi per ruolo funziona, ecc, ecc, ecc.
Grazie per il link al patch, Carlo. Direi che questa soluzione è molto potente...
[Edit]
Visto il tuo edit, quindi edito anch'io. Si può diventare incassinato, come tutto per il resto. Ma quando penso alla pagina permessi per 10 content types...
Aspetto qualche giorno per provare, poi segnalo il mio approvazione sul issue queue di context
[/Edit]
John
Più imparo, più dubito.
Mi accodo a questo topic per condividere come ho risolto un problema simile (ma piu' semplice):
dati certi valori di campi cck o termini di un determinato nodo visualizzare o meno dei blocchi ad hoc generati con views.
Nel mio caso ho aggiunto il campo cck discriminante al content type, creato un blocco view specificando come parametro il nid del nodo, impostato "Stabilire il parametro predefinito->ID nodo dall'URL", aggiunto come filtro della view il valore desiderato per il campo cck.