Validation appears broken if you attempt to sub-class the Form class to add functionality of your own.

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Create your own sub-class of Form (MyForm) and ensure that you redefine any 
private members in the class definition.
2. Attempt to create a for using your subclassed MyForm, and then validate its 
content during a submit. 

What is the expected output? What do you see instead?

The form will render properly, and but all validation ceases to work, you don't 
get error messages, and invalid data does not fail.

What version of the product are you using? On what operating system?

2.3

Please provide any additional information below.

My company wishes to utilize this script to generate forms within our web 
application software. To accomplish this in a friendly manner, we decided to 
attempt to subclass the Form class so that we could apply default behavior to 
our sub class for use within our platform. For the most part this worked just 
fine until I got to testing the validation process at which point the error 
messages wouldn't work anymore and bad data wasn't actually coming up as 
invalid.

My code is as follows;

class exchangeForm extends Form
{
    private $elements = array();
    private $prefix = "http";
    private $values = array();
    private $widthSuffix = "px";

    function __construct($id = 'pfbc', $width = 580)
    {
        parent::__construct($id, $width);
        $this->configure(array(
        'resourcesPath'=>'lib/PFBC/Resources',
        'preventXHTMLStrict' => 1,
        //'view'=>new View_SideBySide(200, array('labelRightAlign'=>1)),
        //'view'=>new View_Horizontal,
        //'view'=>new View_Grid(array(2,1,1)),
        'action'=>$_SERVER['PHP_SELF'].'?'.$_SERVER['QUERY_STRING'],
        'method'=>'post',
        ));
        $this->addElement(new Element_Hidden('form', $id));
    }

    function submitted()
    {
        if ( isset($_POST['form']) && $_POST['form'] == $this->getId() )
        {
            return True;
        }
        else
        {
            return False;
        }
    }
}

My theory is that this has something to do with the visibility of 
members/member functions throughout the Form class and that there's more than 
just the private member variables causing a problem. Apart from that I'm not 
sure where to start looking for an answer to this problem, and was hoping 
someone at the project could shake their head, point a finger and tell me 
"*sigh*, here,... just look here".  :D

Thanks in advance!

Original issue reported on code.google.com by broum...@gmail.com on 10 Oct 2011 at 5:34

[GoogleCodeExporter]

I have the same problem issue #156, i am curious if it in your case also has to 
do with the serialisation of the object in Form.php:

    /*The save method serialized the form's instance and saves it in the session.*/
    private function save() {
        $_SESSION["pfbc"][$this->attributes["id"]]["form"] = serialize($this);
    }

What do you get when you 
var_dump(unserialize($_SESSION["pfbc"][$this->attributes["id"]]["form"])); 

Regards,Daniel

Original comment by webvan...@gmail.com on 11 Oct 2011 at 8:33

[GoogleCodeExporter]

Excuse me, i meant issue #155

Original comment by webvan...@gmail.com on 11 Oct 2011 at 12:14

[GoogleCodeExporter]

Hi Daniel, 

You know what, the serialize error you describe is what I ran into before this, 
and I... "sort of" solved it by adding the re-definition of the private member 
variables you see at the top of my class. 

What I wonder about is the reasoning behind the visibility of some members and 
functions in the Form class. The developers have used protected members sure, 
but they're also using entirely private members and functions which now, as far 
as I read on php.net, no longer get duplicated in child classes. This means 
that our sub-classes are missing the odd function, wherever "private function" 
has been used.

In the form class this includes;
Form::recover()
Form::applyValues()
Form::renderCSS()
Form::renderCSSFiles()
Form::renderJS()
Form::renderJSFiles()
Form::save()

Now, if I'm reading the information in php's docs on visibility properly, these 
methods are not available within our subclasses, and it was after reading about 
this that I added in the private member definitions at the top of the sub class 
to try to solve the issue. Now of course I hadn't reproduced all the functions 
but perhaps that's the answer, to simply build in private function aliases to 
the parent::function() involved, like so;

private function applyValues()
{
    return parent::applyValues();
}

I'll give this a try, and post again shortly. (to be honest this feels kinda... 
hacky, to me... but.. whatever works right?)

Original comment by broum...@gmail.com on 11 Oct 2011 at 4:24

[GoogleCodeExporter]

No Dice. As you can see from the attached file I've aliased the functions, but 
when using this class in practice I still get no error warnings when I submit 
the form.

I'll do a bit more digging into how the validation works and see what I can 
come up with.

Original comment by broum...@gmail.com on 11 Oct 2011 at 4:34

Attachments:

• Form.class.php

[GoogleCodeExporter]

Hey Guys,

I wanted to chime in regarding this issue you're having with extending the Form 
class within the PFBC project.  The form's configure method allows you to set 
any protected (or public) properties of the form.  There are some properties, 
that I don't want set by the end user, which is why you see private properties.

That being said, I realize now that private properties and methods are 
unintended consequences - i.e. problems extending the Form class.  So, let me 
spend some time re-thinking and re-implementing this workflow.  I'm confident 
that with a few tweaks, you'll be able to extend the Form class without running 
into these issues.

- Andrew

Original comment by ajporterfield@gmail.com on 11 Oct 2011 at 4:39

[GoogleCodeExporter]

Hi Andrew, thanks for jumping in!

I had already considered just changing all the private definitions to protected 
and seeing if that made a difference but I really didn't want to get into 
modifying your code if I could avoid it (hence trying to sub-class it in the 
first place).

Original comment by broum...@gmail.com on 11 Oct 2011 at 4:58

[GoogleCodeExporter]

Yep, understand.  To help set your expectations accordingly, I'll try to have 
something for you to try by the end of this week.

- Andrew

Original comment by ajporterfield@gmail.com on 11 Oct 2011 at 5:10

[GoogleCodeExporter]

Changed all private members/functions to protected and my code is now working 
with my sub-class as desired.

I know this will take more consideration on your part Andrew but so far this 
has worked to fix the problem for my purposes.

Daniel, you might try this as well, I think it will correct your problems with 
serialization.

Original comment by broum...@gmail.com on 11 Oct 2011 at 5:10

[GoogleCodeExporter]

Oh, sorry Andrew we posted at the same time there. I can run in the short term 
with what I've done, you don't need to rush out an update or anything, but 
knowing that this bug is in your ear for the next release is good stuff. I'm 
still very excited about this project and the other dev and I at our little 
company are really excited to use your code. We just needed to add some 
routines to it before we could do that, hence our little thread here.
Thanks for the back-and-forth on this!

Original comment by broum...@gmail.com on 11 Oct 2011 at 5:15

[GoogleCodeExporter]

I was able to make several updates in the latest revision - r552 - that I 
believe will make extending the Form class function as expected.  I haven't 
fully tested.  Could you please pull down this revision and test your 
implementation?

svn export http://php-form-builder-class.googlecode.com/svn/trunk/ 
php-form-builder-class

- Andrew

Original comment by ajporterfield@gmail.com on 12 Oct 2011 at 3:29

[GoogleCodeExporter]

Sorry this version is the php 5.3 version, and our servers only run php 5.2 
currently, so I get compatibility errors right off the hop as you attempt to 
define your namespace.

Can you make the same changes to your 5.2 branch and post that so I can test it 
for you?

Original comment by broum...@gmail.com on 12 Oct 2011 at 3:20

[GoogleCodeExporter]

Yes, I can do that.  It won't be until this evening until I can get to it 
though as I'm currently at work.

- Andrew

Original comment by ajporterfield@gmail.com on 12 Oct 2011 at 3:41

[GoogleCodeExporter]

No worries Andrew, like I said, I've got a working version of your code where 
I've made all the changes to the functions and members. I just did so ignorant 
of any other intentions you had about how it should work.

I've attached a copy of my Form.php 

Original comment by broum...@gmail.com on 12 Oct 2011 at 3:46

Attachments:

• Form.php

[GoogleCodeExporter]

Changing all the private members/functions from private to protected makes the 
validation work again, thanks!
For now it's ok but it's not the nicest way of doing this. I don't like 
changing the project's source because it will break the next time it must be 
updated. I hope this issue will be fixed soon.

Andrew, thanks for the great work, i really like this project.

Original comment by webvan...@gmail.com on 24 Oct 2011 at 8:19