dibi fórum

nic to nemění. DibiRow se stále chová jako pole

ArrayObject je zbytečně komplikovaný a jsou tam věci, které nejsou pro DR třeba. KISS

Hm, tak nevím, jestli to je už v téhle verzi, ale dneska jsem stáhnul verzi z 2010–04–26 a přestalo mi fungovat tohle:

<?php
public function getOperators($country_code = NULL)
{
        $select = dibi::select('*')->from('sd_operators');
        if (!empty($country_code))
        {
                $select->where("country_code = %s", $country_code);
        }
        return $select->fetchAssoc('operator_id');
}
...
$operators = $services->getOperators($this->template->service['country']);
...
foreach ($operators as &$operator)
{
        $operator['revenues'] = array();
        foreach ($this->template->revenue_groups as $revenue_group_id => $tmp)
        {
!!!             $operator['revenues'][$revenue_group_id] = NULL;
        }
}
unset($operator);

foreach ($revenues as $revenue)
{
!!!     $operators[$revenue['operator_id']]['revenues'][$revenue['revenue_group_id']] = $revenue['value'];
}
?>

Na řádcích označených !!! – tj. změna objektu DibiRow mi to vyhazuje:

PHP Notice: Indirect modification of overloaded element of DibiRow has no effect in …

a nic nepřiřadí. Ve verzi z 2010–04–06 to fungovalo.

Takže co je jinak? Co jsem koukal do zdrojáků DibiRow, tak by se to opravdu mělo chovat jako pole…

EDIT:

Ještě jsem to trochu prošel, tak ten řádek

<?php
$operator['revenues'] = array();
?>

projde, tj. v objektu DibiRow vytvoří novou položku „revenues“, která je pole, ale když chci přidat do tohoto pole index, tak to už nedá.

EDIT 2:

Tak to asi souvisí s tímhle BUGem v PHP?

http://bugs.php.net/bug.php?…
( http://bugs.php.net/bug.php?… )
( http://bugs.php.net/bug.php?… )

EDIT 3 (snad naposled) – ŘEŠENÍ:

Tak když k tomu ‚revenues‘ nepřistupuju jako prvku v poli, ale jako členské proměnné, tak to funguje, tj.:

<?php
$operator->revenues = array();
...
$operator->revenues[$revenue_group_id] = NULL;
...
$operators[$revenue['operator_id']]->revenues[$revenue['revenue_group_id']] = $revenue['value'];
?>

Editoval Petr Daňa (30. 4. 2010 14:28)

ahoj, DibiRow je hloupý Data Transfer Object. dělat z něj děděním cokoliv jiného je chybou v návrhu. tvá základní modelová/ORM třída by nikdy neměla objekt řádku rozšiřovat – měla by jej spíše obsahovat. pak bys neměl důvod implementovat vlastní třídu NěcoRow

nevyřešila by tvůj aktuální problém prostá náhrada property_exists() za isset()?

paranoiq napsal(a):

ahoj, DibiRow je hloupý Data Transfer Object. dělat z něj děděním cokoliv jiného je chybou v návrhu. tvá základní modelová/ORM třída by nikdy neměla objekt řádku rozšiřovat – měla by jej spíše obsahovat. pak bys neměl důvod implementovat vlastní třídu NěcoRow

nevyřešila by tvůj aktuální problém prostá náhrada property_exists() za isset()?

Ahoj,
to je úhel pohledu. Proč bych měl v základní třídě pro row uchovavat DibiRow? To tam můžu rovnou uchovávat data v primitivním poli (což také dělám). Tím že nahradím DibiRow svým objektem, mohu pořád využívat kouzla dibi, jako fetchAssoc. Ale jak to vidím, nic jiného mi stejně nezbyde.
Přesto stále tvrdím, ze implementace rozhraní je nejlepší řešení. Třeba Nette na tom stojí celé.

Voláním setRowClass(FALSE) si můžete nechat vracet pole.