Solved code problems in Formulize 3.12

Submitted by dpicella on Tue, 03/23/2010 - 6:22am

There were several modules (Extcal 2.2, AMS 2.42, and Formulize 3.12) causing "XoopsLogger" class errors in the Xoops module that this solution worked for so I am going to direct you to Xoops where I posted a full description of the problem and the solution. It has to do with upgrading to php 5.3x

http://www.xoops.org/modules/newbb/viewtopic.php?topic_id=71182&post_id=...

Hope this helps ... Cheers!

‹ IT Department Applications Database Derived Fields making calculations from framework handles in a unified display ›

Comments

Do you have a reference with info about the issue in PHP 5.3?

Submitted by Julian Egelstaff on Wed, 03/31/2010 - 2:29pm.

I read this page: http://php.net/manual/en/language.references.pass.php and it gives an example of passing in a non-variable by reference to a function, and that produces a fatal error, since 5.0.5.

I'm wondering if you found specific places in Formulize where this syntax needed changing, or if it was just in the xoopslogger?

--Julian

Formulize versus xoopslogger

Submitted by dpicella on Thu, 04/01/2010 - 6:59am.

The code changes are specific to formulize. I will go back through it hopefully later today and give you the specific changes later today.

Cheers!

Details about formulize versus xoopslogger

Submitted by dpicella on Sun, 04/04/2010 - 5:12am.

Here are the details. There are three lines of code that Xoops 2.4.4 will complain about if using php 5.3x

Here they are:

1. Fatal error: Class 'XoopsLogger' not found in /absolutepath/formulize/include/elementdisplay.php on line 139

Here is line 139
$renderer =& new formulizeElementRenderer($element);

2. Fatal error: Class 'XoopsLogger' not found in /absolutepath/formulize/include/class/elementrenderer.php on line 582

Here is line 584
$t =& new XoopsFormCheckBox(

3. Fatal error: Class 'XoopsLogger' not found in /absolutepath/formulize/include/class/elementrenderer.php on line 691

Here is line 691
$t =& new XoopsFormRadio(

I coverted =& to = on these lines and the fatal errors went away.

Now Formulize seems to work fine, however, it does not render yes/no radio buttons correctly. Yes/No radio buttons will both be rendered as "No" -- a problem that I also posted about in this forum but now I seem to have tracked down the radio button assignment issue to this code (more specifically to whatever is going on in elementrenderer.php at 691).

Note ... The yes/no radio buttons derive the "Yes" and "No" from xoops english language documents. Whatever text is assigned to the "_NO" constant will appear as the label for BOTH y/n radio buttons. Both radio buttons are also assigned a "value" of 2 ... So apparently formulize is truly rendering 2 "No" options and not just mixing up the labels.

Follow up on xoopslogger, formulize, and radio buttons

Submitted by dpicella on Sat, 04/10/2010 - 9:00am.

Just a follow up. I am noticing the same behavior with all radio buttons actually.

Whatever the last option is, all choices will be rendered with those properties - and that goes for both plain "radio" buttons and the simple yes/no type.

For example:

If my radio buttons are:

red
blue
green
yellow

The options will be:

yellow
yellow
yellow
yellow

For yes/no they are:

No
No

It would be great to work this out. Probably not a very difficult fix.

Cheers!

Fixed in SVN, details of where the changes were made

Submitted by Julian Egelstaff on Tue, 05/25/2010 - 9:02am.

Hello,

Thanks for the test environment! It would have been a stab in the dark to fix this otherwise. The problem is that in the latest version of PHP, you run into issues when you try to assign a new object to a variable that already has been set (which is kind of strange to do in the first place anyway).

So bottom line, around lines 601 and 716 of the modules/formulize/class/elementrenderer.php file, this code:

$form_ele1->addElement($t);

Needs to have an extra line:

$form_ele1->addElement($t);
unset($t);

$t gets recreated in each loop as a new form element object, which gets added to the collection of elements called $form_ele1. If you specifically unset it at the end of each loop, then PHP stops getting confused about what the actual elements are that XOOPS should render.

This fix has been committed to SVN now. The =& fixes will go in shortly too.

--Julian