| # |
Apr 11th 2019, 14:11 |
 neothermic |
oh, the shim puts it back? |
| # |
Apr 11th 2019, 14:11 |
dereuromark |
problem solved |
| # |
Apr 11th 2019, 14:11 |
dereuromark |
or use the shim plugin :slightly_smiling_face: |
| # |
Apr 11th 2019, 14:10 |
neothermic |
that's painful. if saveField is gone from 3.0, I have 112 places to fix to migrate this codebase :P |
| # |
Apr 11th 2019, 13:38 |
conehead |
just seen the service layer plugin the first time. I really like the idea of having a service layer. Might try it out when I finished migrating! |
| # |
Apr 11th 2019, 13:28 |
ricksaccous |
you can do it! |
| # |
Apr 11th 2019, 13:20 |
admad |
time to dig the trenches |
| # |
Apr 11th 2019, 13:20 |
neon1024 |
Moral is wavering! |
| # |
Apr 11th 2019, 13:20 |
admad |
hah |
| # |
Apr 11th 2019, 13:20 |
neon1024 |
Day three! |
| # |
Apr 11th 2019, 13:20 |
neon1024 |
In that horrible zone where it works locally, the test suite passes, the dev versions of the consuming front-ends work, but prod is not happy |
| # |
Apr 11th 2019, 13:20 |
admad |
marching forward or retreating in the battle? :slightly_smiling_face: |
| # |
Apr 11th 2019, 13:19 |
neon1024 |
I’m battling with league/fractal at the moment |
| # |
Apr 11th 2019, 13:19 |
neon1024 |
Then there are the form resource bits I think |
| # |
Apr 11th 2019, 13:19 |
neon1024 |
Then everything in my fork is covered off in the plugin I think |
| # |
Apr 11th 2019, 13:18 |
neon1024 |
I’d like to get the pagination in ideally |
| # |
Apr 11th 2019, 13:18 |
admad |
you can now start working on cake 4 compatible v3 :P |
| # |
Apr 11th 2019, 13:18 |
admad |
@neon1024 2.0.0 tagged |
| # |
Apr 11th 2019, 13:13 |
dereuromark |
a propos ide autocomplete: @burzum, i have a small PR: https://github.com/burzum/cakephp-service-layer/pull/11 |
| # |
Apr 11th 2019, 13:12 |
neon1024 |
Oooh! :tada: |
| # |
Apr 11th 2019, 13:11 |
admad |
@neon1024 waiting for travis to give the green https://github.com/UseMuffin/Webservice/pull/85 |
| # |
Apr 11th 2019, 13:05 |
admad |
anything that can be easily achieved with a plugin doesn't need to be in core :slightly_smiling_face: |
| # |
Apr 11th 2019, 13:05 |
neon1024 |
Agreed, and it’s worth noting that because you think a feature is great, doesn’t mean it needs to be in the framework. You are not confined to the framework, you can add your own bits too! |
| # |
Apr 11th 2019, 13:03 |
admad |
and those annotations can be updated later on if you change table fields by using @dereuromark's IdeHelper plugin |
| # |
Apr 11th 2019, 13:02 |
admad |
https://github.com/cakephp/bake/blob/master/tests/comparisons/Model/testBakeEntitySimple.php#L9 |
| # |
Apr 11th 2019, 13:01 |
admad |
in case you haven't noticed baked entities do have annotations for the magic methods |
| # |
Apr 11th 2019, 13:00 |
admad |
framework can't always cater to everyone's preferences |
| # |
Apr 11th 2019, 12:59 |
admad |
still anyone who prefers magic methods can achieve it with their own entity class with a few lines of code |
| # |
Apr 11th 2019, 12:57 |
admad |
@val 1. it's a matter of perception 2. IDE autocompletion would be no different for magic methods vs magic props, both need annotations. Infact using getter method like you propose would mean typing extra 3 chars "get" each time before you start getting useful autocompletion 3. This is PHP not Java :slightly_smiling_face: |
| # |
Apr 11th 2019, 12:46 |
dereuromark |
Setting on properties is indeed not nice, thus I do not use this for the Dto plugin. Providing the actual methods via generated code is the smartest and best option if you know the fields. With entities and virtual fields or alike this is too tricky to do probably. thus the simple (magic) property way here. |
| # |
Apr 11th 2019, 12:39 |
val |
Of course, a plugin could be used or a custom implementation. But it would be nice to have such basic features in the framework. IMHO. |
| # |
Apr 11th 2019, 12:37 |
dereuromark |
Actually, properties have the same IDE typehinting as methods. At least for the getting part. |
| # |
Apr 11th 2019, 12:36 |
dereuromark |
Then use my Dto plugin :slightly_smiling_face: |
| # |
Apr 11th 2019, 12:30 |
slackebot3 |
properties directly. |
| # |
Apr 11th 2019, 12:30 |
val |
In my opinion that would allow to write cleaner code. `$this->my_property` gives an impression that a public property is accessed that is not encapsulated while `$this->getMyProperty()` gives an impression that the property is encapsulated in a good way. Also auto-completion in IDEs is easier with `getMyProperty()` than with `get()`. I think people who are used to strong typed languages like Java prefer getters like `getMyProperty()` than to use |
| # |
Apr 11th 2019, 12:00 |
admad |
there's already `->get('prop')` btw |
| # |
Apr 11th 2019, 11:59 |
admad |
@val what benefit would that provided? |
| # |
Apr 11th 2019, 11:50 |
val |
@berarma of course, but it would be nice to have that in the framework |
| # |
Apr 11th 2019, 11:38 |
conehead |
Not sure. It's a little bit about the autocompletion. When having the annotations it is just one Click with PHPStorm |
| # |
Apr 11th 2019, 11:37 |
berarma |
@val You could easily implement it in your own Entity class. All your entities should extend from it. |
| # |
Apr 11th 2019, 11:25 |
val |
It would be good to implement the magic `__call()` method so that `$this->getMyProperty()` would return the same result as `$this->my_property` IMHO. |