
Also das Teil schnurrt ja wie kätzchen. Top, Danke SW! Da werden sich bestimmt 50% meiner Kunden freuen über die neue Technik. Ein paar Wünsche und Fragen:
- Medien Unabhängig von Artikeln hochladen und Gruppieren, z.B. für EKW's
- Medien in verschiedenen Grössen
- Produkte, Kataloge und Kategorien mit "Freitextfelder" z.B. für Kategorietexte, meta description etc.
- Produkte Eigenschaften/Tags ?
- statt /storefront-api/?limit=10&offset=23 sowas wie /storefront-api/ und die details dazu als objektkörper {api: "product", limit: 10, offset: 23} kein plan wie das heisst, bin kein Programmierer :-D es muss aber so sein, dass ich später https://meineinstanz.pg.shopware.com "forwarden?" kann auf https://meinedomainSamedomain.de , ist das QSA,L ?
- gibts einen offset für limit?
Comments
Freitextfelder und auch weitere Produktinformationen, wie bspw. Eigenschaften sind schon auf der Agenda. Da wird es regelmäßig updates geben. Auch die Medienverwaltung gibt es ja schon, da müsstest du auch separat Medien hochladen können. Da arbeiten die Kollegen aktuell auch noch dran.
Wie willst du denn sonst Parameter übertragen? Und was ist so schlimm daran, die Parameter zu übertragen?
Letztendlich kannst du die natürlich auch als Objekt weiter geben .... Kommt halt darauf an, wie du es programmierst ...
Simples dirty Beispiel zu Testzwecken:
So bum ... Letztendlich liegt es an dir wie du die Daten überträgst, nicht an der API ...
so:
warum? Übersicht.
Moin,
wünschen darf man sich immer etwas und Feedback gegen sowieso. Einige Punkte hat @Moritz Naczenski ja schon kommentiert. Einen offset gibt es über die API bewusst nicht. Stattdessen gibt es den Parameter "page". Wenn man also bisher "offset: 50, limit: 50" genutz hat, wäre es nun "limit:50 page:2"
Zurzeit sind folgende Werte für "limit" möglich: 1, 5, 10, 25, 50, 75, 100, 500
Die Parameter im request body zu setzen ist keine schlechte Idee, funktioniert aber leider bei allen GET Routen nicht, da es dort keinen request body gibt. Das ganze ist also technisch begründet.
Ja - Aber das meinte ich doch. Es liegt doch an dir, wie du es programmierst.
Bei meinen obigen dirty Beispiel übergibst du die Parameter ja praktisch direkt so.
Dat sind dann oben deine Parameter als Objekt. Meine Class sieht dann so aus:
Und die Kategorien rufste dann auf mit this.getCategories();
Ist aber alles nicht optimal, da es nur hop hop zum testen war.
https://developer.mozilla.org/en-US/docs/Web/API/URL
https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch
ps. braucht wohl noch auth...
Für die Freitextfelder ist mir noch was eingefallen: jeder selbst angelegtes Freitextfeld sollte eine Instanz-Kennung haben und jeder Freitextfeld eines Plugins oder externen Anbieters sollte die Programmiererkennung/Pluginkennung haben. Beispiel warum: ich lege ein FTF an und nenne es MHD. Dann hole ich mir ein Plugin was auch MHD heisst. Das Plugin meint Mindesthaltbarkeitsdatum, während ich Mittelhochdeutsch meine. Oder auch mies: ich belege meine attr1 und ein Plugin überschreibt attr1 mit eigenen Inhalten.
Das macht man ja bereits jetzt so - bzw. sollte es jeder Entwickler so machen bei Shopware. Denn auch dafür gibt's ja bspw. die Anbieterkennzeichnung.
Wenn ich also in einem neuen Plugin ein neues Freitextfeld anlege, dann würde ich es aktuell eben nennen: vendorName_attribut_iwas
Um genau eben das obige zu vermeiden.
Kann man aus dem Backend/Admin Bereich dieses Gravatar bitte wegmachen?
Habe mir dieses Vue.js mal angerschaut. So wie es aussieht, ist damit ja auch das Backend gebaut. Ist Vue.js jetzt die Zukunft? Mein erster Eindruck ist nämlich: warum schon wieder kompliziert? :-P
Dann wünsche ich mir auch was: Dezimale Mengen bei Artikeln, Artikelbestellungen nach frei eingebbaren Längen und Breiten mit anschließender Quadratmeterpreisberechnung und das ganze bitte auch noch mit Preisstaffeln (Preis ab 5qm, Preis ab 10qm..)
Für das Storefront API: Kann man in /category ein Object "items" hinterlegen, welche die id's aller darin befindlichen Artikel hat? Oder anders herum: Kann ich beim Endpunkt /product ein Katagorie-Object hinzufügen welches alle Kategorie-Id's hat in dem sich der Artikel befindet? Irgendetwas zum filternnach Kategorie brauch ich. Weil mitliefern tut er ja nur catalogID :-/
Ausserdem laut gedacht: kein meta description, hidetop, cmsHeadline im Result-JSON, lieber mit Freitextfeldern als Object gekapselt.
Dann soll jeder der das braucht sich diese Freitextfelder individuell als Baustein dazubuchen und die API bleibt rein.
Kompliziert würde ich nicht sagen: Denn Vue.js ist 10x simpler aufgebaut wie bspw. ExtJs. Aber natürlich benötigt man für ein User Interface auch ein entsprechendes JS Framework. Aber ja, die Administration ist auf Vue.js aufgebaut.
Und verglichen mit den aktuellen anderen Frameworks wie Angular, React & Co. ist Vue.js schon relativ simpel. Man muss eben mit der Zeit gehen und natürlich muss man ggf. auch neue Dinge lernen :)
Die Frage ist: Was findest du daran "schon wieder kompliziert" und wie würdest du es denn "leicht" machen? Ich denke mit Vue.js ist Shopware einen sehr guten Weg eingeschlagen, da es eben vergleichweise recht leicht zu erlernen ist und auf der anderen Seite auch optimal für ein User Interface ist wie eine solche Administration. Und es ist vor allem flexibel. Verglichen mit ExtJS .... Da liegen ja Welten zwischen
Bin mir nicht ganz sicher ob ich das richtig verstehe, aber dass hatte ich letztens schon angepint.
Eine Lösung ist hier aktuell bspw. GraphQL - Du bekommst also nicht das komplette Objekt mit allen Properties zurück, sondern wirklich nur die welche du in dein Query packst.
Also bspw. brauchst du im Listing nur Artikelname, Preis & Bild. Die API gibt dir aber alles vom Artikel zurück. Freitextfelder, Beschreibung und was weiß ich noch alles. Also 90% was du bspw. gar nicht brauchst.
Mit GraphQL hast du hier die Möglichkeit zu sagen: Gib mir nur den Namen, Preis und das Image. Du bekommst also dann von der API nur das zurück, was du auch tatsächlich benötigst und nicht das komplette Objekt mit allen zip und zap.
Habe eben gerade das richtige Tutorial gefunden. Ein Blick auf die Entwicklerseite bewirkt wunder
Hatte vorher nur so payvideos gesehen wo der Compiler angeschmissen wird. Das fand ich nicht passend für das was ich suchte. Für alle Interessenten: https://vuejs.org/v2/guide/
GraohQL muss ich erstmal googlen
Jau - Bei Vue wie aber auch bei anderen Frameworks gibt es noch viele weitere Dinge.
Wie bspw. Vuex für den store/state management, Vue-Router usw. usw.
Dazu kommt dann natürlich noch, dass man Javascript drauf haben muss, ES6, ggf. Typescript, Babel/Webpack usw.
Nuxt.js für's Frontend ist auch interessant ...
Ist auf jeden Fall einiges zum lernen. Aber du hast ja noch Zeit
Ich kann hier auf jeden Fall den Vue.js 2 Complete Kurs auf Udemy empfehlen.
Wäre schön wenn es sowas wie "Expertenmodus" gibt wo die ID's angezeigt werden für Kataloge, Kategorien und Produkte. THX.
Wenn ich nicht ganz falsch liege, braucht man für einen schönen Ladebalken "Content-length" im Response-Header. Kann SW den bitte mitschicken? Danke @Jens_K @Moritz Naczenski
Mhh,mal kurz ein Report vom Backend:
Und heute sind wieder alle Artikel im Backend, bis auf einer vorhanden... woran liegt das? Habe ausserdem gecheckt, dass wenn man in der Übersicht den Herstellernamen ändert und die positive Notification kommt, dass es dann noch nicht abegschlossen ist, irgendwas "rödelt" noch und man sollte die Seite nicht verlassen bis der Ladekreis über der Mouse weg ist.
@brettvormkopp Bzgl. deiner Abfrage auf Basis eines Objekts. Habe da meine Class noch etwas überarbeitet. Ist jetzt aber nur für Filter.
Den Request machste dann bspw. mit:
Eine Frage, warum nutzt du die Fetch Api. Welchen Mehrwert ausser der offensichtlich vereinfachten Syntax, bietet es gegenüber normalen xhr? Ich steig nicht dahinter.
https://stackoverflow.com/questions/35549547/what-is-the-difference-between-the-fetch-api-and-xmlhttprequest
https://developers.google.com/web/updates/2015/03/introduction-to-fetch
Allerdings könnte man auch auf axios setzen statt fetch. Axios bietet ein paar weitere Vorteile -> https://medium.com/@sahilkkrazy/fetch-vs-axios-http-request-c9afa43f804e
Aber da es derzeit ausreicht mit fetch kann ich eine externe library sparen
Ich werde die Class ja sowieso noch überarbeiten, damit man eben nicht nur Filter verwenden kann usw.
Nur war ja oben deine Frage, wie man praktisch die Parameter als Objekt übergeben kann und dann eben das Ergebnis zurück bekommt. Ist auch nur ein Denkanstoß die Class
Ein weiterer Wünsch:
Das hatte ich ja berits angemerkt - Eine Lösung wäre aktuell GraphQL welch eben nur die Ergebnisse zurück liefert, welche man benötigt und nicht die kompletten Objekte. Dazu hier die letze Antwort: https://forum.shopware.com/discussion/57225/shopware-playground-kategorie-namen#latest
GraphQL wäre in der Tat eine gute Entscheidung. Die Resolver sind extrem flexibel und mehr oder weniger unabhängig vom tatsächlichen Backend. Un dass vue genommen wird finde ich persönlich super, da flexibel, mehr oder weniger unkompliziert und modular.
Es wäre gut wenn der Playground sowas wie einen liveticker/status hat. Die Jungs vom Hostinganbieter Ubernaut tickern immer über twitter wenn sie irgendwas machen und das system nicht erreichbar ist. Das würde sicher eine Menge "Ärger" ersparen wenn die Systeme streiken und die Admins bei sich suchen, es aber ggf bei der Api liegt.
Achso, und ich habe generell die Frage wie es mit Playground weitergeht? Bin schon drauf und dran eine eigene API zu machen... #nohate
Moin brettvormkopp! Intern haben wir ein Monitoring und behalten das ganze im Blick. Wenn etwas wirklich kaputt ist, bemerken wir das relativ schnell. Da es sich aber um kein Produktivsystem handelt, kann es in vorkommen, dass es 1-2 Tage dauert bis ein Fehler behoben ist. Daher ist ein öffentlicher Live-Ticker/Statusanzeige o.ä. erstmal nicht geplant.
Wie es genau mit Playground weitergeht kann ich dir nicht sagen aber der ein System zu haben auf dem man mal schnell etwas ausprobieren kann, ist wie ich finde eine coole Sache.
Hi @Jens_K ja es ist ziemlich cool, gar keine Frage und ich hoffe dass das Shopware Playground System stabil weiter entwickelt wird. Bei dem geringen Frage-Aufkommen hier im Forum frage ich mich, ob es zu wenig Leute nutzen?
Ich habe auch einen weiteren Wunsch/Vorschlag:
Danke und Gruss