Habe in der oxartextends ein neues Feld eingebaut, das aber nicht im Template ankommt?
Gibt es dafür kein “lazy loading”?
Habe in der oxartextends ein neues Feld eingebaut, das aber nicht im Template ankommt?
Gibt es dafür kein “lazy loading”?
[QUOTE=Marco Steinhaeuser;80634]Moin,
hat das ggf. hiermit zu tun?
https://bugs.oxid-esales.com/view.php?id=3463
Gruß[/QUOTE]
Nein, das sind Großbuchstaben…
Geil, oder?
hast Du es schon mit der 457er versucht? Sollte laut changelog geflickt sein.
Ich habe in der autoload-Funktion noch einen eigenen Ordner aufgenommen und dort eine oxbase.php reinkopiert in der ich den Teil mit dem lazydings mit dem aus der 45er ersetzt haben. Das sollte hoffentlich halten bis das wieder läuft.
tschüß, Stefan
Dieses Thema würde mich auch interessieren.
Falls ich das “lazy loading” richtig interpretiere (ich dneke hier an so etwas wie $oArticle->oxarticle__customfield->value ), dann bin ich zu dieser Erkenntnis gekommen:
Die (custom) Felder aus der oxartextends gibts nicht in der View für oxArticle, deswegen funktioniert kein eingebautes “lazy loading”. Würden die Felder in oxarticles sein, dann wäre es kein Problem.
Die Abfrage der Longdescription wird anhand des Feldnamen rausgefiltert und an die View osv_oxartextends geschickt.
ich bastle momentan auch an einem Modul, um die eigenen Felder aus der oxartextends möglichst einfach rauszuholen. Hier z.b. meine Funktion zum rausholen der Eintrgäge aus oxartextends:
public function getOxArtExtended($sField = null )
{
if($this->$sField === null) {
$this->$sField = new oxField();
$sOxid = $sOxid === null ? $this->getId() : $sOxid;
$sViewName = getViewName( 'oxartextends', $this->getLanguage() );
$sDbValue = oxDb::getDb()->getOne( "SELECT ($sField) FROM {$sViewName} where oxid = ?", array( $sOxid ) );
if ( $sDbValue !== false ) {
$this->$sField->setValue( $sDbValue, oxField::T_RAW );
} elseif ( $this->oxarticles__oxparentid->value ) {
$this->$sField->setValue( $this->getParentArticle()->getOxArtExtends($sField)->getRawValue(), oxField::T_RAW );
}
}
return $this->$sField;
}
ist aber noch in der Entwicklung und muss vorsichtig getestet werden
viele Grüße
[QUOTE=stefan2;80643]hast Du es schon mit der 457er versucht? Sollte laut changelog geflickt sein.[/QUOTE]Ja, habe gerade auf die 4.5.7 aktualisiert, hat sich nichts geändert…
Da geht lazyloading leider nicht:
http://www.oxid-esales.com/forum/showthread.php?t=3927&highlight=oxartextends
Hi,
hab grad mal mit den Entwicklern geschnattert, die schauen sich das mal an:
https://bugs.oxid-esales.com/view.php?id=3541
Gruß
Hallo,
der Link im Bugtracker, der als mögliche Lösung angegeben ist, ist wirklich keine Lösung
Beim Aufruf von “[B]$oArticle->oxartextends__abc[/B]” wird “oxartextends__abc” im $sName gespeichert und von oxArticle an oxBase weitergegeben.
Und da liegt auch der Hund begraben.
Und zwar ein mal in der Zeile 236:
if ( $this->_blUseLazyLoading && stripos( $sName, $this->_sCoreTable . "__" )
“[B]$this->_sCoreTable[/B]” ist im Fall von oxarticle die Tabelle "[B]oxarticles[/B]"
deswegen fliegen wir mit unserem “[B]oxartextends[/B]” vorbei und unser Feld wird nicht geladen.
mögliche Lösung hierfür wäre z.B: nicht nach Core Table im $sName zu suchen, sondern die entsprechende Tabelle aus $sName rauszuholen.
Da ich aber nicht sicher bin, ob dadurch irgendwelche Shopfunktionen beeinträchtigt werden, habe ich an dieser Stelle (direkt in der Zeile vor der IF-Klausel) erst nur eine Abfrage nach oxartextends eingebaut:
if( stripos( $sName, "oxartextends__" ) === 0 ) {
$this->_sCoreTable = "oxartextends";
}
Die nächste Problemzone ist in der Zeile 245:
$sViewName = $this->getViewName();
ich kann gerade nicht in einem zusammenhängenden Satz ausdrücken, was und warum hier nicht stimmt, aber wenn man der Funktion mitteilt, für welches Feld die View gebraucht wird, dann bekommen wir auch die richtige View oxv_oxartextends und nicht die oxv_oxarticles:
$sViewName = $this->getViewName($this->_sCoreTbl);
Und schon müsste es funktionieren.
Der Ansatz könnte natürlich auch anders umgesetzt werden: z.B. die getViewName() anzupassen.
Ich hoffe, ich habe hier keinen totalen Blödsinn geschrieben
einen entspannten Sonntag wünsche ich euch
Hi,
kann es sein, das die Felder mit Deiner Methode erst nach füllen des caches zur Verfügung stehen. Also cache leeren abdrücken, longdesc leer, noch mal abdrücken longdesc da. Bei Dir auch?
Und mal davon abgesehen, ob das überhaupt so gültig ist, hast Du beim setzen des Tabellennamens eine Einbahnstraße gebaut. Das erste Vorkommen von oxartextends setzt den Tabellennamen aber zurück gehts dann nicht mehr.
if( $_sTableName = strstr($sName, '__', true) ) {
$this->_sCoreTable = $_sTableName;
}
passt besser.
tschüss, Stefan
[QUOTE=stefan2;80808]Hi,
kann es sein, das die Felder mit Deiner Methode erst nach füllen des caches zur Verfügung stehen. Also cache leeren abdrücken, longdesc leer, noch mal abdrücken longdesc da. Bei Dir auch?
Und mal davon abgesehen, ob das überhaupt so gültig ist, hast Du beim setzen des Tabellennamens eine Einbahnstraße gebaut. Das erste Vorkommen von oxartextends setzt den Tabellennamen aber zurück gehts dann nicht mehr.
if( $_sTableName = strstr($sName, '__', true) ) {
$this->_sCoreTable = $_sTableName;
}
passt besser.
tschüss, Stefan[/QUOTE]
Die Lösung gefällt mir insgesamt nicht: ich will nicht wissen müssen, ob das in oxartextends oder in oxarticles ist, weil mich die interne Organisation der Artikeldaten nicht interessiert…
Die müssen daher m.E. wie die longdesc nach oxarticles gemapped werden…
Hallo avenger,
Die müssen daher m.E. wie die longdesc nach oxarticles gemapped werden…
Vollkommen richtig. Du siehst aber ja in der oxarticle.php welchen Aufriss für die Tags und den langen Text gemacht wird. Der Bereich um die magische __get Methode sieht mir schon als die richtige Stelle dafür aus.
Du kannst das mapping, ohne den lazycache, ja auch selbst reinbescheissen, entweder als smarty-Funktion oder z.B. als Modul in der oxarticles.php. Die Methode getArticleLongDesc bietet sich an weil die immer getriggert wird.
$oArtExt = oxNew('oxI18n');
$oArtExt->init('oxartextends');
$oArtExt->setLanguage((int) $this->getLanguage());
$oArtExt->load($this->getId());
$_aSkipFields = array( 'oxid', 'oxlongdesc', 'oxtags');
foreach( array_keys($oArtExt->_aFieldNames) as $sFieldName ) {
if( in_array($sFieldName, $_aSkipFields) ) {
continue;
}
$_sArtExtFieldName = 'oxartextends__' . $sFieldName;
$_sArtFieldName = 'oxarticles__' . $sFieldName;
$this->$_sArtFieldName = $oArtExt->$_sArtExtFieldName;
}
einfach vor das return $this->_oLongDesc
Eine Smarty-Funktion würde ich bevorzugen, weil weniger Modulstress, dort müssen die Felder halt an das “oDetailsProduct”, oder wie das objekt noch mal gleich heißt, eingepflanzt werden.
Ansonsten hilft wohl nur eine Feature-Anfrage oder Achtung jetzt kommts: einfach die oxarticles für eigenen Spalten benutzen.
adios, Stefan
[QUOTE=Marco Steinhaeuser;80850]Hi,
Feature-Anfrage?
https://bugs.oxid-esales.com/view.php?id=3541
Gruß[/QUOTE]
It’s not a feature, it’s a bug…