cercasi slideshow semplicissimo

http://drupal.org/project/galleria

Gio, 29/04/2010 - 16:18

#3

Grazie, lo provo subito!!

Gio, 29/04/2010 - 16:23

#4

mmm forse non è ciò che mi serviva.

Le immagini le devo inserire all'interno di un nodo, ma non è la galleria ad esser un nodo, bensì ne fa parte.
Quindi, con Image caricherei le immagini in una directory (e ne crea i rispettivi nodi per immagini), poi Galleria ne prende atto e ne crea un nodo con alcune di esse e infine il mio nodo, tra le altre cose, preleva la Galleria da visualizzare...

Che matrioska!

Gio, 29/04/2010 - 16:30

#5

non è così che funziona.
galleria non crea nodi (la descrizione è fuorviante in questo)
galleria, semplicemente, prende le immagini allegate (tramite upload O imagefield) ad un nodo, e le visualizza come una galleria.
gli altri contenuti (campi) restano intatti e gestibili separatamente.
Inoltre, si può utilizzare l'altro metodo non usato da galleria (upload O imagefield) per inserire altre immafìgini fuori della galleria.

tanto per fare un esempio sto lavorando ad un content type con 20+ campi mostrati in vario modo, tra cui anche una galleria associata all'unico campo imagefield.

Gio, 29/04/2010 - 16:43

#6

Allora, ho installato oltre a Galleria qualcosa come jCarousel e ImageCache (e relativi moduli richiesti da questi); ho operato le configurazioni utili ma non in node/add non appare la possibilità di inserire nuove foto, né tanto meno si capisce in che modo potrei passare loro le foto in questione.

Qualche aiuto?

A me servirebbe poter inserire nella form di inserimento contenuto (per un custom content type simile a page) fino a 4 foto, le quali vengono ridimensionate opportunamente per lo slide show, il quale poi, in fase di node_view, mette su lo slide show così come serve.

Grazie.

Gio, 29/04/2010 - 16:51

#7

se hai configurato correttamente il modulo (galleria), non devi fare nulla in node/add.
se devi usare il modulo con imagefield e non con upload devi configurarlo specificamente: galleria è settato di default per funzionare con il modulo upload

nelle impostazioni del content type devi anche attivare galleria

il fatto che tu non trovi il campo immagine è strano; hai installato anche imageapi, imagefield e filefield? sono tutti nrcessari per il funzionamento di imagecache. poi devi configurare anche i preset di imagecache da usare nella galleria

Quote:
A me servirebbe poter inserire nella form di inserimento contenuto (per un custom content type simile a page) fino a 4 foto, le quali vengono ridimensionate opportunamente per lo slide show, il quale poi, in fase di node_view, mette su lo slide show così come serve.

ho capito quello che devi fare; ti ho suggerioto galleria perchè fa proprio questo: carichi le immagini e nel nodo compare la galleria

Gio, 29/04/2010 - 19:24

#8

ziobudda

Felagund ma il modulo CCK l'hai installato e configurato per aggiungere un campo di tipo ImageField al tuo tipo di contenuto ?

M.

--
Michel 'ZioBudda' Morelli -- [email protected]
Sviluppo applicazioni CMS DRUPAL e web dinamiche -- Corsi Drupal -- Amministrazione Drupal -- Hosting Drupal

Ven, 30/04/2010 - 00:06

#9

Scusate ma perché tutti questi moduli per fare questa cosa a livello banale? A me serviva un modulino semplice che, prese in consegna le immagini, mi organizava uno slideshow in JS.

Allora, ricapitolo ciò che ho fatto, magari mi dite dove devo correggere; inoltre cerco di seguire i vostri suggerimenti, anche se con tutti questi moduli e configurazioni ci sto capendo ben poco...

Ho installato e configurato Galleria e ImageCache il quale necessita di ImageAPI. Ho quindi configurato un preset (ma cos'è di preciso?), Galleria lo ha agganciato.
Poi ho installato sia jCarousel che Lightbox2, ma tra i due preferisco quest'ultimo.

A quel punto mi son fermato, poiché la domanda è stata "e adesso lo slide show da dove appare?"; ho quindi installato il modulo Image giusto per delle prove. Ho create 5 nodi Image e ho creato il seguente modulo di test:

<?php
function test_menu() {
  $items['test'] = array(
    'title' => 'Test'
    , 'page callback' => 'test_slideshow'
    , 'access arguments' => 'access content'
    , 'type' => MENU_NORMAL_ITEM
  );
  return $items;
}
function test_slideshow() {
  $output = "";
  for ($nid = 1; $nid < 5; $nid++) {
    $node = node_load(array('nid' => $nid));
    $output .= l(
      $node->title
      , $node->images['_original']
      , array('attributes' => array('rel' => "lightbox[roadtrip]"))). "<br />";
  }
  return $output;
}
?>

Cliccando sui link delle foto mi apre un overlay in JS devo dire di tutto rispetto; ma ancora non ho raggiunto la soluzione al problema.

Dopo ho appreso qualcosa in più dai vostri post che qui riprendo, così magari mi correggete.

Non ho ben capito a che serva ImageCache, però lo richiede Galleria.
Dal canto mio creo un nodo x di tipo y e, via Upload, invio n immagini; è corretto?
Al view di questo nodo dovrei aspettarmi uno slideshow, ma in che modo? Fa tutto Galleria "magicamente"?
Dal modulo Upload è possibile ridimensionare le immagini, cosicché da avere le anteprime ridotte e una misura standard di qualsiasi immagini inviata?

<a href="mailto:[email protected]" rel="nofollow">[email protected]</a> wrote:
tanto per fare un esempio sto lavorando ad un content type con 20+ campi mostrati in vario modo, tra cui anche una galleria associata all'unico campo imagefield.

In che modo stai definendo questo tuo content type?

Rispondo alle vostre domande.
Non ho installato imagefield e filefield poiché da nessuna parte mi veniva richiesto.
Ma senza CCK non si può fare niente? No, non l'ho installato, poiché il content type l'ho definito diversamente.

Grazie

Ven, 30/04/2010 - 00:56

#10

nessuno mette in dubbio, almeno io, che si possa fare in 100 modi diversi, tra cui sicuramente senza moduli contrib.

se segui quest'approccio, non so come aiutarti, mi dispiace.
CCK, views, imagecache, filefield, imagefield, sono la base comune della maggioranza dei siti in drupal; il motivo è semplice: coprono una buona fetta delle necessità di un sito, sono mantenute da una community efficientissima e si integrano quasi perfettamente tra loro.
se scrivi codice ad hoc, non solo reinventi la ruota, ma devi anche mantenerlo.....
secondo me, ovviamente.

se ci ripensi, ho creato una feature di esempio per un node type "galleria".
estrai la cartella in sites/all/modules e attiva la feature
ti servono:
features
cck
imageapi
imagecache
imagefield
filefield
galleria

l'unica cosa che devi fare dopo è impostare i due preset di esempio di imagecache (galleria_full e galleria_thumb) nella configurazione di galleria (admin/settings/galleria)

Ven, 30/04/2010 - 09:43

#11

Rispondo alle domande.

Quote:
Non ho ben capito a che serva ImageCache

Imagecache serve a gestire i vari formati (dimensioni ed altro) di ciascuna immagine presente sul sito.
questa pagina è molto chiara ed esplicativa al riguardo: http://drupal.org/node/163561

Quote:
Al view di questo nodo dovrei aspettarmi uno slideshow, ma in che modo? Fa tutto Galleria "magicamente"?

exactly. galleria e gli altri moduli citati fanno tutto magicamente (se correttamente impostati)

Quote:
Dal modulo Upload è possibile ridimensionare le immagini, cosicché da avere le anteprime ridotte e una misura standard di qualsiasi immagini inviata?

è esattamente quello che fa imagecache.

Quote:
In che modo stai definendo questo tuo content type?

con cck e moduli associati; tranne alcuni aspetti del theming o casi particolari, è tutto fatto via UI, niente codice.

Sab, 01/05/2010 - 16:45

#12

<a href="mailto:[email protected]" rel="nofollow">[email protected]</a> wrote:
nessuno mette in dubbio, almeno io, che si possa fare in 100 modi diversi, tra cui sicuramente senza moduli contrib.

se segui quest'approccio, non so come aiutarti, mi dispiace.
CCK, views, imagecache, filefield, imagefield, sono la base comune della maggioranza dei siti in drupal; il motivo è semplice: coprono una buona fetta delle necessità di un sito, sono mantenute da una community efficientissima e si integrano quasi perfettamente tra loro.
se scrivi codice ad hoc, non solo reinventi la ruota, ma devi anche mantenerlo.....
secondo me, ovviamente.

No, non penso di reinvitare la ruota poiché sto definendo un custom content type utilizzando le API messe a disposizione dal framework. Se avessi tentato di creare moduli come il CCK & co., allora si che in quel caso starei "reinventando la ruota"... è un po' come creare un tema: si definiscono tpl, css, si ritagliano le immagini, ma non sto ricreando il sistema che governa un tema in drupal. Allo stesso modo definisco gli elementi del mio content type senza reinventare il sistema che li gestisce. Quindi l'unica parte di codice da "mantenere" è ridotta solamente al sistema di API messe su, ed è compito di chi sviluppa drupal, non mio che le sto utilizzando.

<a href="mailto:[email protected]" rel="nofollow">[email protected]</a> wrote:

se ci ripensi, ho creato una feature di esempio per un node type "galleria".

Provo immediatamente il tuo esempio e ti lascerò un feedback.

<a href="mailto:[email protected]" rel="nofollow">[email protected]</a> wrote:

Quote:
In che modo stai definendo questo tuo content type?

con cck e moduli associati; tranne alcuni aspetti del theming o casi particolari, è tutto fatto via UI, niente codice.

Rispondo brevemente senz'andare off topic.
Dunque, io mi trovo a lavorare su drupal in situazioni atipiche, indi non ho l'obiettivo di risparmiare codice (anche perché la mia professione è quella di maneggiare codice intelligentemente), semmai quello di riutilizzarlo dove e come serve, e di risparmiarmelo se altri lo han già implementato per me.

Io mi trovo (diciamo) costretto ad utilizzare la componente framework di drupal, e quindi non posso sviluppare compilando delle form, bensì sfruttando le API messe a disposizione.
CCK & co. nel mio caso sono inutili poiché esistono diversi hook per poter definire il mio content type - indi non vado ad impelagarmi utilizzando le loro funzioni o a inviare form con drupal_execute -.
Ma allo stesso tempo, ad esempio, non creo un modulo per organizzare la taxonomy, bensì utilizzo le sue API per definire e gestire vocabolari e termini. Non so se rendo l'idea della sottile differenza che noto dal mio punto di vista.

Quindi se installo ImageCache per governare Upload e poi Galleria con Lightbox2 non risolvo il mio problema? Alla fine il fulcro del mio problema è esattamente questo - anche perché sto apprezzando il lavoro svolto da ImageCache -.

Grazie

Sab, 01/05/2010 - 18:28

#13

Grazie a te della spiegazione.
Concordo pienamente che l'uso corretto delle API non è "reinventare la ruota" ed è senz'altro un metodo valido.
Non sono sicuro che un approccio simile permetta di risparmiare codice, ma a differenza di te, il "mio mestiere" è più quello di utilizzare in modo efficiente il codice creato da altri, e quindi non sono molto ferrato nell'utilizzo diretto delle API e magari mi sbaglio.
Voglio dire: non capisco come un modulo come galleria (tanto per dire) che implementa una libreria JS per drupal, debba essere più pesante o meno efficiente di un modulo ad hoc che fa la stessa cosa.

Anche sull'inutilità di CCK ho i miei dubbi perchè l'API di CCK è sicuramente molto più potente della core API, per quanto riguarda la gestione dei content types.
Anche views si può bypassare con delle semplici query al db e susseguente formattazione dei risultati, ma anche qui non vedo come sia più efficiente. e, ripeto, tutto il codice "nuovo" che scrivi, va in qualche modo mantenuto. anche se si tratta di implementazione standard delle API

Sarei curioso di sapere perchè sei "costretto" ad usare la componente framework...

Detto ciò, se uno ne capisce veramente, le 20 API sono uno strumento di gran lunga più potente e flessibile del semplice uso dei moduli e delle loro UI. Quindi di vantaggi ce ne saranno sicuramente molti, ma io non ci arrivo, per ora ;P

Tornando IT: se lightbox + imagecache fanno quello che desideri, pernso che vada bene. d'altro canto si tratta solo di usare un'altra libreria JS invece di galleria. Concordo su imagecache: è una pietra miliare per drupal.

Sab, 01/05/2010 - 19:57

#14

<a href="mailto:[email protected]" rel="nofollow">[email protected]</a> wrote:
Grazie a te della spiegazione.
Concordo pienamente che l'uso corretto delle API non è "reinventare la ruota" ed è senz'altro un metodo valido.
Non sono sicuro che un approccio simile permetta di risparmiare codice, ma a differenza di te, il "mio mestiere" è più quello di utilizzare in modo efficiente il codice creato da altri, e quindi non sono molto ferrato nell'utilizzo diretto delle API e magari mi sbaglio.
Voglio dire: non capisco come un modulo come galleria (tanto per dire) che implementa una libreria JS per drupal, debba essere più pesante o meno efficiente di un modulo ad hoc che fa la stessa cosa.

E infatti non volevo rifare un modulo Galleria, bensì utilizzarlo. Come dicevo, maneggio codice, e cerco di farlo con una certa intelligenza. Sinceramente mi scoccio a star dietro al JS per quet'implementazione: non ne varrebbe la pena.

<a href="mailto:[email protected]" rel="nofollow">[email protected]</a> wrote:

Anche sull'inutilità di CCK ho i miei dubbi perchè l'API di CCK è sicuramente molto più potente della core API, per quanto riguarda la gestione dei content types.

mmm Quando vidi CCK per la prima volta chiesi se era possibile utilizzarlo via API, mi è stato risposto che era disegnato per un utilizzo via UI; quindi l'ho abbandonato.
Finora le core API hanno risposto brillantemente ai requisiti di sviluppo e non ho avuto mai alcun limite. In settimana mi documento sulle API di CCK & co. così potrò confrontare meglio. Comunque, osservando altri moduli del core o dal repo di drupal, ho notato che questi utilizzano le core API per i content type...

<a href="mailto:[email protected]" rel="nofollow">[email protected]</a> wrote:

Anche views si può bypassare con delle semplici query al db e susseguente formattazione dei risultati, ma anche qui non vedo come sia più efficiente. e, ripeto, tutto il codice "nuovo" che scrivi, va in qualche modo mantenuto. anche se si tratta di implementazione standard delle API

Esistono delle tecniche di sviluppo molto efficienti. Quanto prodotto non serve mantenerlo a meno che non cambiano le specifiche.

<a href="mailto:[email protected]" rel="nofollow">[email protected]</a> wrote:

Sarei curioso di sapere perchè sei "costretto" ad usare la componente framework...

Non scendo nei dettagli del mio lavoro, però considera che è come se stessi sviluppando contrib modules che andranno installati non so dove e non so da chi. Per quel che mi riguarda devo solamente produrre moduli o meglio riutilizzare moduli esistenti e adattati allo scopo (e li adatto overridando dove serve). Inoltre quanto prodotto andrà a finire in un repository dove altri colleghi aggiungeranno il proprio lavoro.

<a href="mailto:[email protected]" rel="nofollow">[email protected]</a> wrote:

Detto ciò, se uno ne capisce veramente, le 20 API sono uno strumento di gran lunga più potente e flessibile del semplice uso dei moduli e delle loro UI. Quindi di vantaggi ce ne saranno sicuramente molti, ma io non ci arrivo, per ora ;P

Io sarei a metà strada, nel senso che sono abbastanza nuovo di drupal, ma ho accumulato esperienze su altre tecnologie web che mi han dato gli strumenti per poter trattare con API, framework e via discorrendo - drupal l'ho trovato da subito molto semplice e intuitivo, oltre che bello xD -. Però tra il riutilizzare e il fare, preferisco il riutilizzare e l'overridare ;)

<a href="mailto:[email protected]" rel="nofollow">[email protected]</a> wrote:

Tornando IT: se lightbox + imagecache fanno quello che desideri, pernso che vada bene. d'altro canto si tratta solo di usare un'altra libreria JS invece di galleria. Concordo su imagecache: è una pietra miliare per drupal.

:D
mmm forse LightBox ci arriva vicino ma non fa il lavoro sperato. Anziché aprire l'overlay, dovrebbe occupare un'area predisposta all'ingrandimento dell'immagine.

Ma quindi Galleria è CCK-dipendente?
Se si, una domanda mi sorge spontanea: se un node type viene gestito poi dal core, qualsiasi sia il metodo per definirlo, perché allora Galleria è CCK dipendente? Dovrebbe "fregarsene" e funzionare, no?

Infine, non ho acceso il pc da lavoro oggi per provare il tuo esempio :D
lo farò lunedì XD

Grazie.

Sab, 01/05/2010 - 20:30

#15

galleria è indipendente da CCK se viene utilizzato con il modulo upload e non con filefield/imagefield (che è CCK dipendente)
Per tagliare la testa al toro vedi qui una demo. alleghi le foto al nodo ed il risultato è questo (ovviamente serve un po' di CSS per i ritocchi finali).

Quote:
mmm Quando vidi CCK per la prima volta chiesi se era possibile utilizzarlo via API, mi è stato risposto che era disegnato per un utilizzo via UI; quindi l'ho abbandonato.

spero di non essere stato io a dirti una fesseria simile!
puoi investigare la api di cck (content) e altri moduli contrib qui: http://api.zzolo.org/api/drupal/drupal-6-contrib--cck--content.module/dr...

tanto per fare un esempio, posto l'export di un content type, che è poi anche il metodo con cui definire content type tramite cck. questo codice (o parte di esso!) può essere importato direttamente in cck attivando il modulo content copy

<?php
$content['type']  = array (
  'name' => 'Image',
  'type' => 'image',
  'description' => 'an image content type for posting images and creating a simple image gallery',
  'title_label' => 'Title',
  'body_label' => 'Description',
  'min_word_count' => '0',
  'help' => '',
  'node_options' =>
  array (
    'status' => true,
    'promote' => true,
    'sticky' => false,
    'revision' => false,
  ),
  'old_type' => 'image',
  'orig_type' => '',
  'module' => 'node',
  'custom' => '1',
  'modified' => '1',
  'locked' => '0',
  'comment' => '2',
  'comment_default_mode' => '4',
  'comment_default_order' => '1',
  'comment_default_per_page' => '50',
  'comment_controls' => '3',
  'comment_anonymous' => 0,
  'comment_subject_field' => '1',
  'comment_preview' => '1',
  'comment_form_location' => '0',
);
$content['fields']  = array (
  0 =>
  array (
    'label' => 'Image',
    'field_name' => 'field_image',
    'type' => 'filefield',
    'widget_type' => 'imagefield_widget',
    'change' => 'Change basic information',
    'weight' => '31',
    'file_extensions' => 'png gif jpg jpeg',
    'progress_indicator' => 'bar',
    'file_path' => 'images',
    'max_filesize_per_file' => '',
    'max_filesize_per_node' => '',
    'max_resolution' => '800x800',
    'min_resolution' => 0,
    'custom_alt' => 0,
    'alt' => '',
    'custom_title' => 0,
    'title_type' => 'textfield',
    'title' => '',
    'use_default_image' => 0,
    'default_image_upload' => '',
    'default_image' => NULL,
    'description' => '',
    'required' => 1,
    'multiple' => '0',
    'list_field' => '0',
    'list_default' => 1,
    'description_field' => '0',
    'op' => 'Save field settings',
    'module' => 'filefield',
    'widget_module' => 'imagefield',
    'columns' =>
    array (
      'fid' =>
      array (
        'type' => 'int',
        'not null' => false,
        'views' => true,
      ),
      'list' =>
      array (
        'type' => 'int',
        'size' => 'tiny',
        'not null' => false,
        'views' => true,
      ),
      'data' =>
      array (
        'type' => 'text',
        'serialize' => true,
        'views' => true,
      ),
    ),
    'display_settings' =>
    array (
      'weight' => '31',
      'parent' => '',
      'label' =>
      array (
        'format' => 'hidden',
      ),
      'teaser' =>
      array (
        'format' => 'tiny_linked',
        'exclude' => 0,
      ),
      'full' =>
      array (
        'format' => 'full_imagelink',
        'exclude' => 0,
      ),
      4 =>
      array (
        'format' => 'image_plain',
        'exclude' => 0,
      ),
    ),
  ),
);
$content['extra']  = array (
  'title' => '-5',
  'body_field' => '0',
  'revision_information' => '20',
  'comment_settings' => '30',
  'menu' => '-2',
);
?>

Per quanto riguarda l'esempio che ho postato, tieni a mente che è una feature, il concetto è spiegato qui: http://developmentseed.org/blog/2009/may/29/making-and-using-features-dr...

Gio, 06/05/2010 - 13:02

#16