| # |
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. |
| # |
Apr 11th 2019, 11:03 |
neon1024 |
Also, I mean, the maintenance headache on that would be huge |
| # |
Apr 11th 2019, 11:03 |
neon1024 |
There is a magic getter already though `$entity->get()` |
| # |
Apr 11th 2019, 11:02 |
dereuromark |
aka fighting the system |
| # |
Apr 11th 2019, 11:02 |
dereuromark |
manual work for no reason :) |
| # |
Apr 11th 2019, 10:58 |
conehead |
Was just wondering. Is there any downside to create getters for every property in every Entity. I somehow dislike accessing the properties directly |
| # |
Apr 11th 2019, 10:52 |
conehead |
:wave: Good mornin |
| # |
Apr 11th 2019, 10:48 |
neon1024 |
Morning all |