| # |
May 29th 2021, 21:40 |
 etibor |
thank you Kevin, i stuck by the buildRules |
| # |
May 29th 2021, 21:38 |
kevin.pfeifer |
let me grab one of my examples |
| # |
May 29th 2021, 21:38 |
kevin.pfeifer |
well this would be perfect for a custom validation rule I would guess |
| # |
May 29th 2021, 21:38 |
kevin.pfeifer |
i see |
| # |
May 29th 2021, 21:38 |
kevin.pfeifer |
ahh |
| # |
May 29th 2021, 21:37 |
etibor |
well, the first part is right, and the second is a bit different, Documents stores the score field, and Storage stores the score minimal and maximal value(there can be different Storeges) and Document's instances have storage_id |
| # |
May 29th 2021, 21:35 |
kevin.pfeifer |
am i right? |
| # |
May 29th 2021, 21:33 |
kevin.pfeifer |
so Storage hasMany Documents and Documents BelongsTo Storage And you want to “restrict” the selection of available Storage inside your Documents Model so they are “filtered” according to your logic |
| # |
May 29th 2021, 21:32 |
etibor |
how can i deal in DocumentsTable.php with the StorageModel ? I have never worked with this like before |
| # |
May 29th 2021, 21:31 |
etibor |
the scenerio is like : Documents have an storage_id, score field(store an int) the maximal and minimal value is stored in the storage Model so Document's score depend on Storage minimal and maximal field |
| # |
May 29th 2021, 21:29 |
kevin.pfeifer |
an example would be easier i would guess so i don’t describe the “wrong” thing |
| # |
May 29th 2021, 21:29 |
etibor |
i havent found any description regarding to this |
| # |
May 29th 2021, 21:29 |
etibor |
how can i implement application validation rule(RulesCheckers) i need to validate one Model depends on ther Model's field value |
| # |
May 29th 2021, 21:28 |
etibor |
Kevin just one last questrion for today |
| # |
May 29th 2021, 21:27 |
kevin.pfeifer |
and see which errors/warnings etc. popup and fix them as they come |
| # |
May 29th 2021, 21:27 |
kevin.pfeifer |
but basically I would just upgrade via composer, set your ```'Error' => [ 'errorLevel' => E_ALL, ]``` in your app.php |
| # |
May 29th 2021, 21:26 |
kevin.pfeifer |
here is a list of all “deprecated” classes etc. https://book.cakephp.org/4/en/appendices/4-0-migration-guide.html |
| # |
May 29th 2021, 21:26 |
kevin.pfeifer |
if you are used to cake3 then cake4 is not different at all |
| # |
May 29th 2021, 21:25 |
etibor |
i hope i will manage not so hard the change |
| # |
May 29th 2021, 21:25 |
etibor |
well for myself it was a disaster when i used to the 2 and i have to change, but thank you for calming me |
| # |
May 29th 2021, 21:24 |
kevin.pfeifer |
and as stated - an upgrade from cake3 to cake4 is definetly not as hard as cake2 to cake3 |
| # |
May 29th 2021, 21:24 |
kevin.pfeifer |
but keeping your software up2date is pretty normal I would say ^^ |
| # |
May 29th 2021, 21:24 |
kevin.pfeifer |
i would guess there will be more “public warnings” when the time comes near |
| # |
May 29th 2021, 21:23 |
etibor |
thank you for warning me for this "dead" line |
| # |
May 29th 2021, 21:21 |
kevin.pfeifer |
which means now you have 1.5 years |
| # |
May 29th 2021, 21:21 |
etibor |
ooo |
| # |
May 29th 2021, 21:21 |
kevin.pfeifer |
so till the end of 2022 |
| # |
May 29th 2021, 21:21 |
kevin.pfeifer |
well 3 years counting from 16 Dec 2019 |
| # |
May 29th 2021, 21:20 |
kevin.pfeifer |
but could be that the core team has decided on some other roadmpa |
| # |
May 29th 2021, 21:20 |
etibor |
so its means having 3 years for prepare for upgrading |
| # |
May 29th 2021, 21:20 |
kevin.pfeifer |
so you get 3 years of security fixes for 3.x |
| # |
May 29th 2021, 21:19 |
kevin.pfeifer |
https://github.com/cakephp/cakephp/releases/tag/4.0.0 |
| # |
May 29th 2021, 21:19 |
kevin.pfeifer |
4.0.0 release on 16 Dec 2019 |
| # |
May 29th 2021, 21:18 |
slackebot |
is released. Our hope is that these time frames give you and your teams ample time to plan and execute an upgrade. |
| # |
May 29th 2021, 21:18 |
kevin.pfeifer |
Our current plans would make the 3.x to 4.0 upgrade relatively easy. Because of this we don’t currently see many reasons to continue doing 3.x feature releases. This would make 3.6 the last 3.x with the possibility of 3.7 happening. If there is enough community interest in it. Furthermore, we plan on doing supporting 3.x with: • Bug fixes for _18 months_ after 4.0.0. • Security fixes for _36 months_ after 4.0.0 |
| # |
May 29th 2021, 21:18 |
kevin.pfeifer |
https://bakery.cakephp.org/2017/06/23/upcoming-cakephp-roadmap.html |
| # |
May 29th 2021, 21:18 |
kevin.pfeifer |
well if we look in here |
| # |
May 29th 2021, 21:18 |
etibor |
sounds not good |
| # |
May 29th 2021, 21:17 |
kevin.pfeifer |
the fact that cakephp2 just now is going EOL |
| # |
May 29th 2021, 21:17 |
kevin.pfeifer |
well |
| # |
May 29th 2021, 21:16 |
etibor |
do you think cake3 will be supported its longer? |