/lieblingsessen befehl hinzufügen

[hendricokakiko]

/lieblingsessen oder /config, /edit soll das fav_food in der db erweitern, oder löschen wenn eintrag bereits vorhanden ist. und natürlich dem user die aktuelle fav_food liste anzeigen.

[lukruh]

ich hab mir nochmal überlegt ob es vielleicht cooler wäre statt (oder zusätzlich) nen string anzugeben, essens objekte zu erstellen, die einen Namen, eine liste von wörtern, die es triggern eine optionale kurzbeschreibung und ein optionales bild haben und ein public status (andere können es aus ner liste auswählen). Dann könnte man tatsächlich etwas algemeinere dinge eintragen, wie Burger, Nudeln, Nudeln mit Gulasch aber auch sehr konkrete.. Das würde für den User sicherlich sehr viel hübscher wirken, wäre allerdings mit etwas mehr programmieraufwand verbunden.

Als beispiel aus Nutzersicht: /lieblingsessen burger erstellt ein neues (privates) essens objekt namens burger mit suchwort burger. /lieblingsessen zeigt eine Liste mit öffentlichen/offiziellen Lieblingsessen (zur zeit weihnachtsessen und grünkohl) Klinkt erstmal nach unnötig viel Aufwand: Aber, dieser Ansatz würde es zum Beispiel erlauben, das Nutzer oder wir selbst (über den bot oder ein webformular) neue Lieblingsessen mitsamt den Alarmstrings und einer liste von Stichwörtern eingeben können. Und man zB sehen könnte wieviele Leute haben welches essen aboniert... und soweiter..

Was hälst du von dem Ansatz? Also ausgewählte lieblingsessen nicht im User zu speichern, sondern in ner Essens tabelle, dann hätten auch nicht mehrere leute nen string 'tagessuppe' sondern alle würden auf 1 Tagessuppen objekt zeigen (was das nachträgliche ändern vereinfacht, wenn die mensa es zB in Tagessüppchen umbennen sollte) Und im User speichert man dann ne liste von Essensobjekten mit einer sogenannten (ManyToMany verknüpfung) würde mir dann nochmal anschauen wie das genau mit sqlalchemy geht, aber da gibts glaub ich einfach nen datentyp für genau wie integer oder boolean

[hendricokakiko]

würde erstmal individuell einstellbar lassen, und wenn wir sehen wie sich die suchanfragen clustern kan man ja vorlagen erstellen, namentlich burger

[lukruh]

ok, denke auch son formular ist erstmal total overkill, aber ob wir schon direkt essensklasse erstellen wäre ne überlegung wert um später nicht soviel umbauen zu müssen.. wobei warscheinlich macht das dann auch eher sinn wenn man nen konkreten plan hat, was die klasse können soll damit man sie später nicht mehr so sehr umbauen muss... Dann setz ich das mal auf die gedankliche "Features in the future"-Liste

[lukruh]

ich nehme mich dem mal an... erstmal nur mit den strings

[lukruh]

Also ich würds jetzt erstmal so machen das /favfood = /lieblingsessen mit argumenten das erste argument (oder alle?) direkt an die string liste anhängt (oder diese ersetzt?) Ein zusätzlicher befehl kann ja bestimmte oder alle essen löschen (auf default zurücksetzen) Wenn keine parameter übergeben werden also nur /lieblingsessen würde ich das direkt auf die seite im configdialog linken, in der dann ne erklärung zu dem befehl steht...

fändest du löschen mit /lieblingsessen remove grünkohl oder /lieblingsessenlöschen grünkohl geiler? ich glaub letzteres ist einfacher, das mit den argumenten scheint die meisten user ja zu überfordern.. solche befehle müssen dann ja nicht im quickstart stehen sondern iwo in ner detail info/hilfe

[lukruh]

gut was geschafft heute ;) getestet wird das nächstemal scheint erstmal alles zu laufen.. nur wenn man alles löscht, behält man das letzte komma sieht bisschen dumm aus funzt aber trotzdem... müssen nur sicherstellen, dass das die suche nicht beeinflusst.. außerdem muss noch geprüft werden ob groß-kleinschreibung auch wirklich keine rollespielt ('blabla' in 'blaBLAB' true oder false?) wenns sensitive ist fixen in del_fav_food()