| # |
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 |
| # |
Apr 10th 2019, 15:19 |
jeremyharris |
that’s very weird |
| # |
Apr 10th 2019, 15:16 |
tom082 |
Just happens in emails sent through the CLI shell |
| # |
Apr 10th 2019, 15:16 |
tom082 |
Nope vanilla as it gets |
| # |
Apr 10th 2019, 15:15 |
jeremyharris |
and no before/after render shenanigans happening in your views/helpers I’m guessing |
| # |
Apr 10th 2019, 15:15 |
jeremyharris |
if that reflects the exact setup you are actually using then I don’t see anything wrong. that’s very odd behavior indeed. do you see a similar issue outside of emails? For example if you have a regular template that loops through that array and uses that element, do you get different results? |
| # |
Apr 10th 2019, 15:11 |
tom082 |
https://gist.githubusercontent.com/vaultdweller40/4a02d28ec13bc794735a27aade5476e7/raw/d45b10281d4a6c6985f1a14c1665f3c110aacef8/gistfile1.txt |
| # |
Apr 10th 2019, 15:05 |
tom082 |
Sure one sec |
| # |
Apr 10th 2019, 15:02 |
jeremyharris |
can you gist your code for the the $email setting as well as the template/element? |
| # |
Apr 10th 2019, 15:00 |
tom082 |
both are passed to the template with $email->viewVars($copy); |