On Wed, Jul 3, 2013 at 1:59 PM, Ayush Chaudhary ayushchd@gmail.com wrote:

Hi,

On Wednesday, 3 July 2013 at 2:08 PM, Dieter Adriaenssens wrote:

2013/7/3 Ayush Chaudhary ayushchd@gmail.com:

Hi,

Is there a reason why validation.lib.php is not a class with public static method? Is it okay to convert it to a class with all methods' access specifier as public static?

Did you mean the PMA_SQLValidator class in libraries/sqlvalidator.class.php? I didn't find a validation.lib.php, or something similar, in the PMA codebase, that contains a class. (libraries/config/validate.lib.php doesn't contain a class)

Sorry for not being clear. I was referring to the library libraries/config/validate.lib.php. I am currently writing tests for libraries/config/FormDisplay.class.php, and there are numerous calls to functions from validate.lib.php which cannot be mocked because they are not contained in a class. Also, the same issue holds for libraries/config/FormDisplay.tpl.php

I am in favor of putting these functions into a class as static methods.

Assuming you mean PMA_SQLValidator, this is not a static class, ie. it has to be instanciated (= turned into an object), so it can't have static methods. [1] To use (or test) this class, you have to create an instance and call the methods from that instance, fe.

$validator = new PMA_SQLValidator();

$validator->start();

(see libraries/sqlvalidator.lib.php for an example on how to instanciate and use the PMA_SQLValidator class)

BTW : Testing a class instance can sometimes be tricky, especially if it communicates with, or uses another class. If this is the case, you will have to use Mock objects [0] and Stubs to simulate the expected behaviour of the other class.

I wanted to use mocking and just set expectations with parameters, but that won't be possible unless these libraries are converted to classes

Here [1] is a good blog post from the author of PHPUnit about mocking static methods.

[1] http://sebastian-bergmann.de/archives/883-Stubbing-and-Mocking-Static-Method...

hi can i have 2 actions on 1 form in php?

On Mon, Jul 8, 2013 at 1:46 PM, Ayush Chaudhary ayushchd@gmail.com wrote:

On Wednesday, 3 July 2013 at 8:41 PM, Madhura Jayaratne wrote:

On Wed, Jul 3, 2013 at 1:59 PM, Ayush Chaudhary ayushchd@gmail.comwrote:

Hi,

On Wednesday, 3 July 2013 at 2:08 PM, Dieter Adriaenssens wrote:

2013/7/3 Ayush Chaudhary ayushchd@gmail.com:

Hi,

Is there a reason why validation.lib.php is not a class with public static method? Is it okay to convert it to a class with all methods' access specifier as public static?

Did you mean the PMA_SQLValidator class in libraries/sqlvalidator.class.php? I didn't find a validation.lib.php, or something similar, in the PMA codebase, that contains a class. (libraries/config/validate.lib.php doesn't contain a class)

Sorry for not being clear. I was referring to the library libraries/config/validate.lib.php. I am currently writing tests for libraries/config/FormDisplay.class.php, and there are numerous calls to functions from validate.lib.php which cannot be mocked because they are not contained in a class. Also, the same issue holds for libraries/config/FormDisplay.tpl.php

I am in favor of putting these functions into a class as static methods.

Waiting for more confirmations :)

Assuming you mean PMA_SQLValidator, this is not a static class, ie. it has to be instanciated (= turned into an object), so it can't have static methods. [1] To use (or test) this class, you have to create an instance and call the methods from that instance, fe.

$validator = new PMA_SQLValidator();

$validator->start();

(see libraries/sqlvalidator.lib.php for an example on how to instanciate and use the PMA_SQLValidator class)

BTW : Testing a class instance can sometimes be tricky, especially if it communicates with, or uses another class. If this is the case, you will have to use Mock objects [0] and Stubs to simulate the expected behaviour of the other class.

I wanted to use mocking and just set expectations with parameters, but that won't be possible unless these libraries are converted to classes

Here [1] is a good blog post from the author of PHPUnit about mocking static methods.

[1] http://sebastian-bergmann.de/archives/883-Stubbing-and-Mocking-Static-Method...

-- Thanks and Regards,

Madhura Jayaratne

---

This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel

---

This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel

2013/7/8 Ayush Chaudhary ayushchd@gmail.com:

On Wednesday, 3 July 2013 at 8:41 PM, Madhura Jayaratne wrote:

On Wed, Jul 3, 2013 at 1:59 PM, Ayush Chaudhary ayushchd@gmail.com wrote:

Hi,

On Wednesday, 3 July 2013 at 2:08 PM, Dieter Adriaenssens wrote:

2013/7/3 Ayush Chaudhary ayushchd@gmail.com:

Hi,

Is there a reason why validation.lib.php is not a class with public static method? Is it okay to convert it to a class with all methods' access specifier as public static?

Did you mean the PMA_SQLValidator class in libraries/sqlvalidator.class.php? I didn't find a validation.lib.php, or something similar, in the PMA codebase, that contains a class. (libraries/config/validate.lib.php doesn't contain a class)

Sorry for not being clear. I was referring to the library libraries/config/validate.lib.php. I am currently writing tests for libraries/config/FormDisplay.class.php, and there are numerous calls to functions from validate.lib.php which cannot be mocked because they are not contained in a class. Also, the same issue holds for libraries/config/FormDisplay.tpl.php

I am in favor of putting these functions into a class as static methods.

Waiting for more confirmations :)

I agree too.

BTW : In an ideal world, everyone on this mailing list, or at least the core developers would have voted in favor or against. In practice, if nobody objects within a few days, it is a silent agreement. ;)

Kind regards, Dieter Adriaenssens