Menukaart restaurant

[perpixel]

Een vriend van mij heeft recent een eetcafé geopend en heeft aan mij gevraagd zijn site te doen. Ik (als goede vriend) heb hier natuurlijk ja tegen gezegd en aangegeven dit als vriendendienst te doen. Omdat ik er zelf natuurlijk ook wat uit wil halen wil ik er graag iets van leren.

Het idee is nu om de voorkant op te zetten als een "single page application" en daarbij gebruik te maken van vue.js, durendaljs of angular. Met geen van alleen heb ik echt ervaring en dus een mooie kans om te leren. Voorlopig komt er nog geen back-end achter, maar ik wil wel graag de data zo structureren dat het in de toekomst wel mogelijk is.

Het leek me dus logisch om de data alvast los in JSON op te slaan. Echter loop ik bij de menukaart tegen een probleem aan.

Het menu wordt uiteindelijk in tabbladen getoond met een tab voor iedere gang en binnen een gang kunnen meerdere categorieën zijn welke een titel krijgen met daaronder de gerechten.

Ik ben heel onervaren met het opslaan van data, maar ik denk dat zoiets dan toereikend zou moeten zijn:

JavaScript:

[
  {
    "_id": "57222dcc3b6f7539445b1383",
    "index": 0,
    "name": "et officia",
    "price": "$21.70",
    "course": "sunt",
    "category": "ad"
  },
  {
    "_id": "57222dcc01da550e537447c4",
    "index": 1,
    "name": "consequat labore",
    "price": "$26.93",
    "course": "non",
    "category": "nostrud"
  },
  {
    "_id": "57222dcc8c2a03caca1e9116",
    "index": 2,
    "name": "dolor sint",
    "price": "$23.85",
    "course": "sunt",
    "category": "mollit"
  }
]
 

Dan kun je voor elke "course" een tablad maken waarin over die gerechten gelooped wordt en deze bij de juiste categorie geplaatst worden.

Echter is het zo dat er een aantal gerechten zijn met meerdere prijzen (klein, middel, groot of friet, aardappelen, rijst).

Na dit verhaal zit ik met een paar vragen:

1. Deze manier van JSON opzetten. Correcte gedachte? of zou het beter zijn dit eerder op te delen in gangen met daarin categorieen en daar pas de gerechten in.
2. hoe ga ik om met soms een enkele prijs en soms meerdere prijzen met een aparte benaming

[Xudonax]

Maak je JSON een multi-level array, dat lijkt me de handigste oplossing. Denk zoiets:

code:

[
  {
    "_id": "1234567890",
    "index": 1,
    "name": "Hutspot",
    "prices": 
      {
        "Klein": 3.85,
        "Middel": 5.00,
        "Groot": 7.50
      }
  },
  {
    "_id": "1234567890",
    "index": 1,
    "name": "Boerenkool",
    "prices": 
      {
        "": 3.85
      }
  }
]

Hierbij ittereer je over de prijzen heen om ze te tonen, en heb je meteen labels voor als je fancy dingen wilt doen (bijv. een vegetarische variant, een variant met worst, een variant met een gehaktbal etc.)

EDIT: Ik zou misschien zelfs nog een niveau boven de gerechten maken voor de categorie/tab, het lijkt me dat het op die manier eenvoudiger is om de gegevens te parsen in JavaScript. Maar dat werkt natuurlijk alleen goed als een gerecht altijd maar in één categorie staat, anders ga je (veel) data dubbel verzenden.

[ Voor 20% gewijzigd door Xudonax op 28-04-2016 17:52 ]

[NMe]

Als aanvulling op Xudonax zou ik categorieën ook naar boven toe trekken:

JSON:

[
  {
    "name": "Categorie 1"
    "dishes": [
      {
        "_id": "1234567890",
        "index": 1,
        "name": "Boerenkool",
        "prices": {
          "Klein": 3.85,
          "Middel": 5.00,
          "Groot": 7.50
        }
      }
    ]
  }
]

edit:
Dat zegt Xudonax zelf na een edit inmiddels ook.

[ Voor 12% gewijzigd door NMe op 28-04-2016 17:57 ]

[simon]

Waarom zijn je id's tekst eigenlijk? Een uniek oplopend getal als ID is in mijn ogen beste setup. Verder met rest.

[ Voor 4% gewijzigd door simon op 28-04-2016 17:59 ]

[Edwin88]

simon schreef op donderdag 28 april 2016 @ 17:59:
Waarom zijn je id's tekst eigenlijk? Een uniek oplopend getal als ID is in mijn ogen beste setup. Verder met rest.

Dit is in veel gevallen een best-practice om rip-scripts te voorkomen. Unique ID's zorgen er voor dat iemand met API access bijvoorbeeld niet je hele dataset kan rippen door /restresource/1-1000 op te halen.

In dit geval is het misschien niet zo nodig, maar het zou voor de meeste implementaties niet uit moeten maken.

[edit: wat achtergrond info]
http://blog.codinghorror.com/primary-keys-ids-versus-guids/

[ Voor 18% gewijzigd door Edwin88 op 28-04-2016 20:46 ]

[perpixel]

Edwin88 schreef op donderdag 28 april 2016 @ 20:44:
[...]


Dit is in veel gevallen een best-practice om rip-scripts te voorkomen. Unique ID's zorgen er voor dat iemand met API access bijvoorbeeld niet je hele dataset kan rippen door /restresource/1-1000 op te halen.

In dit geval is het misschien niet zo nodig, maar het zou voor de meeste implementaties niet uit moeten maken.

[edit: wat achtergrond info]
http://blog.codinghorror.com/primary-keys-ids-versus-guids/

Het idee (als ik er aan toe kom) is om het backend-less op te bouwen en dan inderdaad met een cms en een rest API de content op te halen. Waardoor het iets relevanter wordt.

Xudonax schreef op donderdag 28 april 2016 @ 17:51:
Maak je JSON een multi-level array, dat lijkt me de handigste oplossing. Denk zoiets:

code:

[
  {
    "_id": "1234567890",
    "index": 1,
    "name": "Hutspot",
    "prices": 
      {
        "Klein": 3.85,
        "Middel": 5.00,
        "Groot": 7.50
      }
  },
  {
    "_id": "1234567890",
    "index": 1,
    "name": "Boerenkool",
    "prices": 
      {
        "": 3.85
      }
  }
]

Hierbij ittereer je over de prijzen heen om ze te tonen, en heb je meteen labels voor als je fancy dingen wilt doen (bijv. een vegetarische variant, een variant met worst, een variant met een gehaktbal etc.)

EDIT: Ik zou misschien zelfs nog een niveau boven de gerechten maken voor de categorie/tab, het lijkt me dat het op die manier eenvoudiger is om de gegevens te parsen in JavaScript. Maar dat werkt natuurlijk alleen goed als een gerecht altijd maar in één categorie staat, anders ga je (veel) data dubbel verzenden.

Top! precies wat ik ook dacht na het schrijven van mijn vraag, maar fijn dat ik nu bevestiging heb.

Waar ik nog een beetje mee zit is dat de "view" van het eten veranderd wanneer er meerdere prijzen zijn bijv.:
Categorie 1 (enkele prijs)

Gerecht1	Prijs
Gerecht2	Prijs

Categorie 2 (meerdere prijzen)

	Klein	Midden	Groot
Gerecht1	Prijs 1	Prijs 2	Prijs 3
Gerecht2		Prijs 2	Prijs 3

Hoe kan ik dan bepalen welke "view" hij moet gebruiken en welke titels hij bij de prijzen plaatst.

[Xudonax]

Je kunt kijken hoeveel items er in de arrays zitten, of je definieert dat categorie X altijd klein/midden/groot heeft als labels. Mocht dat voor een recept niet ingevuld zijn dan maak je er een <td colspan="3"> van ipv een gewone <td> tag.

[Edwin88]

perpixel schreef op donderdag 28 april 2016 @ 21:56:
Waar ik nog een beetje mee zit is dat de "view" van het eten veranderd wanneer er meerdere prijzen zijn bijv.:
Categorie 1 (enkele prijs)

Gerecht1	Prijs
Gerecht2	Prijs

Categorie 2 (meerdere prijzen)

	Klein	Midden	Groot
Gerecht1	Prijs 1	Prijs 2	Prijs 3
Gerecht2		Prijs 2	Prijs 3

Ik zou niet voor elke prijsvariatie een column maken; dan beperk je jezelf later als je bijvoorbeeld meerdere verschillende variaties van 1 menu-item wilt hebben, die niet op alle menu-items toepasbaar zijn.

Beter is het denk ik zo:

Gerecht1	Klein 1,- Groot 2,-
Gerecht2	1,50

met uiteraard wat mooiere styling.

Zo kan je ook je JSON simpel doorlopen en prijzen printen zolang een menu-item prijs-variaties heeft.

[perpixel]

Precies. De tables waren natuurlijk ook als voorbeeld. Ik hou nu ook teveel vast aan het (slecht) opgemaakte menu zoals het is aangeleverd. Dat hoeft natuurlijk niet.

Als ik het binnen redelijke tijd gedaan heb zal ik hier nog wel het resultaat laten zien. Bedankt voor de hulp allemaal.

[simon]

Edwin88 schreef op donderdag 28 april 2016 @ 20:44:
[...]


Dit is in veel gevallen een best-practice om rip-scripts te voorkomen. Unique ID's zorgen er voor dat iemand met API access bijvoorbeeld niet je hele dataset kan rippen door /restresource/1-1000 op te halen.

In dit geval is het misschien niet zo nodig, maar het zou voor de meeste implementaties niet uit moeten maken.

[edit: wat achtergrond info]
http://blog.codinghorror.com/primary-keys-ids-versus-guids/

offtopic:
de reacties er onder zeggen in mijn ogen al redelijk veel, het tegengaan van het rippen van een dataset door je database design te verbouwen lijkt mij redelijk contra-intuitief. Op de kleine database in dit voorbeeld zal het niet veel effect hebben, maar op grote databases lijkt het me niet handig. Een GUID naast een UID kan ik me voorstellen, maar de performance en size effecten op grote DB's lijken mij niet te onderschatten.

[Edwin88]

simon schreef op vrijdag 29 april 2016 @ 11:07:
[...]

offtopic:
de reacties er onder zeggen in mijn ogen al redelijk veel, het tegengaan van het rippen van een dataset door je database design te verbouwen lijkt mij redelijk contra-intuitief. Op de kleine database in dit voorbeeld zal het niet veel effect hebben, maar op grote databases lijkt het me niet handig. Een GUID naast een UID kan ik me voorstellen, maar de performance en size effecten op grote DB's lijken mij niet te onderschatten.

offtopic:
het gebruik van GUID is ook voornamelijk voor front-end anti-rip mogelijkheden. Of je in je backend volledig GUIDs gebruikt of ook traditionele ID's is natuurlijk vrij om te kiezen afhankelijk van je schaal. Maar dat staat ook in die comments.

[Galinsky]

Over de view van de gerechten:
Ik zou het net zo weergeven als dat het op de fysieke menukaart staat. Sommige (oude) mensen kijken misschien eerst online en dan bestellen ze het. Als de kolommen anders op de site staan kan dat misschien voor verwarring zorgen. Ook zit het er overzichtelijker/ netter voor de klant uit.

[Verwijderd]

Voor het wisselen van de view: als je er een container-DIV omheen hebt staan waar je de class van aanpast kun je aan de hand van de selecties heel simpel de weergave van items aan en uit zetten. Iets als

Cascading Stylesheet:

#menukaart > div {
    display: none;
}
#menukaart.stamppot > .stamppot {
    display: block;
}

HTML:

<div id='#menukaart' class='stamppot'>
    <div id='57222dcc3b6f7539445b1383' class='stamppot'>
        <!-- zichtbaar -->
    </div>
    <div id='4353456c3b6f7539445b1383' class='vegetarisch'>
        <!-- niet zichtbaar -->
    </div>
</div>

[perpixel]

Galinsky schreef op vrijdag 29 april 2016 @ 11:27:
Over de view van de gerechten:
Ik zou het net zo weergeven als dat het op de fysieke menukaart staat. Sommige (oude) mensen kijken misschien eerst online en dan bestellen ze het. Als de kolommen anders op de site staan kan dat misschien voor verwarring zorgen. Ook zit het er overzichtelijker/ netter voor de klant uit.

Normaal zou ik het met je eens zijn. Ik ben helemaal voor continuïteit, maar in dit geval zal het menu zo vaak veranderen (en is het eigenlijk ook nog niet echt vormgegeven). Dat ik me daar nu niet heel druk om maak.

Verder geloof ik er niet in dat mensen op de site van een restaurant al tot de letter precies kiezen wat ze willen. Het menu is er als indicatie van de gerecht soorten en prijzen daarvan. Ik denk ook niet dat iemand erdoor verwart zal raken.