Package home | Report new bug | New search | Development Roadmap Status: Open | Feedback | All | Closed Since Version 1.0.2

Bug #6894 _reorderElements unusual case
Submitted: 2006-02-22 18:48 UTC
From: car at cespi dot unlp dot edu dot ar Assigned: justinpatrin
Status: Closed Package: DB_DataObject_FormBuilder (version 1.0.0RC2)
PHP Version: Irrelevant OS: ALL
Roadmaps: (Not assigned)    
Comments Add Comment Add patch

Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know! Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
Solve the problem : 26 + 42 = ?

 [2006-02-22 18:48 UTC] car at cespi dot unlp dot edu dot ar (Christian Adri├ín Rodriguez)
Description: ------------ In case _getFieldsToRender() is disjoint from preDefOrder, there is a problem in the _reoprderElements method. The error rises at line 1652. In know it is a very unusual case, but I think declaring the ordered variable as an empty array is a cleaner solution than the current one. Test script: --------------- I propose declaring $ordered variable as empty array in line 1635


 [2006-02-22 18:50 UTC] justinpatrin
Please include some information as to what fields you're listing in those 2 options, what actually happens, and what you expect to happen.
 [2006-02-22 19:03 UTC] car at cespi dot unlp dot edu dot ar
if you look at the code, in the lines I mentioned, In my opinion, it make sense to declare the variable. The example you asked me to post could by like this: class DataObjects_Distrito extends DB_DataObject { var $fb_fieldLabels = array('id_localidad'=>'Localidad','id_entidad'=>'Entidad'); var $fb_linkDisplayFields = array('nombre'); /************ The following two lines raise the bug ****** var $fb_preDefOrder=array('nombre'); var $fb_fieldsToRender=array('email'); // ###START_AUTOCODE /* the code below is auto generated do not remove the above tag */ public $__table = 'distrito'; // table name public $id; // int(11) not_null primary_key auto_increment public $nombre; // string(100) not_null unique_key public $id_localidad; // int(11) not_null multiple_key public $direccion; // string(255) public $telefono; // string(100) public $email; // string(100) public $id_entidad; // int(11) not_null multiple_key /* Static get */ function staticGet($k,$v=NULL) { return DB_DataObject::staticGet('DataObjects_Distrito',$k,$v); } /* the code above is auto generated do not remove the tag below */ ###END_AUTOCODE }
 [2006-02-22 19:12 UTC] justinpatrin
What is the error you're seeing? You need to give me more info. What actually happens and what do you think should happen? Are the fields displayed in a "wrong" order? Is it not displaying a field it should? Is a field editable when it should not be? Are you seeing a PHP warning or notice? You need to include more information on what is actually wrong.
 [2006-02-22 19:15 UTC] justinpatrin
This bug has been fixed in CVS. If this was a documentation problem, the fix will appear on by the end of next Sunday (CET). If this was a problem with the website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better. Ok, I think I understand what you're saying. You're saying that there is a notice or warning of some kind when preDefOrder and fieldsToRender don't have any shared fields. Yes, $ordered should be initialized here. It would have been much easier to understand this if you have included the error message that you were seeing.
 [2006-02-22 19:21 UTC] car at cespi dot unlp dot edu dot ar
The problem with the example I gave, and the following two lines: var $fb_preDefOrder=array('nombre'); var $fb_fieldsToRender=array('email'); That are disjoint sets of table fields of my do, gives the following error: /usr/share/php/DB/DataObject/FormBuilder.php (1652) Undefined variable: ordered So I suggested a solution to, in my opinion, a better or cleaner way to write the _reorderElements method. Please take a look at the code in the error line, and then consider declaring the ordered variable. But as it is an unusual case, you should not consider my report, and instead advice not to declare those variables disjoints.
 [2006-02-22 19:31 UTC] justinpatrin
This bug is fixed in CVS, as said in the last change I made. Please do not re-open it again. Declaring those 2 options disjoint should be supported and that variable should have been initialized. I had forgotten to do it. In the future please always include the entire error message in your error reports.