awesome-cakephp
awesome-cakephp copied to clipboard
Add FormBuilder library
https://github.com/bancer/form-builder
At this point we only accept new plugins that can be 4.x compatible
I have not tested it with 4.x yet but I believe it is compatible.
I did a quick testing with CakePHP 4.2.10. It is compatible.
This is not how dependency versioning works https://github.com/bancer/form-builder/blob/master/composer.json#L4-L6
Major versions of Cake are different enough that it warrants proper constraining on the dependencies.
I am still a bit unsure about this at this point.
Well, FormHelper is the only CakePHP class that I use and it is not very different between 3.x and 4.x (in terms of signatures of public methods). If signatures of FormHelper public methods will not change in 5.x it will be compatible with 5.x too. I intentionally do not constrain FormBuilder to a specific CakePHP version and I believe I can make it work quite easily even with 2.x if the need arrives. It is just a simpler wrapper. What is your concern?
I did a quick testing with CakePHP 4.2.10. It is compatible.
Sorry, that's not good enough. You need to run the testsuite with CakePHP 4 as part of your CI setup.
Sorry, that's not good enough. You need to run the testsuite with CakePHP 4 as part of your CI setup.
That would mean that many assertions would need to be rewritten because 4.x FormHelper generates different HTML than in 3.x. I really see no good reason to do that because the code of FormBulder itself will not need to be changed in order to pass the new tests. Take a look at this method for example: https://github.com/bancer/form-builder/blob/master/src/DateTag.php#L68-L72
public function __toString()
{
$options = $this->getOptions();
return $this->FormHelper->date($this->fieldName, $options);
}
This is compatible both with 3.x and 4.x although would generate different HTML as expected.
You need to proof your compatibility by actuall using require on all major versions and provide a test for highest and lowest (prefer lowest) as we always do. This way, it can be sure not to break in the future somehow for older ones (hidden regressions).
If outputted HTML is different, maybe assert on it more dynamically, or write a test case per major, and skip for non fitting major. There are quite a few ways to do it.
Usually however, you would just support 1 framework major per branch/major, and just merge across them.