2009-12-02 13 views
6

Ho un tipo di contenuto Ristorante. Per ogni ristorante, vorrei registrare il loro menu.Tipo di contenuto Drupal (ristorante) Design

I dati di esempio sarebbe simile a questa:

Bevande

  • Coke                                                 $ 4,99
  • Acqua Minerale                     $ 2,99

Cocktail

  • Blue Lagoon                           $ 9,99

    (X combinato con Y, ecc)

  • Red Sapphire                       $ 9,99

    (Un altro X mescolato con bla)

Pasta

  • classico bolognese       $ 13,69

    (Pasta a scelta mescolato con le nostre specialità fatte in casa salsa bolognese)


Come si può vedere, il menu consisteva di diversi componenti: categorie, nome del menu, descrizione, prezzo. Sarebbe anche bello se potessimo anche riordinare le categorie (alcuni ristoranti potrebbero preferire che le loro bevande vengano esposte prima del loro corso, mentre altre preferiscono il contrario).

  1. Come raccomanderesti la progettazione del tipo di contenuto?
  2. Se si dovesse utilizzare il riferimento al nodo, esiste un modo/modulo semplice per permettermi di modificare il menu direttamente dal modulo di modifica del ristorante? (forse alcune schede addizionale sullo menù)

risposta

3

Il modo in cui lo farei sarebbe probabilmente simile a questo:
nota, io sono abituato a sviluppare Drupal, quindi vorrei essere in grado di fare un sacco di questi le cose sono piuttosto veloci, dato che ultimamente ho fatto cose simili di recente. Questa potrebbe non essere la scelta migliore per te.

  1. In un modulo vorrei creare i due tipi di contenuto per questo, ristorante e menu_item.
  2. Probabilmente il ristorante sarà solo titolo e un altro campo che utilizzerei per i tipi di voci di menu. Non sono sicuro di come lo farei, dipende un po 'da cosa sarebbe il futuro del progetto. Potrei scegliere di non rendere il tipo di contenuto del ristorante o di non fare nulla di speciale e creare una tabella esclusivamente per l'ordine dei tipi di voci di menu.
  3. La maggior parte del tipo di contenuto della voce di menu può essere eseguita tramite CCK, ma probabilmente creerei una tabella e campi personalizzati per il loro ordine (questo è qualcosa che ho fatto alcune volte quindi ho snippet per rendere il js trascinabile sistema di ordinazione come quello che fa CCK per i campi di ordinazione). Potrei anche scegliere di gestire me stesso i prezzi, se ho bisogno di un controllo migliore in diversi casi, come fare calcoli di scambio ecc.
  4. Per le categorie userei la tassonomia (usando la tassonomia dà molti extra bonus come SEO) .
  5. Vorrei utilizzare il riferimento del nodo per collegare le voci di menu a qualsiasi menu che devono essere.
  6. Il resto dei campi di voci di menu è solo campi di testo che CCK gestirà correttamente.
  7. Vorrei utilizzare node_api per recuperare le voci di menu per i nodi del ristorante, in modo che con il tema, la visualizzazione del nodo del ristorante sarebbe la visualizzazione del menu (Se questa è la caratteristica principale, altrimenti farei una scheda per il menu e mantenere i dettagli del ristorante sulla vista del nodo).
  8. Con alcuni form_alter vorrei creare un sistema di ordinazione che è collegato a qualsiasi sistema che scelgo per ordinare le categorie.
  9. Potrei consentire agli amministratori di modificare l'ordine delle voci di menu stesse nella visualizzazione del nodo o di creare una scheda per esso. Dipende da ciò che il cliente vorrebbe.

Questo è un po 'pesante per gli sviluppatori, poiché molte di queste cose avrebbero bisogno di essere codificate. Potresti andare molto lontano usando solo cck e views, ma preferirei creare un modulo per questo. La ragione è che se il cliente vorrebbe che questo cambi in mezzo anno o con funzionalità aggiuntive, potrei trovarlo molto difficile implementarlo. L'integrazione con cck e view può essere molto complicata e richiede molto tempo, quindi l'utilizzo di un po 'di tempo extra ora lo renderebbe molto più flessibile ed estendibile. Ho anche fatto cose diverse che hanno alcuni motivi comuni, quindi sarei in grado di C/P un sacco di codice, che conosco bene, e basta regolarlo qua e là per alcune di queste cose. Questo è anche in parte il motivo per cui sto seguendo questa strada, poiché l'utilizzo di cck e visualizzazioni non mi avrebbe comunque risparmiato più di tempo

+0

Mi piace questa proposta, anche se non ci andrei a meno che altre parti del progetto non dovessero esplicitamente separare le diverse parti del menu (ma questa è una questione di filosofia di sviluppo, quindi non sto minimamente andando avanti per questo soluzione si male in alcun modo!). Mi piace soprattutto il punto n. 4 in quanto è vero che la tassonomia apporta diversi vantaggi di design - oltre al punto SEO googletorp già menzionato). – mac

+0

@mac Il percorso da eseguire dipende molto dal progetto. Alcuni dei miei progetti sono molto ben definiti e, in tal caso, vorrei sapere se tutto ciò sarebbe necessario o farei qualcosa di più semplice con meno codice. Ma se questo fosse per un sito che con il tempo sarà esteso in diverse aree, preferirei avere le cose più sotto controllo. Ma come dici tu, è una questione di filosofia di sviluppo. Un motivo per cui preferisco questa tattica, potrebbe anche essere il tipo di lavoro che ho fatto negli ultimi due mesi che non è stato con Drupal :) – googletorp

4

Tipo di contenuto RISTORANTE. Campi per nome dell'azienda, indirizzo commerciale, telefono, fax, sito web, email, IM, twitter, titolare dell'attività commerciale, contatto aziendale (come gestore), descrizione ristorante, logo e link posizione mappa google (o implementazione moduli posizione e gmap) ecc. Forse utilizzare il modulo a cinque stelle per abilitare le valutazioni degli utenti dei ristoranti.

Tassonomia hiearchical FOOD (modulo necessario per questo).Le categorie di alimenti sono bevande (alcoliche, non alcoliche, ecc.), Zuppe, insalate, colazioni, pranzi, cene, dessert, antipasti, sandwich, frutti di mare, ecc.

Tipo di contenuto FOOD. Campi per il campo di riferimento del nodo al nome RISTORANTE in modo che il loro menu venga creato e organizzato correttamente, selezione tassonomia hi-food, titolo dell'alimento (McRib, Whopper, Bloomin Onion, ecc.), Prezzo, opzioni di preparazione (media, ben fatto, ecc.), alimento (s), e le aggiunte che possono essere combinati con questo piatto dovrebbe essere o selezionare le opzioni di elenco o riferimenti nodo ad altri tipi di contenuto alimentare (purè di patate o al forno con che?)

per quanto riguarda le immagini, utilizzare imagecache per genera diverse dimensioni utili di tutte le immagini, quindi puoi ottenere miniature minuscole, immagini di dimensioni medie e foto stupende a grandezza naturale dei piatti.

Visualizzazione su CSS simile a un menau. Guarda i siti di ristoranti nazionali come Chilis.com per vedere come lo fanno. Fornire collegamenti di menu dei termini di tassonomia alimentare per ogni ristorante e una vista di ristoranti con filtri esposti in modo che gli utenti possano facilmente trovare ristoranti per tipo, posizione, valutazione a stelle, ecc.

Sembra un progetto divertente. Mi piacerebbe vedere un case study pubblicato quando hai finito.

+0

Qualcuno ha segnato questo -1? Inutile? Qualche idea del perché? Ho pensato che fosse utile, ho fornito una soluzione che rispondeva a tutte le parti della loro domanda. Forse mi sono perso qualcosa? Per favore dimmi cosa ho fatto di sbagliato? Penso che le persone che collegano una risposta in giù dovrebbero essere costrette a spiegare perché lo hanno fatto, per fornire un feedback costruttivo perché la risposta fornita non è stata utile. Altrimenti deve essere un brutto senso di competizione tra i rispondenti, come autori su Amazon che riesaminano i libri della concorrenza per migliorare il loro aspetto. C'è un wiki che discute questo problema? –

+0

C'è http://meta.stackoverflow.com per discutere di questo tipo di problemi. E sì, c'è già una discussione in corso su questo, ma il risultato finora sembra essere: no, il sistema è buono così com'è. Anche la mia soluzione è stata downvotata perché a qualcuno non piaceva l'approccio, anche se - come il tuo - è tecnicamente assolutamente valido: direi che è normale su SO essere a volte downvoted per questioni di stile/approccio/filosofia diversi. Se ci sono errori reali/informazioni sbagliate in una risposta - comunque - qualcuno te lo farà sapere in una frazione di minuto! ;) – mac

+0

ottima soluzione! Mi piace molto :) +1 – giorgio79

1

ho dovuto fare qualcosa di molto simile a questo. l'ho risolto con pannelli, viste e cck. ho creato un tipo di nodo 'ristorante' e un tipo di nodo 'menu_item'. la tassonomia menu_item viene impostata utilizzando un vocabolario specifico. ho usato i pannelli per visualizzare il menu per i percorsi nome-ristorante/menu, quindi le viste + cck per mostrare gli elementi nel menu (ho usato i riferimenti ai nodi per collegare gli articoli ai ristoranti). quindi ho raggruppato la vista per tassonomia: campo termine.

1

La prima idea che ho dovuto fare questo potrebbe essere qualcosa come segue:

tipo di contenuto
  • alimentare con: nome (titolo), descrizione (corpo) e il prezzo
  • tipo di contenuto Ristorante con più nodi cibo -Referenza campi
  • Vocabolario associata al cibo con termini come bevande, cocktail, pasta, .. (e sono abbastanza sicuro che ci sia un modulo che permette di definire i termini tassonomia pesi)

In questo modo, è possibile memorizzare i dati.

Per la parte visualizzazione, è possibile utilizzare:

  1. (approccio migliore) un nodo-restaurant.tpl.php personalizzato che crea la pagina formattata mostrando alimenti classificati per termine tassonomia (Sono abbastanza sicuro che avere accesso diretto ai nodi di riferimento attraverso le variabili del modello .. Vado a testare e ti faccio sapere)
  2. (potrebbe essere fatto attraverso il pannello di amministrazione) Una vista in un blocco collocato nella regione "contenuto" che mostra il riferimento nodi, formattati come una tabella raggruppata per termini di tassonomia nel vocabolario "Categoria alimentare". È possibile ottenere il nodo corrente nid (utilizzato per il filtraggio) utilizzando gli argomenti.

Suggerisco la prima scelta in quanto è più conforme agli standard, più rapida nell'esecuzione e potrebbe evitare alcuni possibili problemi che potrebbero derivare dalle viste + modo blocco.

+0

(Probabilmente l'approccio migliore sarebbe scrivere un modulo nodo che faccia questo creando un modulo AHAH a più valori, con categoria/titolo/prezzo/descrizione, ma immagino che questo non sia il tipo di soluzione che stai cercando ..) – redShadow

+0

.. e utilizzando il nodo-riferimento, hai anche il vantaggio di definizioni di cibo condiviso (ad esempio, se il prezzo del vino rosso cambia, si potrebbe averlo aggiornato automaticamente su tutti i menu, non solo uno ..). – redShadow

Problemi correlati