brettvormkopp

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?

Moritz Naczenski

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.

Shopwareianer

@brettvormkopp schrieb:

• 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 ?

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:

  componentDidMount() {
    var p = {
      active: 1,
      name: "test"
    };

    var result = "?";
    for (var key in p) {
      if (p.hasOwnProperty(key)) {
        var filter = "filter[product." + p[key] + "]=" + key + "&";
        result += filter;
      }
    }

    console.log(result);
  }

 So bum ... Letztendlich liegt es an dir wie du die Daten überträgst, nicht an der API ...

brettvormkopp

Wie willst du denn sonst Parameter übertragen? Und was ist so schlimm daran, die Parameter zu übertragen? 
 

so:

mydata = {api:"product",filter:{product.name:"desc"}}

$.ajax({
  dataType: "json",
  data: mydata, 
  url: "https://INSTANZ.pg.shopware.com/storefront-api/",
  headers: {"x-sw-access-key":"1234567890"},
  success: function(result){
  ...
  }
});

 warum? Übersicht.

Jens_K

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.

Shopwareianer

@brettvormkopp schrieb:

Wie willst du denn sonst Parameter übertragen? Und was ist so schlimm daran, die Parameter zu übertragen? 
 

so:

mydata = {api:"product",filter:{product.name:"desc"}}

$.ajax({
  dataType: "json",
  data: mydata, 
  url: "<a href="https://INSTANZ.pg.shopware.com/storefront-api/">https://INSTANZ.pg.shopware.com/storefront-api/"</a>,
  headers: {"x-sw-access-key":"1234567890"},
  success: function(result){
  ...
  }
});

 warum? Übersicht.

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. 

var p = {
   active: 1,
   name: "test"
};

Dat sind dann oben deine Parameter als Objekt. Meine Class sieht dann so aus:

import axios from "axios";

export default class Api {
  constructor() {
    this.host = process.env.REACT_APP_API_URL;
    this.apiKey = process.env.REACT_APP_API_KEY;
  }
  async handleRequest(selector) {
    return await axios
      .get(this.host + selector.url, {
        method: selector.method,
        headers: {
          "x-sw-access-key": this.apiKey,
          "Content-Type": "application/json"
        }
      })
      .then(response => {
        return response.data;
      })
      .catch(error => {
        console.error(error);
      });
  }

  getCategories() {
    return this.handleRequest({
      url: "category",
      method: "GET"
    });
  }
  getProducts(params) {
    return this.handleRequest({
      url: "product" + params,
      method: "GET"
    });
  }
  ....
}

Und die Kategorien rufste dann auf mit this.getCategories(); 
Ist aber alles nicht optimal, da es nur hop hop zum testen war.

wontfix

https://developer.mozilla.org/en-US/docs/Web/API/URL
https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch

let url = new URL("https://my.shop/api/articles";
url.searchParams.set("limit", 10);
url.searchParams.set("offset", 32);

fetch(url)
  .then(resp => resp.json())
  .then(data => console.log(JSON.stringify(data)))
;

ps. braucht wohl noch auth...

brettvormkopp

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.

Shopwareianer

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.

brettvormkopp

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

FloC3

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..)

brettvormkopp

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.

{data:[{ 
  freitextfelder: {
    "meta description": "jjojo",
    "cmsHeadline": " so siehts aus",
    ....
  }
}]

Dann soll jeder der das braucht sich diese Freitextfelder individuell als Baustein dazubuchen und die API bleibt rein.

Shopwareianer

@brettvormkopp schrieb:

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

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

Shopwareianer

@brettvormkopp schrieb:

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.

{data:[{ 
  freitextfelder: {
    "meta description": "jjojo",
    "cmsHeadline": " so siehts aus",
    ....
  }
}]

Dann soll jeder der das braucht sich diese Freitextfelder individuell als Baustein dazubuchen und die API bleibt rein.

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. 

brettvormkopp

Die Frage ist: Was findest du daran "schon wieder kompliziert" und wie würdest du es denn "leicht" machen?

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

Shopwareianer

@brettvormkopp schrieb:

Die Frage ist: Was findest du daran "schon wieder kompliziert" und wie würdest du es denn "leicht" machen?

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.

brettvormkopp

Wäre schön wenn es sowas wie "Expertenmodus" gibt wo die ID's angezeigt werden für Kataloge, Kategorien und Produkte. THX.

brettvormkopp

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‍

brettvormkopp

Mhh,mal kurz ein Report vom Backend: 

• Habe einen Codeschnipsel, nur text und breaks, in die Artikelbeschreibung gemacht. Nach dem speichern waren alle anderen Testartikel weg. Ärgerlich. Beim löschen des Codeschnipsels und speichern ohne Inhalt, sagt er es ist ein Fehler aufgetreten. Also Textfeld leer machen und irgendein nonsens reinschreiben. Dann wieder öffnen, nonsense löschen und speichern.
• Ausserdem habe ich eine Kategorie angelegt. Diese wurde aber nicht angezeigt, also habe ich nochmal eine angelegt. Und plötzlich habe ich zwei Kategorien in einem Katalog mit dem gleichen Namen. Gleiche Kategorie-Namen in einem Katalog sollte nicht sein.
• Die Notification der geglückten oder missglückten Arbeitsschritte sollte auch nicht über dem Produktlisting erscheinen -> erstes Produkt. Ausserdem sollte "bearbeiten" nicht versteckt hinter einem Klick sein. Wenn ich in Produkte gehe IST das erste was ich will.... trommelwirbel... bearbeiten.
• 19% Steuer sollte immer voreingestellt sein. Oder irgendwo einstellbar sein. Ebenso einen default-Hersteller.
• Achso, was istn eigentlich mit Responsive Textareas? Mobil lässt sich das so nicht nutzen.
• Artikel-Preview für Backendnutzer.(EDIT:fällt mir gerade ein, dass dazu ja auch das Frontend irgendwie stehen muss)
• Bilder Upload danach fragen ob Exif gerippt werden soll oder unterbunden werden soll.
• Bildupload-CDN selbst festlegen, z.B. kein Amazon AWS.

brettvormkopp

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.

Shopwareianer

@brettvormkopp‍ Bzgl. deiner Abfrage auf Basis eines Objekts. Habe da meine Class noch etwas überarbeitet. Ist jetzt aber nur für Filter.

export default class Api {
  constructor() {
    this.host = process.env.REACT_APP_API_URL;
    this.apiKey = process.env.REACT_APP_API_KEY;
  }

  async handleRequest(selector) {
    return fetch(this.host + selector.url, {
      method: selector.method,
      headers: {
        "x-sw-access-key": this.apiKey,
        "Content-Type": "application/json"
      }
    })
      .then(response => response.json())
      .then(json => json)
      .catch(error => console.error(error));
  }

  handleFilters(entityName, params) {
    const entity = entityName.replace("/", "");
    const filter = [];

    for (const key in params) {
      if (params.hasOwnProperty(key)) {
        const url = `filter[${entity}.${key}]=${params[key]}`;
        filter.push(url);
      }
    }

    const result = "?" + filter.join("&");
    return result;
  }

  getResult(entityName, params) {
    let url = "";
    if (params !== undefined) {
      url = `${entityName}${this.handleFilters(entityName, params)}`;
    } else {
      url = `${entityName}`;
    }
    return this.handleRequest({
      url,
      method: "GET"
    });
  }
}

Den Request machste dann bspw. mit:

await this.shop.getResult("product/", {
    categoryTree: this.props.match.params.categoryId,
    weitererFilter: value,
});

 

brettvormkopp

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.

 

Shopwareianer

@brettvormkopp schrieb:

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

brettvormkopp

Ein weiterer Wünsch:

• die JSON Rückgabe sollte man ggf im Backend steuern können, so wie im aktuellen Shopware die Rechtevergabe der User, stelle ich mir eine Checkbox-Liste vor mit Daten die das Frontend ausgeben soll.

Shopwareianer

@brettvormkopp schrieb:

Ein weiterer Wünsch:

• die JSON Rückgabe sollte man ggf im Backend steuern können, so wie im aktuellen Shopware die Rechtevergabe der User, stelle ich mir eine Checkbox-Liste vor mit Daten die das Frontend ausgeben soll.

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

langnickel

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.

brettvormkopp

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.

brettvormkopp

Achso, und ich habe generell die Frage wie es mit Playground weitergeht? Bin schon drauf und dran eine eigene API zu machen... #nohate

Jens_K

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.

brettvormkopp

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?

brettvormkopp

Ich habe auch einen weiteren Wunsch/Vorschlag:

• Description Long nicht mit einem p-tag wrappen.
• ml/kg/stk irgendwo einstellen können und den Grundpreis berechnen lassen ( oder ist der Grundpreis irgendwo versteckt? )

Danke und Gruss