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

Bug #1984 hierselect producing extra characters
Submitted: 2004-07-26 12:51 UTC Modified: 2006-12-24 15:47 UTC
From: pear dot 20 dot rytsarsky at spamgourmet dot com Assigned: avb
Status: Closed Package: HTML_QuickForm
PHP Version: 4.3.3 OS: linux
Roadmaps: (Not assigned)    
Subscription  


 [2004-07-26 12:51 UTC] pear dot 20 dot rytsarsky at spamgourmet dot com
Description: ------------ When displaying a form with a hierselect, the characters '//]]>' appear right before the first (main) element. The resulting html has //]]> </script> //]]> </script> right there. I'm guessing that that should just be there once. Reproduce code: --------------- $form = new QuickForm('', 'get'); $sel =& $form->addElement('hierselect', 'category', 'Category: '); $form->addElement('submit', 'submit', 'Search'); $sel->setMainOptions($main); $sel->setSecOptions($sec); echo $form->toHtml(); Expected result: ---------------- Category: [MainSelect] [SecSelect] Actual result: -------------- Category: //]]>[MainSelect] [SecSelect]

Comments

 [2004-07-26 14:31 UTC] avb
Cannot reproduce the problem. "Reproduce" code is a total joke, having the wrong classname for Quickform.
 [2004-07-27 09:47 UTC] pear dot 20 dot rytsarsky at spamgourmet dot com
Okay... I was able to produce a test case that demonstrates this bug. Here's the code: (mainly from http://www.thelinuxconsultancy.co.uk/quickform.html) ---------- <?php require_once "HTML/QuickForm.php"; $form = new HTML_QuickForm('frmTest', 'get'); $main = array(); $secondary = array(); $main[0] = "England"; $main[1] = "Scotland"; $main[2] = "USA"; $secondary[0][0] = "London"; $secondary[0][1] = "Manchester"; $secondary[0][2] = "Liverpool"; $secondary[1][3] = "Edinburgh"; $secondary[1][4] = "Glasgow"; $secondary[2][5] = "Fort Worth"; $secondary[2][6] = "Boston"; $secondary[2][7] = "Los Angles"; $sel =& $form->addElement('hierselect', 'location', 'Location:'); $sel->setMainOptions($main); $sel->setSecOptions($secondary); $form->addElement('submit', 'btnSubmit', 'Submit'); if ($form->validate()) { // Form is validated, then processes the data $form->freeze(); $form->process('process_data', false); } else { $renderer =& $form->defaultRenderer(); $form->accept($renderer); $form->display(); } function process_data ($values) { echo "<pre>"; var_dump($values); echo "</pre>"; } ?> ---------- Just by adding the two lines: $renderer =& $form->defaultRenderer(); $form->accept($renderer); You can see the behavior described in the initial report.
 [2004-07-27 12:18 UTC] avb
OK, now I can reproduce. Although there is a problem with the code, the part $renderer =& $form->defaultRenderer(); $form->accept($renderer); $form->display(); is redundant as it actually renders the form *twice*. You should leave either $form->display(); or $renderer =& $form->defaultRenderer(); $form->accept($renderer); echo $renderer->toHtml(); With the original code, even if this bug is fixed you may still have some undesired behaviour.
 [2004-07-27 12:32 UTC] pear dot 20 dot rytsarsky at spamgourmet dot com
First, I'm not just getting the default renderer, then accepting it... I'm actually changing it between those steps, so they have to stay, but the changes don't have to be there to see the bug. In other words... $renderer =& $form->defaultRenderer(); // do stuff to $renderer here, but that doesn't effect the bug $form->accept($renderer); $form->display(); Also, setting the renderer and calling echo $form->toHtml() as suggested still results in those extra characters. As I understand it, setting the renderer doesn't actually render the form, it just tells the object how to render when toHtml or display is called.
 [2004-07-27 12:49 UTC] avb
1. Look at the package code, $form->display() calls $form->toHtml() which calls $form->accept() *again*. accept() is *the* rendering method. 2. Look (closely) at my message, it has $renderer->toHtml(), *not* $form->toHtml() (see 1.). 3. The preferred means of techsupport is pear-general mailing list, *not* the bug system.
 [2004-07-27 22:09 UTC] pear dot 20 dot rytsarsky at spamgourmet dot com
My Bad. It's just that that method worked for all elements other than hierselect. I still say this is a bug. I wasn't trying to get tech support, I was simply trying to explain what I did to see the bug. Sorry I misread your code, your solution does seem to work, except that it now requires hidden elements to be added to the form before all the other elements, weird.
 [2004-10-09 14:33 UTC] avb
This bug has been fixed in CVS. In case this was a documentation problem, the fix will show up at the end of next Sunday (CET) on pear.php.net. In case this was a pear.php.net website problem, the change will show up on the website in short time. Thank you for the report, and for helping us make PEAR better.