Darf man sich schon was wünschen?

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 :smiley: 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?

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.

@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 :smiley: 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? :smiley:
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 …

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

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.

Moin,

wünschen darf man sich immer etwas und Feedback gegen sowieso. Einige Punkte hat [@Moritz Naczenski](http://forum.shopware.com/profile/14574/Moritz Naczenski “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.

2 „Gefällt mir“

@brettvormkopp schrieb:

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

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.

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.

1 „Gefällt mir“

https://developer.mozilla.org/en-US/docs/Web/API/URL
Using Fetch - Web APIs | MDN

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…

1 „Gefällt mir“

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? :stuck_out_tongue:

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.

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

1 „Gefällt mir“

@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? :stuck_out_tongue:

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 :smiley:

1 „Gefällt mir“

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

1 „Gefällt mir“

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 :smiley: 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: Introduction | Vue.js

GraohQL muss ich erstmal googlen

@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 :D 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 :slight_smile:

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](http://forum.shopware.com/profile/14574/Moritz Naczenski “Moritz Naczenski”)‍

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.
1 „Gefällt mir“

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.