Hello to all!

I am creating a module restaurants, I have in mind to use the tables for the database: location, menu, ...

What could be more to add?

Thanks for your help

When it is ready, I add it on github.

winecard? ;)

Quote:
This is good ;)

Thank you!

In addition to customer lists, what can we add?

If I understand correctly, you want to add something which shows the menu, the locations etc?

In that case:
* Drinks cart
* Food carts
* Desserts
* Perhaps beer cart
* Locations
* Wine card
* Suggestions

And that's kinda everything I can think about :P

Kev

Don't reinvent the wheel!

Just go to http://www.sourceforge.net and search for restaurant:

https://sourceforge.net/directory/os:windows/?q=php+restaurant

Just by pure coincidence, I was looking for the same last week, and found that the mySeat was a very nice solution. But there are tons of others too.

So my recommendation:

1) search for existing solutions first (SourceForge and GitHub)
2) analyze their features so you know what your module should have
3) see if any existing XOOPS module could be modified to do it (e.g. Oledrion)
4) if not, see if any of these existing solutions could be easily ported to XOOPS, or merged with an existing module (e.g. Oledrion)
5) since most of them are old, see at some of the newest jQuery/JavaScript plugins/components that could spice up your module. Last week I was looking at this fantastic plugin for seat reservation. Check out the demo - it's really good

I've learned one thing over the last several years - whatever idea I have, I know that somebody somewhere had it already before me, and I can save a lot of time by leveraging their solution, instead of "reinventing the wheel" myself

Thanks Mamba!

I will do so, however, the Oledrion module is really outdated, it is worth to change it, when I create a base with tdmcreate 1.91?

This is exactly what I wanted to do with jquery, use for example an add form element to allow customers to add all the dishes and have the end the total expenditure price.

Quote:
It's really up to you, what you find more useful. However, sometimes it's better to fix/improve an existing module, instead creating a new one.

My personal preference would be to merge the best features from some existing modules and create one that is better than any of them individually, and provide users of these modules with a migration path to that one.

Publisher is the best example. We had News, xNews, AMS, SmartSections, but all of them could be migrated to Publisher. I prefer to work on and improve Publisher, and encourage all users to migrate to Publisher, because then we have less modules to maintain

We need to focus on more reuse between modules. The best example of reuse is what Mage did with the "ModuleAdmin", because now all modules can share it and we have a nice consistency between modules.

It's possible that we cannot adjust Oledrion to be a "Restaurant" module. But think how cool it would be, if we could transform Oledrion into a generic "eCommerce engine", and by adding a specialized plugins like a "Hotel", "Restaurant", or "Bookshop", being able to provide our users with such solutions. It would be much faster to develop such plugins and easier to maintain them, than having tons of different modules developed from scratch.

I hope, XMF and Bitcero's Common Utilities will help us to extract more and more common features that could be shared and reused between module....

Please do not change oledrion for your restauran module.
Oledrion is a ecommerce module and you want to build a presentation/content module.
You would need much more time to undestand and fix oledrion instead of creating a Restaurant module from scratch.
Oledrion is a powerfull ecommerce module and it should be used for this purpose

Quote:
Depends how you look at that!

If you want to manage a restaurant, it is way more than just creating a menu. It involves:
- the menu itself (products)
- reservation method (e.g. a table)
- ordering on line (e.g. for carry-out)
- payment on-line or in person
- inventory (food items, wine, etc.)

All of this stuff can be handled by Oledrion

However, this would not be to convert Oledrion into a Restaurant module, but instead, making it more flexible and powerful, so it could handle various tasks like Hotel, Restaurant, Bookshop, etc.

If you remember, Oledrion was based on the Bookshop module (see the original announcement), but it was made more generic in order to handle any product or service. So it would be possible to make it even more generic with an architecture that would allow for specialized extensions to handle any sale of any product, like a Hotel, Restaurant, Bookshop, etc.

And that's what forking is all about, i.e. he doesn't have to change the original code of Oledrion, he can just create something different and maybe more powerful, the same way as Trabis forked SmartSection into Publisher

It would be nice if someone would maintain the oledrion module adding new features. But this is the wrong way to do it.

Xoops is a web presentation or/and web community tool.
Why should someone make a inventory with xoops? Why should someone use restaurant payments with xoops?
Don't get this wrong, but let's stay with the purpose of cms.

A good ecommerce module for xoops is important but if you want to do professional ecommerce then you will use a professional free or paid ecommerce tools.

Let focus on xoops as cms.

This suggestion Quote:
are only for presentation purpose and not for administration of a restaurant.

Let's stay focused and make xoops powerfull in things that a cms should do.