| # |
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 |
| # |
Apr 10th 2019, 20:18 |
ricksaccous |
np |
| # |
Apr 10th 2019, 20:18 |
hollistergraham123 |
Good idea, I didn’t think to look if it accepted a second parameter. Thanks! |
| # |
Apr 10th 2019, 20:17 |
ricksaccous |
with the format you were feeding it? |
| # |
Apr 10th 2019, 20:17 |
ricksaccous |
did you try setting the formats array? |
| # |
Apr 10th 2019, 20:17 |
ricksaccous |
https://api.cakephp.org/3.4/class-Cake.Validation.Validator.html#_dateTime |
| # |
Apr 10th 2019, 20:16 |
hollistergraham123 |
And I did patch entity with that datetime value and got error invalid value |
| # |
Apr 10th 2019, 20:16 |
hollistergraham123 |
my validator is set as follows `$validator ->dateTime(‘reminder’) ->allowEmptyDate(‘reminder’);` |
| # |
Apr 10th 2019, 20:15 |
ricksaccous |
and cake can handle saving that into db i believe |
| # |
Apr 10th 2019, 20:14 |
ricksaccous |
@hollistergraham123... when you patch entity with request data it automatically gets turned into a FrozenTime object (I believe) |
| # |
Apr 10th 2019, 20:13 |
hollistergraham123 |
@dereuromark was that towards me that 3.7 supports isostring for datetime? |
| # |
Apr 10th 2019, 20:10 |
ricksaccous |
let me re-read the docs on it first lol |
| # |
Apr 10th 2019, 20:09 |
ricksaccous |
@dereuromark not sure if you're still around, but your queue plugin works great, was wondering if it had support for seeing history of job failure? I could probably just implement that myself i suppose |
| # |
Apr 10th 2019, 19:30 |
dereuromark |
shouldnt that be built in in 3.7? |
| # |
Apr 10th 2019, 18:32 |
hollistergraham123 |
Is there a way to get cake to accept 2019-04-10T22:21:00.504Z as a datetime value |
| # |
Apr 10th 2019, 16:25 |
tom082 |
I vardumped the get_defined_vars()s and the 2nd email has the first email defined somewhere so as always flipping cache |