6 Antworten zu diesem Thema

[MarioK]

Hallo liebe SmartStore Gemeinde,

wie würde ich am besten ein "Produkt Konfigurator" Plugin realisieren?

 

Was ich bisher umgesetzt habe:

• Basic Plugin mit Konfiguration
• Adminmenü um neuen Menüeintrag erweitert.
  Der dient zur Konfiguration der Stammdaten. Diese werden über einen anderen Webservice zur Verfügung gestellt. (Read/Write)
• Kategorie-Menü (im Shop) bei Installation des Plugins um Menüpunkt "Konfigurator" erweitert.
  Zusätzlich wurde bei der Installation des Plugins ein neues Produkt angelegt, welches als Vorlage zum "konfigurieren" dienen soll.
• Beim Klick auf "Konfigurator" im Kategorie-Menü wird nun mit dem "Vorlage-Produkt" in die ProductDetail View navigiert.

Nun anstehende Anforderungen:

• Es müssen nun x Attribute konfiguriert werden. Diese sind logisch voneinander abhängig.
• Zu beginn sollen alle Attribute bis auf das erste(Nr.1) (Datei upload) deaktiviert sein.
• Nach dem Hochladen der Datei soll diese an einen (bestehenden)Webservice zur Verarbeitung geschickt werden.
  Ist das Ergebnis OK, wird das nächste Attribut (Nr.2) aktiviert.
• Nach der Auswahl von (Nr.2) dessen Content auch vom Webservice bezogen wurde, wird der zur Auswahl passende Content (Liste) durch Attribut (Nr.3) zur Verfügung gestellt.
• u.s.w
• Es soll nun auch möglich sein, das z.B. nach Auswahl von (Nr.3) sich der der Produktpreis ändert.

 

Nun stelle ich mir die Frage, ob ich bei diesen Anforderungen mit der Entwicklung eines Widgets oder eines oder mehrere Filter mein Ziel erreichen kann. Ich würde natürlich so viel "Standard-Shop-Funktionalität" verwenden wie möglich ist.

 

Welche Entwicklungsrichtung bietet sich hier am besten an? Widget, Filter oder beides? Gibt es für so einen Fall ein "Best Practice" ?

 

Evtl. ist das was ich bis jetzt umgesetzt habe auch gar nicht so sinnvoll und ich sollte eurer Meinung nach ganz anders verfahren.

 

Ich bin für ALLE Vorschläge, Ideen und Hilfe echt dankbar.

[Marcus Gesing]

Klingt im wesentlichen (bis auf die Entgegennahme des Datei-Uploads) nach Client-Scripting, sprich Ajax und jQuery. Ich würde wahrscheinlich damit

beginnen mir eine jQuery-Komponente zu schreiben und diese per action filter und IWidgetProvider in die Produkt-Detail-Seite zu injizieren.

Siehe als Beispiel PayPalPlusWidgetZoneFilter.

 

Was ist denn Sinn und Zweck des "Vorlage-Produkt"?

[MarioK]

Vielen Dank für die schnelle Antwort.

Das "Vorlage-Produkt" erzeuge ich bei der Installation des Plugins, damit der Shop-Betreiber es nicht anlegen muss.

Ich wollte nun jedesmal bei Navigation über den Konfigurator-Link mit genau diesem Produkt in den Konfigurator/ProductDetail gehen.

Das würde dann ja auch bedeuten, das ich alle benötigten Attribute mit dem Produkt bei der Installation des Plugins anlege, oder?

Kann ja auch sein, daß ich nicht vestehe wie die JQuery-Komponente arbeiten soll.

Ich würde mich über ein paar Details zu der Inject-Idee freuen.

 

Hier noch ein Nachtrag in Quellcode Form der, so glaube ich ein wenig mehr Aufschluss zum Thema "Vorlage-Produkt" gibt:

public ActionResult Configurator()
    {
      // Eine evtl. vorhandene ProduktUrl für das Produkt ermitteln 
      string productUrl = settingService.GetSettingByKey("Plugins.XXX.YYY.GlobalSettings.ProductUrl", defaultValue: string.Empty);

      // Eine evtl. vorhandene ProduktId für das Produkt ermitteln 
      int productId = settingService.GetSettingByKey("Plugins.XXX.YYY.GlobalSettings.ProductId", defaultValue: -1);

      bool productNotExistOrDeleted = false;

      // Prüfen ob das Default-Produkt noch existiert.
      if (productId != -1)
      {
        var product = productService.GetProductById(productId);

        productNotExistOrDeleted = product == null || product.Deleted;
      }

      // Falls entweder noch kein Default-Produkt konfiguriert wurde oder das konfigurierte Produkt
      // anhand seiner ProduktId nicht mehr auffindbar ist.
      if (productId == -1 || productNotExistOrDeleted)
      {
        var product = new Product()
        {
          Name = this.localizationService.GetResource("XXX.YYY.ZZZ"),
          Price = (decimal)0.0,
          CreatedOnUtc = DateTime.Now,
          UpdatedOnUtc = DateTime.Now,
          AvailableEndDateTimeUtc = DateTime.Now,
          AvailableStartDateTimeUtc = DateTime.Now,
          SpecialPriceEndDateTimeUtc = DateTime.Now,
          SpecialPriceStartDateTimeUtc = DateTime.Now,
          VisibleIndividually = true,
          Published = true,
          ProductType = ProductType.SimpleProduct
        };

        // Das Produkt in die Datenbank speichern
        productService.InsertProduct(product);

        // Das Produkt durch den UrlRecordService speichern, 
        // damit eine Produkt-Url erzeugt und mit dem Produkt verknüpft wird
        urlRecordService.SaveSlug<Product>(product, x => x.Name);
        productUrl = "~/" + product.GetSeName();

        // Die Produkt-Url in den globalen Einstellungen speichern
        settingService.SetSetting("Plugins.XXX.YYY.GlobalSettings.ProductUrl", productUrl);

        // Die Produkt-Id in den globalen Einstellungen speichern
        settingService.SetSetting("Plugins.XXX.YYY.GlobalSettings.ProductId", product.Id);
      }

      // Die Produktdetails anhand der Produkt-Url aufrufen
      return Redirect(productUrl);
    }

[Marcus Gesing]

Client-Scripting (z.B. in Form einer jQuery-Komponente) ist notwendig, um auf die Konfigurationsereignisse zu reagieren, insb. dieses Schritt für Schritt aktivieren der einzelnen Attribute.

 

"Das würde dann ja auch bedeuten, das ich alle benötigten Attribute mit dem Produkt bei der Installation des Plugins anlege, oder?"

Ja, das klingt sinnvoll, aber was ist, wenn sich die Attribute oder deren Werte beim Webservice ändern?

[MarioK]

Ich unterscheide hier Attribute von Attributinhalten. In meiner Vision werden dann die Attribute zur Laufzeit (Installation) erzeugt und dem Produkt hinzugefügt (Damit diese dann auch in den ProductDetails auftauchen).  Die Inhalte der Attribut(Felder) werden ausschließlich über den Webservice bezogen. So sollten sich Änderungen sofort im Shop auswirken.

 

Mich würde noch einmal interessieren, ob das Herangehen in der geposteten Methode "Configurator" totaler blödsinn ist und man das automatische Erzeugen von Produkten besser anders durchführt?

 

Mir kommt der von mir eingeschlagene Weg um auf die Produktdetails zu navigieren ein wenig unschön vor. Wie sollte man es evtl. besser machen?

[Marcus Gesing]

Das mit dem Ablegen des Vorlageproduktes ist schon ok so. AvailableEndDateTimeUtc, AvailableStartDateTimeUtc, SpecialPriceEndDateTimeUtc und SpecialPriceStartDateTimeUtc sollten NULL sein. CreatedOnUtc und UpdatedOnUtc immer in UTC also DateTime.UtcNow. ProductType: ProductType.SimpleProduct. Slug:

var seName = product.ValidateSeName(null, product.Name, true, urlRecordService, seoSettings);
urlRecordService.SaveSlug(product, seName, 0);

Den Redirect macht man am elegantesten so:

return RedirectToRoute("Product", new { SeName = product.GetSeName(), area = "" });

ProductUrl oder SeName würde ich nicht separat speichern, da die sich ändern können, d.h. nur die Product.Id als Setting speichern und den Rest bei Bedarf nachladen.

[MarioK]

Vielen herzlichen Dank !!!

Nun habe ich genug Input um voran zu kommen.

Echt super. :-)