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

Bug #2915 tripleLinks aren't frozen with the rest of the form
Submitted: 2004-12-07 20:59 UTC
From: justinpatrin Assigned: justinpatrin
Status: Closed Package: DB_DataObject_FormBuilder
PHP Version: Irrelevant OS: Irrelevant
Roadmaps: (Not assigned)    
Subscription  
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:
MUST BE VALID
Solve the problem : 49 + 35 = ?

 
 [2004-12-07 20:59 UTC] justinpatrin
Description: ------------ When you $form->freeze(); on an FB created form, any triplelinks aren't frozen. Unfortunately this is due to how the triplelinks are created. They use HTML_Table and a static element for display. I'm not sure how to fix this, but wanted to get the bug in here.

Comments

 [2004-12-07 22:50 UTC] mw21st
Just a quick idea, don't know if it's practical or even if it can be done: Maybe a new method freezeForm() could be added to FormBuilder itself - if you need to freeze the form prior to outputting it, you could call it and FormBuilder would render the checkboxes as [x], like the default QuickForm renderer does.
 [2004-12-07 22:56 UTC] justinpatrin
I did think of that (long ago when I first noticed this), but you'd have to call it *before* FB creates the form. In other words, it would have to be in the config before the getForm() call, which means you can't validate the form...which means this would be useless for the "normal" use of freezing the form. i.e: $form = $fb->getForm(); if ($form->validate()) { //process $form->freeze(); } You could get around this by *recreating* the form when it's frozen...or redirecting, as I do, then displaying a frozen form (with this new option). The only way I can think of to completely fix this is to move the checkboxes into the $form object, but there's no easy way to do that...aside from a special renderer....or...hmmm....a new element type. That's the way we should go. A new "checkbox table" element type. We could easily put it in another class file and lazy-load/register it for triplelinks. Duh!
 [2004-12-12 08:35 UTC] justinpatrin
Following my own advice I created a new QF element type called 'elementTable'. It's committed to CVS, as is the fix for FB to use it. It works perfectly in my testing, freezing as a normal QF element. I have yet to handle setDefaults, however. This should fix all of our QF dependencies once I move this into the QF driver as well. Please try tripleLinks using the CVS version of FB and make sure it works as before.
 [2004-12-12 08:58 UTC] justinpatrin
I just submitted another patch to CVS which uses setDefaults correctly. The triplelinks are now a real part of the QF form. I still have not moved the creation to the FB_QF driver.
 [2004-12-12 09:16 UTC] justinpatrin
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. Sorry for the multiple updates tonight. I kept finding more time. ;-) Please check to make sure the triplelinks code works as it used to and as it should. Thanks.