labelCallback bei copy/cut&paste

Ich habe heute ein seltsames Problem in meinem eigenen Modul.
In der labelCallback Methode in meinem Modul mache ich eine Ausgabe in Abhängigkeit von den Daten in $row, was ja bekanntermaßen der erste Parameter des Callbacks ist. Das klappt auch prima.

Wenn ich aber die Zeile (achja, ich bin im treeview, mode 5) dann per cut oder copy in die Zwischenablage von Contao tue, dann ist dieser Parameter leer. Bin ich da über einen Bug gestolpert?

PHP-Code:

---

public function labelCallback($row, $label, DataContainer $dc=null, $imageAttribute='')
{
    return '<pre>'.print_r($row, true).'</pre>';
} 


---

die Ausgabe sieht dann in diesem Fall, also für die Zeile im Treeview, leider so aus:

PHP-Code:

---

Array
(
    [protected] => 
) 


---

Update:

1.) in tl_pages funktioniert das, warum nicht bei mir?

2.) ich bin dem jetzt der Sache bis zur Zeile 2989 in der DC_Table.php gefolgt. Für den Eintrag, der gerade in der Zwischenablage ist, gibt es dort kein korrektes $objRow.

Was passiert denn bei click auf cut oder copy zuvor alles?

Also das ist ein Bug: Die Tabelle meiner Erweiterung hat im Gegensatz zu tl_page kein Field "protected".

In Zeile 3022 der DC_Table.php ist aber sowas drin:

PHP-Code:

---

$objRow->protected = ($table == 'tl_page') ? ($objRow->protected || $protectedPage) : false; 


---

Vor dieser Zeile sieht die Eigenschaft "arrCache" bei einem print_r von $objRow so aus:

PHP-Code:

---

    [arrCache:protected] => Array
        (
            [1] => Array
                (
                    [id] => 182
                    [pid] => 1
                    [sorting] => 192
                    [tstamp] => 1299500582
                    [name] => 
                    [introduction] => 
                    [visible] => 1
                )

        ) 


---

Nach dieser Zeile aber so:

PHP-Code:

---

[arrCache:protected] => Array
        (
            [1] => Array
                (
                    [id] => 182
                    [pid] => 1
                    [sorting] => 192
                    [tstamp] => 1299500582
                    [name] => 
                    [introduction] => 
                    [color] => 0
                    [informationsId] => 153
                    [type] => cluster
                    [visible] => 1
                )

            [0] => Array
                (
                    [protected] => 
                )

        ) 


---

Also muss entweder dokumentiert sein, dass im mode=5 (treeview) eine Tabelle immer das Feld "protected" haben muss, oder aber diese Eigenschaft darf in Zeile 3022 gar nicht gesetzt werden, wenn kein Feld "protected" vorhanden ist!

Ich werde mal gucken, wie ich das mit wenigen Worten in die Bugbase von Contao geschrieben bekomme...

Update:
Achja, die Konsequenz daraus ist, dass der Aufruf in Zeile 3089 von $objRow->row() die Zeile [0] aus dem arrCache von $objRow nimmt und die richtigen Werte in [1] sind.

ok, das Problem ist ein anderes:

In der onload_callback mache ich einen DB Select auf die gleiche Tabelle. Anscheinend wird da dann der Wert der Tabellen-Zeile mit einem "falschen" Index gecached. Wenn ich an der Stelle den Code ändere, so stimmt auch alles wieder mit dem label... sehr seltsam:

PHP-Code:

---

->execute($id); // vorher
->executeUncached($id); //nachher 


---

Ich muss da nochmal herausfinden, wie das Caching von DB Abfragen funktioniert bei Contao. Das ist sehr verwirrend und hat mich jetzt locker 1/2 Tag gekostet und einen falschen BugReport machen lassen. :(

Ich kann den Fehler nicht reproduzieren. Interessant wäre es auch was du in deinem onload_callback mit dem Database_Result machst, denn der Cache-Index müsste bei 0 beginnen und nicht bei 1.

Hallo Andreas,

also in dem onload_callback mache ich folgendes:

PHP-Code:

---

if ($dc->id) {
    $objRow = $this->Database->prepare("SELECT * FROM ".$dc->table." WHERE id=?")
        ->limit(1)
        ->execute($dc->id)
        ->next();
    // dann kann ich mit $objRow->eigenschaft auf Felder des Ergebnisses (lesend) zugreifen
} 


---

Mehr mache ich nicht. Vielleicht habe ich mir das ->next() falsch abgeguckt und hätte stattdessen ->row() nehmen müssen? Das schlage ich jetzt mal schnell in der API Referenz von Contao nach...

Jedenfalls hat sich das Problem nun gelöst, da ich statt ->execute($dc->id) einfach ->executeUncached($dc->id) benutze.

Danke für die Antwort und Gruß,
Matthias

Update:
http://api.contao.org/Library/Databa...tml#methodnext das sieht aber gut aus, was die next() macht. Da ich leider etwas unter Zeitdruck stehe, kann ich nun das Problem nicht restlos aufklären... ich mach mir eine Notiz und schau später nochmal drauf.

Lass das next() einfach weg, das müsste auch funktionieren. Löst dass das Problem?

Naja, wenn ich das ->next() weglasse, kann ich nicht wie folgt auf die Felder zugreifen:

PHP-Code:

---

$objRow->next();

$id = $objRow->id;
$name = $objRow->name;
$anderes_feld = $objRow->andere_feld; 


---

Ist denn das hier best-practice?

PHP-Code:

---

$row = $objRow->row();

$id = $row['id'];
$name = $row['id'];
$anderes_feld = $row['anderes_feld']; 


---

Welchen Weg nimmst Du?

Hast du es versucht? Du müsstest auch ohne next() auf den ersten Datensatz zugreifen können. Ausser natürlich dein Index im Cache beginnt wieder bei 1 ;)

ok, ok :o du hast mal wieder Recht ;)

ohne das ->next() kann ich tatsächlich schon auf die Eigenschaften zugreifen, auch wenn ich sie mit einem print_r($objRow) noch nicht "sehe":

Code:

---

DB_Mysql_Result Object
(
    [resResult:protected] => Resource id #114
    [strQuery:protected] => SELECT * FROM tl_houses WHERE id='8' LIMIT 0,1
    [intIndex:Database_Result:private] => -1
    [intRowIndex:Database_Result:private] => -1
    [blnDone:Database_Result:private] =>
    [blnModified:Database_Result:private] =>
    [arrCache:protected] => Array
        (
        )
)

---

Wieso habe ich nur das mit dem next() überhaupt angefangen? sehr seltsam! :mad:

Und ist damit auch das Problem behoben, wenn du nicht executeUncached machst?

Oh, das habe ich vergessen zu schreiben!
JA, das Problem ist damit auch gelöst!

Übrigens echt cool, dass Du hier im Forum soviel hilfst und Dich in unser aller Problemchen eindenkst! Echt stark!