| # |
Apr 9th 2019, 10:46 |
 neon1024 |
4.0 is just removing the deprecated parts of the 3.x api |
| # |
Apr 9th 2019, 10:41 |
neothermic |
and if 3.x to 4.x is not complicated. then we might be able to do that as well at the same time |
| # |
Apr 9th 2019, 10:40 |
neothermic |
also when 4.x drops we'll have to do the 3.x migration, or sit with no support |
| # |
Apr 9th 2019, 10:40 |
neothermic |
we've gotten there on some parts of the platform! just not the main part |
| # |
Apr 9th 2019, 10:39 |
neothermic |
well, first we need to get to PHP 7.2 everywhere |
| # |
Apr 9th 2019, 10:39 |
neothermic |
haha |
| # |
Apr 9th 2019, 10:36 |
neon1024 |
What do you care? You’ll be going from 2.x to 5.x at this rate! :P |
| # |
Apr 9th 2019, 10:34 |
neothermic |
(but seriously, 7.2) |
| # |
Apr 9th 2019, 10:33 |
neothermic |
5.5 it is! ; |
| # |
Apr 9th 2019, 10:33 |
neothermic |
well, that was an easy vote |
| # |
Apr 9th 2019, 10:33 |
neon1024 |
Pinned ADmad’s message |
| # |
Apr 9th 2019, 10:32 |
neon1024 |
@neothermic Cast your vote now! :speech_balloon: :point_right: https://github.com/cakephp/cakephp/issues/13103 |
| # |
Apr 9th 2019, 10:25 |
megan |
:awesome: |
| # |
Apr 9th 2019, 10:21 |
neothermic |
what version they be targeting? |
| # |
Apr 9th 2019, 10:17 |
neon1024 |
@megan Can we board the hype train? |
| # |
Apr 9th 2019, 10:17 |
neon1024 |
If the vote for the minimum PHP version for 4.0 is up, does that mean release will be soon (next few months) |
| # |
Apr 9th 2019, 10:17 |
neon1024 |
Soooo |
| # |
Apr 9th 2019, 09:56 |
rogerpro |
They need to be exposed manually but yes, hope to forget Cake 2 soon. |
| # |
Apr 9th 2019, 09:52 |
neon1024 |
Ah Cake 2, was going to say, they work great in Cake 3 |
| # |
Apr 9th 2019, 09:50 |
rogerpro |
Virtual fields not working from a table in `contains` is a feature, not a bug, right? I think I forgot that they only work when in the model the find() is called from (in Cake 2) |
| # |
Apr 9th 2019, 09:31 |
spriz |
Ah yeah, I see. This would not be used in any templates right now - but suddenly this will creep into our codebase in the future I guess :slightly_smiling_face: |
| # |
Apr 9th 2019, 09:30 |
dereuromark |
10 years of success story with this invention of mine in 2009 :P |
| # |
Apr 9th 2019, 09:30 |
dereuromark |
inside the form template you can then just do $entity::types($entity->type) which is super nice, no use statement inclusion needed. |
| # |
Apr 9th 2019, 09:29 |
dereuromark |
well, https://github.com/dereuromark/cakephp-tools/blob/master/src/Model/Entity/Entity.php is my base entity for everything, as such reordering and filtering is possible more easily than with any other way. |
| # |
Apr 9th 2019, 09:29 |
spriz |
Although I did put those constants in the table - but I agree it might make more sense on the entity |
| # |
Apr 9th 2019, 09:28 |
spriz |
I actually drafted exactly what’s in your post, and did not really see benefit of adding the plugin so I think I’ll just stick with that ) |
| # |
Apr 9th 2019, 09:26 |
dereuromark |
well, I like the entity based system best. but sure, you can also look into those ways of doing it. |
| # |
Apr 9th 2019, 09:25 |
spriz |
I was wondering if we should just jump into https://github.com/CakeDC/Enum with the to make sure we don’t recreate magic - but we’d use “Const Configuration” so I’ll have to check what benefit that plugin adds :slightly_smiling_face: |
| # |
Apr 9th 2019, 09:25 |
dereuromark |
=> https://www.dereuromark.de/2010/06/24/static-enums-or-semihardcoded-attributes/ => for 3.x (incl bake template support and stuff possible) |
| # |
Apr 9th 2019, 09:25 |
dereuromark |
they can still be translated, and you can always use subsets in forms (e.g. user vs admin backend) |
| # |
Apr 9th 2019, 09:24 |
spriz |
@dereuromark what do you mean by semi-static? ,:( |
| # |
Apr 9th 2019, 09:23 |
spriz |
It is - it’s our “own” SAAS with single db and single app :slightly_smiling_face: |
| # |
Apr 9th 2019, 09:23 |
dereuromark |
if hardcoding in code is an option at least. |
| # |
Apr 9th 2019, 09:23 |
spriz |
Yeah, I’ll try it out with wiuthout the type table just to see if it’s worth the increased complexity - it’s not like we’ll add types every month from some UI anyway. In the past we’ve always made `_type` tables but we’ve never really added anything in those without also changing code anyway for this new type :P |
| # |
Apr 9th 2019, 09:23 |
rogerpro |
I’m more about normalizing in tables |
| # |
Apr 9th 2019, 09:23 |
dereuromark |
spriz: I use semi-static enums in these cases :slightly_smiling_face: The perfect mixture of easy to change, super-fast and lightweight. |
| # |
Apr 9th 2019, 09:22 |
neon1024 |
I sometimes set static config maps using `Configure::write()` |
| # |
Apr 9th 2019, 09:22 |
rogerpro |
with `id`, `source_product_id`, related_product_id`, `related_product_type_id`, `created`, `modified`, `deleted` |
| # |
Apr 9th 2019, 09:22 |
neon1024 |
Or set a const |
| # |
Apr 9th 2019, 09:22 |
spriz |
I’m actually thinking of just using a enum/string rather than creating another type table :slightly_smiling_face: |
| # |
Apr 9th 2019, 09:22 |
neon1024 |
I mean you could use an ENUM type thing, but normalising the association is probably better |