| # |
Sep 2nd 2019, 10:31 |
 neon1024 |
..as part of the save from Duplicatable |
| # |
Sep 2nd 2019, 10:31 |
neon1024 |
Perhaps I’ll leave it blank and see if the FootprintBehaviour will write it for me automagically |
| # |
Sep 2nd 2019, 10:30 |
neon1024 |
Maintaining the user_id code away from the duplication feels like it would lead to maintenance headaches |
| # |
Sep 2nd 2019, 10:30 |
neon1024 |
Then I have to write a beforeSave, away from my duplication config, and catch what is a save and what is a duplication |
| # |
Sep 2nd 2019, 10:29 |
challgren |
Which is actually good for me to figure out cause I’ll have the same issue coming up sounds like |
| # |
Sep 2nd 2019, 10:29 |
challgren |
So maybe raise it up |
| # |
Sep 2nd 2019, 10:28 |
challgren |
I know the footprint priority is -100 |
| # |
Sep 2nd 2019, 10:28 |
challgren |
instead it would be $options[‘_footprint’] |
| # |
Sep 2nd 2019, 10:28 |
neon1024 |
Perhaps Duplicatable does call save so might fire the beforeSave |
| # |
Sep 2nd 2019, 10:28 |
challgren |
If you want to get the user |
| # |
Sep 2nd 2019, 10:28 |
neon1024 |
I’m not using one |
| # |
Sep 2nd 2019, 10:28 |
challgren |
It would be in your beforeSave/beforeFind |
| # |
Sep 2nd 2019, 10:27 |
neon1024 |
I wanted `$this->_footprint->get('id')` or similar |
| # |
Sep 2nd 2019, 10:27 |
neon1024 |
I am using Duplicatable in the Table class, and need the current users id |
| # |
Sep 2nd 2019, 10:27 |
neon1024 |
> This plugin allows you to pass the currently logged in user to the model layer of a CakePHP 3 application. |
| # |
Sep 2nd 2019, 10:27 |
neon1024 |
Which kinda makes this false |
| # |
Sep 2nd 2019, 10:27 |
challgren |
Why? |
| # |
Sep 2nd 2019, 10:27 |
neon1024 |
Right, so it’s no good for what I need. That’s a shame |
| # |
Sep 2nd 2019, 10:26 |
challgren |
So yep when calling save it will inject the current user in the save `$options` |
| # |
Sep 2nd 2019, 10:25 |
challgren |
Well and figuring out how it does it |
| # |
Sep 2nd 2019, 10:25 |
challgren |
Yep |
| # |
Sep 2nd 2019, 10:25 |
neon1024 |
Are you searching the plugin for `_footprint` ? ;) |
| # |
Sep 2nd 2019, 10:24 |
challgren |
https://github.com/UseMuffin/Footprint/blob/master/src/Model/Behavior/FootprintBehavior.php#L29 |
| # |
Sep 2nd 2019, 10:23 |
challgren |
https://github.com/UseMuffin/Footprint/blob/master/src/Event/FootprintListener.php#L82 |
| # |
Sep 2nd 2019, 10:22 |
challgren |
https://github.com/UseMuffin/Footprint/blob/master/src/Event/FootprintListener.php#L25 |
| # |
Sep 2nd 2019, 10:22 |
neon1024 |
I’ll check the behaviour as that must use it to populate the created_by field |
| # |
Sep 2nd 2019, 10:21 |
challgren |
maybe `$table->save($entity, ['_footprint' => $options']);` |
| # |
Sep 2nd 2019, 10:20 |
neon1024 |
No mention of which `$options` or where |
| # |
Sep 2nd 2019, 10:20 |
neon1024 |
> in the _footprint key of $options |
| # |
Sep 2nd 2019, 10:20 |
neon1024 |
As it says |
| # |
Sep 2nd 2019, 10:20 |
challgren |
Its in the FootprintAwareTrait I recall |
| # |
Sep 2nd 2019, 10:19 |
neon1024 |
Is it this? `$this->request->getAttribute('identity')` |
| # |
Sep 2nd 2019, 10:19 |
neon1024 |
Bit of a stupid question, but the usemuffin/footprint readme, doesn’t tell me how to get the user data in the model |
| # |
Sep 2nd 2019, 10:15 |
neon1024 |
Easier to test with a concrete method implementation too :slightly_smiling_face: |
| # |
Sep 2nd 2019, 10:08 |
dereuromark |
Jep, this is another reason why actual methods on the entity can make sense if you always want to call it manually :slightly_smiling_face: in that case the methods dont have a prefix `_get` |
| # |
Sep 2nd 2019, 10:06 |
neon1024 |
Uses the magic method `__call()` I’d guess |
| # |
Sep 2nd 2019, 10:00 |
mehov |
wow so unless I call `$entity->some_calculation`, `_getSomeCalculation()` won't be executed? how is that done on underlying PHP level? not asking you to explain much, just what to google |
| # |
Sep 2nd 2019, 09:53 |
dereuromark |
Yeah, I am for basic stuff only, for those and other reasons. Everything else move out of such a basic DTO kind of structure :slightly_smiling_face: |
| # |
Sep 2nd 2019, 09:53 |
dereuromark |
and as long as you dont expose them - as I wrote about - then toArray() etc also wouldnt call them either. |
| # |
Sep 2nd 2019, 09:53 |
dereuromark |
only calculated if called :slightly_smiling_face: |
| # |
Sep 2nd 2019, 09:45 |
slackebot2 |
agree it's not as elegant as building on top of existing virtual fields functionality, I won't have it run everywhere even if I don't need it, unless I explicitly need it. Is there any way to control where shouldn't the virtual fields be calculated? Or should I keep some complex calculation (if any) still in my custom methods, and move only basic stuff to virtual fields (like full name concatenation from the cookbook)? |