Eindeutige ID für Kategorie?

Deutsches Forum
1

Hallo lieber OXIDler,

ich habe festgestellt, dass die Kategorien nur über oxid identifiziert werden, statt durch einen festen, betriebwirtschaftlichen Begriff wie z.B. “clothing” (Title wird nicht funtionieren, da das Feld multi-lingual ist). Es ist dann sehr schwierig, features einzubauen, die von Kategorien abhängig sind (wie z.B. jenach Kategorien wird entschieden, ob man den Button “in den Warenkorb” anzeigt oder nicht), da ich nicht beim Programmieren schon weiss, welche oxids werden für die Kategorien generiert; aber von einem festen Kategorie ID wie “clothing” schon.

Vielleicht ist es eine potentielle Verbesserung?

VG, Ge

2

Wo ist das Problem?
Du kannst als OXID auch von dir vorgegebene Werte nehmen, antatt den Zufallszahlen und Buchstabenkombinationen die der Oxid-Shop standardmäßig verwendet. Du kannst solche Strukturen z. B. einfach importieren oder von einer Wawi füllen lassen.
Du musst “lediglich” sicherstellern, das die OXID die du einmal vergeben hast nicht aus Versehen noch ein 2.mal benutzt wird. Weil ab dann treten Probleme auf.

Bei festen “betriebswirtschafliche Begriffen” ist die Gefahr natürlich deutlich höher, das man Werte doppelt oder dreifach benutzt.

3

[QUOTE=ChristophH;76792]Wo ist das Problem?
Du kannst als OXID auch von dir vorgegebene Werte nehmen, antatt den Zufallszahlen und Buchstabenkombinationen die der Oxid-Shop standardmäßig verwendet. Du kannst solche Strukturen z. B. einfach importieren oder von einer Wawi füllen lassen.
Du musst “lediglich” sicherstellern, das die OXID die du einmal vergeben hast nicht aus Versehen noch ein 2.mal benutzt wird. Weil ab dann treten Probleme auf.

Bei festen “betriebswirtschafliche Begriffen” ist die Gefahr natürlich deutlich höher, das man Werte doppelt oder dreifach benutzt.[/QUOTE]

Hi Christoph,

da hast Du Recht, man kann programmisch immer oxid festlegen. Mein Anliegen ist eher, dass man auch im Admin UI einen ID (kann ja auch den oxid sein) festlegen, da nicht jeder Shoptreiber programmiert.

Als workaround kann ich den oxid der Kategorien auch direkt ändern, nur oxid ist für mich eher eine technische ID, eignet sich nicht so ganz wie z.B. die Produktnummer (eigentlich auch schlechtes Beispiel, da die auch doppelt sein kann).

VG, Ge

4

Wer die oxid via Code für bestimmte Zusatzfunktionen ansprechen will, der hat auch genügend Kenntnisse um diese nach Wunsch festzulegen.

Diese Funktion macht ansonsten keinen Sinn. Im Gegenteil, sie birgt eher das Risiko der (versehentlich) doppelt vergebenen IDs.

5

Also das machen wir, wenn wir soetwas brauchen, einfach über ein zusätzliches DB Feld dass dann im Admin interface angezeigt wird. Das ist eine Sache von 10 Minuten.

6

[QUOTE=Hebsacker;76796]Wer die oxid via Code für bestimmte Zusatzfunktionen ansprechen will, der hat auch genügend Kenntnisse um diese nach Wunsch festzulegen.

Diese Funktion macht ansonsten keinen Sinn. Im Gegenteil, sie birgt eher das Risiko der (versehentlich) doppelt vergebenen IDs.[/QUOTE]

Hi Ray,

da bin ich nicht ganz so sicher - Die Produktnummer ist ein Gegenbeispiel. Und man kann dazu auch das Feld Unique machen.

Kenntnis habe ich zum Glück schon inzwischen, nur ich denke hier kann man nach einem “Standard” Feature fragen - d.h. es ist dann auch ein festes Feld für die Zukunft und muss niemand immer dasselbe tun.

Ich erweitere momentan das Shop und habe bestimmte Funtionen, die eigentlich über Kategorien gut lösen lassen - wenn die Kategorien eine logische ID wie Produkte hätten. Also die Kategorien dienen hier wie eine Art Konfiguration, mit denen man Business Logik abbilden kann.

VG, Ge

7

Auch die Artikel haben eine oxID, mit der sie eindeutig identifiziert werden, nicht anhand der Produkt-/Artikelnummer.

8

[QUOTE=Hebsacker;76962]Auch die Artikel haben eine oxID, mit der sie eindeutig identifiziert werden, nicht anhand der Produkt-/Artikelnummer.[/QUOTE]

Hi Ray,

ich bin sofern einverstanden, dass oxid eindeutig alles im OXID shop technisch identifiziert, und könnte auch für Kategorie benutzt werden.

Ich denke es sind eher verschiedene Blickwickel von uns: ich rede von einem größeren Geschäftsumfeld, wobei viele Business-Benutzer mit OXID umgehen müssen, während Du es anschaust aus der Entwicklung. Also werde ich versuchen, das ganze etwas anders zu formulieren, damit es klarer für alle würde:

Ich komme selbst aus Beratung von Enterprise Software, hauptsächlich im Datenmanagement. Heutezutage ist das Hauptprinzip, dass Datenobjekte immer zwei Schlüssel besitzen, ein Business Key (ähnlich wie Produktnummer, man könnte auch in der Nummerierung Logik einbauen, wie z.B. 1000 - 1999 sind Schuhen, muss man aber nicht), ein technisches Key (eher oxid, immer generiert und nicht-sprechend), und beide sind “eindeutig”. Es geht hier nicht nur um Entwicklung, es geht hier auch um den Betrieb - Business Key dient zu Kommunikation, Identifizieren zwischen den Business Usern oder auch Endbenutzern; z.B. niemand von Endkunden wird sich für oxid interessieren, auch nicht die Mitarbeiter, die jeden Tag die Produkte, Kategorien, Attributen usw. im Shop pflegen. Also es ist immer gute Praxis, die zwei Keys sauber zu trennen, beide haben ihre eigene Zwecke. Das ist auch warum, ich hier nach ein Standard-feature von business key für Kategorien und andere fragen; es tut mir schwer, in oxid die Business Keys zu schreiben.

Ein Szenario in Real-Life: ein großes Shop mit 10 Leuten allein die Produkte in 100 Kategorien in 10 Sprachen pflegen, jede Kategorie hat durchschnittlich 10 Attributen. Das Shop soll u.a. anhang der Produktkategorie automatisch auch die Shipping Method, Zahlungsmethoden festlegen, da Möbel zu transportieren verlangt mehr Aufwand als Kleidung (nur Beispiel). Da Produktkategorie fast die einzige Methode ist, die Produkte gruppiert (auch in einer Hierarchie), es ist eine natürliche Wahl. Aber auf der Oberfläche im Admin kann man leider die Kategorien nicht eindeutig identifizieren! Auch nicht die Attributen. Also wie könnten die 10 Leute, die jeden Tag so viele Produkte pflegen müssen, effizient kommunizieren, dass z.B. in der Kategorie “ABC” eine andere Shipping Method/Kosten verwendet wird, da der Logistiker gewechselt wird?

Ich hoffe das Szenario hilft ein bisschen, um mein Anliegen zu klären. Also hier geht um zwei Vorgehensweise: für kleinere Shops, wobei die Techniker meistens auch den Shop betreiben, reicht auch eine “technische Lösung”, während für große Shops, die ganze Planung über Produkte, Kategorien, Attributen usw. kommen eher aus Business und Business wird auch gerne sehen, dass sie die Business Keys im Shop Admin wieder finden, statt eine 32-stellige Nummer, die kein Mensch versteht.

Da OXID auch den Markt für große Kunden behaupten möchte, glaube ich es ist ein sehr wichtiges Feature. Meiner Meinung nach ist es ein Designlücke wo man schnell was machen sollte.

VG, Ge

9

Naja, aber für große Shops braucht es schon (min.) einen kompetenten Entwickler hintendran. Es werden sicherlich noch mehr Dinge abweichend vom Standard benötigt. Und wie Aggrosoft gesagt hat, dieses Feature ist in wenigen Minuten implementiert und daher eigentlich nicht der Rede wert. Sieh OXID eher als eine solide Plattform auf der man gute Shops aufbauen kann. Jeden Anspruch eines jeden Kunden von Anfang an zu implementieren ist ein Ding der Unmöglichkeit. Das sollte ein Berater für Enterpriselösungen sicher verstehen, da sitzen nämlich die meisten Individualisten.
Wenn dir aber ein Feature in Oxid fehlt und du sagst das muss unbedingt rein, so bietet dier Oxid die Möglichkeit dir über die Uservoice Gehör zu verschaffen und bei genug Gleichgesinnten kommen die Vorschläge auch in den Core.

Grüße

Rafael

10

[QUOTE=Rafael Dabrowski;77048]Naja, aber für große Shops braucht es schon (min.) einen kompetenten Entwickler hintendran. Es werden sicherlich noch mehr Dinge abweichend vom Standard benötigt. Und wie Aggrosoft gesagt hat, dieses Feature ist in wenigen Minuten implementiert und daher eigentlich nicht der Rede wert. Sieh OXID eher als eine solide Plattform auf der man gute Shops aufbauen kann. Jeden Anspruch eines jeden Kunden von Anfang an zu implementieren ist ein Ding der Unmöglichkeit. Das sollte ein Berater für Enterpriselösungen sicher verstehen, da sitzen nämlich die meisten Individualisten.
Wenn dir aber ein Feature in Oxid fehlt und du sagst das muss unbedingt rein, so bietet dier Oxid die Möglichkeit dir über die Uservoice Gehör zu verschaffen und bei genug Gleichgesinnten kommen die Vorschläge auch in den Core.

Grüße

Rafael[/QUOTE]

Hi Rafael,

danke für die Hinweise über Uservoice, werde ich mal dort versuchen.

Wegen Individualisten bei den Enterpriselösungen, also genau da habe ich schon viele Wünsche offen; die Kunden heutezutage möchten immer mehr Funktionalitäten Standard haben, statt immer eigene Code zu schreiben; Fazit “Konfigurieren statt Programmieren”. Aber naja, es ist auch eine Sache der Gewohnheit denke ich, bin einfach faul geworden und möchte nicht mehr alles selbst programmieren als vor ein paar Jahren in der Entwicklung…

VG, Ge

11

wie wäre es mit versteckten Kategorien, die eben nur für die Zuordnung von Versandkosten und -regeln etc gelten? (löst aber auch nur einen Teil des Problems, glaube ich )

12

[QUOTE=vanilla thunder;77083]wie wäre es mit versteckten Kategorien, die eben nur für die Zuordnung von Versandkosten und -regeln etc gelten? (löst aber auch nur einen Teil des Problems, glaube ich )[/QUOTE]

Hi Vanilla,

danke für die Antwort. Es ist eher ein Beispiel, um zu zeigen, was man sonst mit Kategorien noch machen könnte, falls es ein Business Key dafür gäbe. Der obiger Vorschlag ist eher ein Workaround, ich selbst habe diese Technik auch schon für mein Shop verwendet, also versteckte Kategorien mit dem “Titel” als Business Key, dabei muss ich für alles Sprachen denselben Wert pflegen, sonst funktioniert es nicht. Zum Glück habe ich nur zwei Sprachen. Nichtsdestotrotz ist es unsauber und fehleranfällig und daher der Wunsch von Business Key.

Ich kenne zu gut das Problem dass man selbst irgendein “workaround” hier und da einbaut, kurzfristig löst es ein Problem man vor den Augen sieht, langfristig machen die Workarounds das System inkonsistent und die Wartung teuer bis unmöglich, sprich “schraubt man an einer Stelle, brechen weitere 10 Stellen”, da die Architektur des Platforms (hier OXID) soweit geändert wird, so dass niemand sie kennt (also Berater gehen am Ende des Projektes, eigene Entwickler verlassen die Firma). Ich betrachte es als ein Designprinzip, was für die Skalierbarkeit des OXID sehr wichtig sein soll. Werde mal bei Uservoice eintüten und hoffe auf Gehör. :slight_smile:

Sonst noch an allen: Frohe Weihnachten :smiley:

VG, Ge