Eigenes Model - Zugriff auf geerbte Methoden

Hallo zusammen,

wir benötigen gerade ein neues Modul, für das eigene Datenbanktabellen und entsprechende Model-Klassen nötig sind. Diese würde ich gerne ordentlich in OXID integrieren, weshalb ich die Models die BaseModel-Klasse extenden lasse.
Leider funktioniert das ganze trotz Recherche nicht so ganz wie gewünscht.

Das Model kann mit oxNew() instanziert werden. Auf dem erzeugten Objekt rufe ich anschließend die von BaseModel geerbte public-Methode exists() auf, kann diese jedoch nicht gefunden werden (was verwundert, da der Aufruf von $this->init() im Kontruktur scheinbar keine Probleme verursacht, obwohl die ja auch geerbt wird).
Auch get_parent_class() nach oxNew() liefert NULL.

Leider kann ich kein Unterschied zwischen meinem Model und recherchierten Beispielen finden.
Gearbeitet wird mit OXID 6.3.1 PE. Die metadata.php verwendet v2.1, das Model kommt dementsprechend nicht darin vor. Da der WidgetController funktioniert, denke ich, sollte das drum herum soweit auch passen.

Nachfolgend der wesentliche Source:

DB-Tabelle

CREATE TABLE kcsconfigurator_systemarticles (
OXID             INT(11)      AUTO_INCREMENT NOT NULL,                     
ID_BASEART       CHAR(32)                    NOT NULL COLLATE utf8_general_ci,
IDS_SYSCOMPLISTS TEXT                        NOT NULL COLLATE utf8_general_ci,
IDS_DEFCOMPS     TEXT                        NOT NULL COLLATE utf8_general_ci,
SEOURL           VARCHAR(255) DEFAULT NULL       NULL COLLATE utf8_general_ci,
PRIMARY  KEY                 ( OXID )        USING BTREE,
         KEY BASEARTICLE_ID  ( ID_BASEART )  USING BTREE
) DEFAULT CHARSET  = UTF8
  COLLATE          = utf8_general_ci
  ENGINE           = InnoDB;

## Dummy Records
INSERT INTO kcsconfigurator_systemarticles ( ID_BASEART, IDS_SYSCOMPLISTS, IDS_DEFCOMPS ) VALUES
( '15537', '1,2', '1,11,40,86' ),
( '19232', '1,2', '1,11,40,86' );

Model
<ModulRoot>/Application/Model/Systemarticle.php

namespace MyVendor\ConfiguratorModule\Application\Model;

use OxidEsales\Eshop\Core\Model\BaseModel;

class Systemarticle extends BaseModel {
  protected $_sClassName = 'Systemarticle';
  
  public function __construct() {
    parent::__construct();
    $this->init('kcsconfigurator_systemarticles');
  }
}

Aufrufender Controller
<ModulRoot>/Application/Component/Widget/ArticleDetails.php

namespace MyVendor\ConfiguratorModule\Application\Component\Widget;

class ArticleDetails extends ArticleDetails_parent {
  public function __construct() {
    parent::__construct();
  }

  public static function isSystemarticle($articleId) {
    $oSysArt = oxNew(\MyVendor\ConfiguratorModule\Application\Component\Systemarticle::class);
    return $oSysArt->exists($articleId);  // ERROR
  }

Controller-Aufruf
<ShopRoot>source/Application/views/theme2022/tpl/widget/product/details.tpl

[{assign var="oDetailsProduct" value=$oView->getProduct()}]
[{assign var="sArticleID"      value=$oViewConf->getActArticleId()}]
[{if $oView->isSystemarticle($sArticleID)}]
  [{oxid_include_widget cl="kcs_configurator" _parent=$oView->getClassName() sSystemarticleID=$sArticleID}]
[{else}]
  [{include file="page/details/details.tpl" blWorkaroundInclude=true}]
[{/if}]

Ich hoffe sehr, jemand hier kann mir bei dieser Sache weiterhelfen. Bisher haben wir solche Probleme immer umgangen, indem wir einfach alles selber gemanaget haben. Ich möchte die Models künftig aber gerne ordentlich integrieren.

Vielen Dank im voraus und beste Grüße

Mir fällt auf den ersten Blick auf, dass Du in

$oSysArt = oxNew(\MyVendor\ConfiguratorModule\Application\Component\Systemarticle::class);

Component gegen Model tauschen musst

$oSysArt = oxNew(\MyVendor\ConfiguratorModule\Application\Model\Systemarticle::class);

2 Likes

Auweia, peinlich peinlich… :see_no_evil:
Vielen Dank für den Hinweis, läuft jetzt einwandfrei.

Das kommt wohl davon, wenn Unachtsamkeit bei Nutzung der Autovervollständigung auf Snippets trifft, die in der IDE nicht excluded sind und falsche Namespaces enthalten.

Eine Frage zum Thema Models hätte ich zum Abschluss aber noch :slight_smile:
Macht es (z.B. aus performancegründen) Sinn, solche Properties wie $_sOXID, $_aFieldNames usw auch hardgecodet zu hinterlegen, wenn möglich? Oder ist das nur für Abweichungen vom Standard sinnvoll?

Gerne :slight_smile:

Dies kommt auf den Einzelfall drauf an.

Erfahrungsgemäß gibt es bei OXID eShops sehr wenige allgemeine Module. Daher unterscheide ich nach Standard Modullösung (in jedem Shop lauffähig z.B. PayPal Modul) und Kundenspezifische Modullösung.

Die Kundenspezifische Modullösung stellt meist die Regel dar und dies bedeutet, dieses Modul muss nur in dem Shop funktionieren wo Sie entwickelt wurde.

Standard Modullösungen sind auch deutlich teurer in der Entwicklung und Wartung als Kundenspezifische Modullösungen. Würde dort mit dem Faktor 10 also ca. 10x aufwendiger rechnen.

Da stellt die Kundenspezifische Modullösung für den einzelnen Händler die preiswertere Alternative dar. Wenn man dies berücksichtig, dann ist es legitim hardcodet Properties zu hinterlegen (für den Einsatz-Shop).

Der entscheidende Punkt dort sollte sein, dass diese Dinge für den Händler*in dokumentiert werden. Das ersichtlich ist, dass die Modullösung nur für diesen speziellen Shop und Anwendungsfall + die Abhängigkeiten zu Artikel xy und Kategorie xy entwickelt wurde.

Okay, verstehe.
Die Properties mit festem Wert zu initialisieren bringt im allgemeinen demnach also auch keine nennenswerte Vorteile. Hatte im Sinn, das es evtl. Sinn machen könnte z.B. die Spaltennamen direkt unter $_aFieldNames zu hinterlegen, damit diese nicht extra aus dem Information-Schema gefetched werden müssen. Ist ja nur minimaler Mehraufwand. Wobei das ja sowieso gecached wird, von dem her wäre der Vorteil vermutlich sowieso nur marginal.

1 Like

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.