Drupal Content Type (Restaurant) Design
Asked Answered
R

4

6

I have one content type Restaurant. For each restaurant, I would like to record their menu.

The sample data would look like this:

Beverages

  • Coke                         $4.99
  • Mineral Water           $2.99

Cocktail

  • Blue Lagoon              $9.99

    (X combined with Y etc)

  • Red Sapphire            $9.99

    (Another X mixed with blah)

Pasta

  • Classic Bolognaise    $13.69

    (Pasta of your choice mixed with our home-made specialties bolognaise sauce)


As you can see,the menu consisted of several components: categories, menu name, description, price. It would also be great if we could also rearrange categories (Some restaurants might prefer their beverages to be displayed before their maincourse, while other prefer the opposite).

  1. How would you recommend the content type design?
  2. If it were to use node reference, are there any easy way / module to allow me to edit the menu directly from restaurant edit form? (Maybe some additionnal tabs for menu)
Radiotelegram answered 2/12, 2009 at 20:26 Comment(0)
K
4

RESTAURANT content type. Fields for business name, business address, phone, fax, website, email, IM, twitter, business owner, business contact (like manager), restaurant description, logo, and google map location link (or implement location and gmap modules) etc. Maybe use five-star module to enable user ratings of the restaurants.

FOOD hiearchical taxonomy (need module for this). Food categories are beverages (alcoholic, non-alcoholic, etc), soups, salads, breakfasts, lunch, dinner, desserts, entrees, sandwiches, seafood, etc.

FOOD content type. Fields for node reference field to the RESTAURANT name so their menu gets built and organized correctly, FOOD hiearchical taxonomy selection, food title (McRib, Whopper, Bloomin Onion, etc.), price, preparation options (medium, well-done, etc.), food image(s), and additions which can be combined with this dish should either be select list options or node references to other food content types (mashed or baked potatoes with that?)

Regarding images, use imagecache to generate several different useful sizes of all pics, so you can tiny thumbnails, medium sized images, and full sized gorgeous pics of the dishes.

Display on CSS that looks somewhat like a menau. Look at national restaurant websites like Chilis.com to see how they do it. Provide menu links of the food taxonomy terms for each restaurant, and a view of restaurants with exposed filters so users can easily find restaurants by type, location, star rating, etc.

Sounds like a fun project. I'd like to see a case study published when you're finished.

Kaciekacy answered 4/12, 2009 at 16:27 Comment(3)
Someone marked this -1? Not useful? Any idea why? I thought it was useful, I provided a solution that answered all parts of their question. Maybe I missed something? Please tell me what I did wrong? I think folks who dock an answer down ought to be forced to explain why they did so, to provide constructive feedback why the answer given was not helpful. Otherwise it must be an ugly sense of competition among answerers, like authors on Amazon reviewing competitor books down to make their own look better. Is there a wiki that discusses this issue?Kaciekacy
There is meta.stackoverflow.com to discuss this kind of issues. And yes, there is already a discussion ongoing on this, but the outcome so far seems to be: no, the system is good as it is. My solution got downvoted too because somebody did not like the approach of it, although - like yours - it is technically absolutely sound: I would say it is normal on SO to get sometimes downvoted for matter of different style / approach / philosophy. If there are real mistakes/wrong information in an answer - however - somebody will let you know that in a fraction of a minute! ;)Jiggered
great solution! I like it a lot :) +1Kial
K
3

The way I would do it would probably be like this:
Note, I'm used to developing Drupal, so I would be able to do a lot of these things pretty fast, since I done sometime similar recently. This might not be the best choice for you.

  1. In a module I would create the two content types for this, restaurant and menu_item.
  2. Restaurant will probably just be title and another field I would make used for the menu item types. I'm not sure how I would do it, it depends a bit on the what the future of the project would be. I might choose not to make the Restaurant content type or not do anything special to it, and create a table solely for the ordering of the menu item types.
  3. Most of the menu item content type can be done through CCK, but I would probably create a table and custom fields for their ordering (this is something I've done a few times so I have snippet for making the js dragable ordering system like what CCK does for ordering fields). I might also choose to handle the prices myself as well, if I need better control in different cases, like doing exchange calculations etc.
  4. For the categories I'd use taxonomy (using taxonomy gives a lot of extra bonuses like SEO).
  5. I'd use node reference to bind the menu items to whatever menu they need to be.
  6. The rest of the menu items fields is just text fields which CCK would handle nicely.
  7. I would use node_api to fetch the menu items for the restaurant nodes, so that with theming, the restaurant node view would be the display of the menu (If this is the main feature, else I'd make a tab for the menu and keep the restaurant details on the node view).
  8. With some form_alter I would create an ordering system that's hooked up to whatever system I choose for ordering the categories.
  9. I might let admins be able to change the ordering of the menu items themselves in the node display, or create a tab for it. Depends what the client would want.

This is a bit developer heavy, as a lot of these things would need to be coded. You could go a very far way just using cck and views, but I would rather create a module for this. The reason is that if the client would want this changed in half a year or come with additional features, I might get a very hard time implementing it. Integrating with cck and views can be very tricky and time consuming, so using a little extra time now, would make it a lot more flexible and extendable. I have also done different things that have some common grounds, so I would be able to C/P a lot of code, that I know well, and just adjust it here and there for some of this stuff. That's also partly the reason for me going this route, as using cck and views alone wouldn't be saving me that much time anyways

Kt answered 3/12, 2009 at 10:44 Comment(2)
I like this proposal, although I would not go for it unless other parts of the project would explicitly need to decouple the different parts of the menu (but this is a matter of development philosophy, so I am not understating going for this solution si bad in any way!). I especially like point #4 as it is true taxonomy brings several design advantages - beside the SEO point googletorp already mentioned).Jiggered
@Jiggered The route to take depends a lot on the project. Some of my projects are very well defined, and in such a case, I would know if all this would be needed, or I would make something more simple with less code. But if this was for a site that with time will be extended in different areas, I would prefer having things more under control. But as you say, it's a matter of development philosophy. One reason for me favoring this tactic, might also be the kind of work I've been doing the past month or two which hasn't been with Drupal :)Kt
B
1

i had to do something very similar to this. i solved it with panels, views and cck. i created a node type 'restaurant' and a node type 'menu_item'. the menu_item taxonomy is set by using an specific vocabulary. i used panels to display the menu for paths restaurant-name/menu, then views+cck to show the items in the menu (i used node referrences to link items to restaurants). then i grouped the view by taxonomy:term field.

Brute answered 6/12, 2009 at 15:14 Comment(0)
D
1

The first idea I had to do this could be something as follows:

  • Food content type with: name (title), description (body) and price
  • Restaurant content type with multiple food node-reference fields
  • Vocabulary associated to food with terms like Beverages, Cocktails, Pasta, .. (and I'm pretty sure there is a module that let you define taxonomy terms weights)

This way, you can store your data.

For the displaying part, you could use:

  1. (better approach) a custom node-restaurant.tpl.php that creates the formatted page showing food categorized by taxonomy term (I'm quite sure you have direct access to referenced nodes through the template variables.. I'm going to test that and let you know)
  2. (could be done through admin panel) A view in a block placed in the "content" region showing the referenced nodes, formatted as a table grouped by taxonomy term on the "Food category" vocabulary. You can get the current node nid (used for filtering) by using arguments.

I recommend the first choice since it is more standards-compliant, quicker in execution and could avoid some possible problems that could come from the views+block way.

Derive answered 1/4, 2010 at 15:43 Comment(2)
(Probably the best approach would be to write a node module that does this by creating a multiple-values AHAH form, with category/title/price/description, but I guess this is not the kind of solution you are looking for..)Derive
..and by using the node-reference, you also have the advantage of shared food definitions (eg. if the price of red wine changes, you could have it updated automatically on all the menus, not just one..).Derive

© 2022 - 2024 — McMap. All rights reserved.