Re: Re: DB_DataObject bug (IMHO): table($table) method and INI file storage

From: Date: Sun, 10 Apr 2005 17:22:28 +0000
Subject: Re: Re: DB_DataObject bug (IMHO): table($table) method and INI file storage
References: 1 2  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-37153@lists.php.net to get a copy of this message
On Apr 10, 2005 5:42 AM, Stijn de Reede <sjr@gmx.co.uk> wrote: > > Hmm... I just realized my field hack won't work, since update() and > insert() will generate SQL for non-existing fields. I think I ned to > overwrite the insert() and update() method, to update the fields there. > But still, it's something to think about, where should the overridden > table definitions be used? > I would recommend instead of using references to internal vars you override fetch() and copy the values to the non-language specific member vars. You would only need to set the language once before you do your first fetch as it's the same object. Alan's mention of getters is also a good idea. > > Stijn > > > Stijn de Reede wrote: > > > Hi all, > > > > I've come across a small problem with DB_DataObject. I'll describe my > > situation first. > > I creating a CMS with multiple language support. The fields in de table > > will be something like: name_en, name_nl, name_de, etc. So the name of > > the field with an underscore and the language appended. The template > > layer of frontend and backend part of CMS will still be using > > name, > > without the language. I'm trying to extend the DB_DataObject classes, so > > references will be made to the correct fields (depending on a session > > language var). > > I've created the following function in my DB_DataObject: > > > > function referenceLanguage() { > > $vars = get_object_vars($this); > > foreach ($vars as $var => $value) { > > if (substr($var, -3) == > > '_'.$_SESSION['c']['language']['edit']) { > > $newvar = substr($var, 0, -3); > > $this->$newvar =& $this->$var; > > } > > } > > } > > > > I'm calling this function from the contructor. In the contructor, I also > > update the table definition for the object with > > > > $table = $this->table(); > > foreach ($table as $var => $type) { > > if (substr($var, -3) == > > '_'.$_SESSION['c']['language']['edit']) { > > $table[substr($var, 0, -3)] = $type; > > } > > } > > $this->table($table); > > > > > > *Now, here comes the problem*: the update() and insert() methods use the > > cached INI file, instead of the updated table difinition (code from > > DataObject.php: > > > > $items = isset($_DB_DATAOBJECT['INI'][$this->_database][$this->__table]) > > ? $_DB_DATAOBJECT['INI'][$this->_database][$this->__table] : > > $this->table(); > > > > The setFrom method doesn't do this, and only uses the table() method. I > > think all methods should use the table() method, since otherwise > > updating your table definition manually isn't really useful. > > > > > > > > *Then another related problem:* > > As you saw, I created refereces to the correct fields with the correct > > language. Since I'm using HTML_Template_Xipe, I want to collect multiple > > result rows in an array within PHP, and then walk over the array in the > > template. Like so: > > > > $content_text = DB_DataObject::factory('Content_text'); > > $content_text->find(); > > $content_texts = array(); > > while ($content_text->fetch()) { > > array_push($content_texts, $content_text); > > } > > > > But this creates a problem. Firstly the contructor isn't called for each > > fetch, so the referenceLanguage() method isn't called either. This can > > be resolved by overriding the fetch() method and adding the > > referenceLanguage() call their. But this still doesn't solve the problem > > because the references to the language fields remain the same references > > when pushing the object onto the array. Meaning... name > > references the > > last name_en field for all the objects in the array. > > PHP makes a shallow copy of the object, keeping the references. How can > > I solve this problem? Overwriting the the __clone() method isn't quite > > right I think... > > > > > > > > Regards, > > > > Stijn > > -- > PEAR Development Mailing List (http://pear.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Justin Patrin

« previous php.pear.dev (#37153) next »