| # |
Sep 2nd 2019, 09:12 |
 conehead |
@mehov well you could do it without a wrapper class at all |
| # |
Sep 2nd 2019, 09:12 |
blancessanchez30 |
@dereuromark thank you, I'll change my approach to that. :thumbsup: |
| # |
Sep 2nd 2019, 09:11 |
dereuromark |
@blancessanchez30 Dont think of controllers then, but of URL string subset (e.g. /foo/bar/....) |
| # |
Sep 2nd 2019, 09:10 |
conehead |
Potentially it will probably cause an (unrecognizable) overhead, but will imho increase readability and seperation a lot |
| # |
Sep 2nd 2019, 09:08 |
challgren |
@mehov excluding the entity and doing more `$wrapperClass->calculateWhatever($entity->created);` is more portable |
| # |
Sep 2nd 2019, 09:06 |
mehov |
Actually that's more or less what I thought. Say there's an Entity, and the method needs to be use with it only and nowhere else. Then I'm choosing between `$entity->calculateWhatever()` on one hand and `$wrapperClass = new \Some\Class(); $result = $wrapperClass->calculateWhatever($entity);` Having this in the entity seemed more lightweight to me I may have gotten it wrong though |
| # |
Sep 2nd 2019, 09:06 |
blancessanchez30 |
@dereuromark I want to set a specific `max_input_vars` on a certain controller. I only need this in one controller, so applying it to all might be too much.. :thinking_face: |
| # |
Sep 2nd 2019, 09:04 |
dereuromark |
@blancessanchez30 Not really, why you need this? This is too early to know about specific routing patterns yet. |
| # |
Sep 2nd 2019, 09:03 |
challgren |
And speaking to that wouldn’t instantiation of another class cause more overhead potentially, yes its a very small class but theres already an instance of the Entity |
| # |
Sep 2nd 2019, 09:03 |
blancessanchez30 |
^ CakePHP 3 |
| # |
Sep 2nd 2019, 09:03 |
blancessanchez30 |
Good afternoon. How do you check in htaccess file if your in a specific controller? Is this possible? |
| # |
Sep 2nd 2019, 09:00 |
conehead |
I wouldn't say more. But I think it is a matter of responsibility |
| # |
Sep 2nd 2019, 09:00 |
dereuromark |
Entities already have a very high cyclic complexity. It only increases with these things. And often those are only needed in a small subset of places. It is a certain architectural choice one has to make sometimes. Where to put things. |
| # |
Sep 2nd 2019, 08:58 |
challgren |
If not more |
| # |
Sep 2nd 2019, 08:58 |
challgren |
@conehead wouldn’t making a business class take just the same effort for testing? |
| # |
Sep 2nd 2019, 08:56 |
conehead |
No if the logic is in the entity. Whenever you create a new DateTime (or similar) you would have to extract that to an additional method to mock it |
| # |
Sep 2nd 2019, 08:55 |
mehov |
@conehead harder to test which classes, the business class ones? |
| # |
Sep 2nd 2019, 08:54 |
conehead |
Additionally it will be "harder" to test those classes |
| # |
Sep 2nd 2019, 08:54 |
challgren |
I put that stuff in `src/Utils` |
| # |
Sep 2nd 2019, 08:54 |
mehov |
Got it, where should I put that class then? |
| # |
Sep 2nd 2019, 08:53 |
dereuromark |
Good point: You have to be careful to not overbloat the entities. If it becomes too much logic/calculation, then having a business class as wrapper is maybe the better choice. |
| # |
Sep 2nd 2019, 08:53 |
conehead |
imho it would not be nice to put such logic into the entities. I would prefer a method that calculates the diff from the created date and then you would just pass a new DateTime to it |
| # |
Sep 2nd 2019, 08:53 |
dereuromark |
Also see https://www.dereuromark.de/2019/02/05/virtual-entity-fields-in-cakephp/ :slightly_smiling_face: |
| # |
Sep 2nd 2019, 08:52 |
dereuromark |
read about virtual fields :slightly_smiling_face: in docs. |
| # |
Sep 2nd 2019, 08:52 |
slackebot2 |
return ($duration->days*24*60)+$duration->i; } ``` |
| # |
Sep 2nd 2019, 08:52 |
slackebot2 |
$this->getDateTimeCreated(); $now = new \DateTimeImmutable('now'); if ($created > $now) { // the session hasn't started yet return null; } $ended = $this->getDateTimeEnded(); return $created->diff($ended?$ended:$now); } public function getDurationMinutes() { $duration = $this->getDuration(); if (empty($duration)) { return 0; } |
| # |
Sep 2nd 2019, 08:52 |
mehov |
Okay sorry I used `created` as an example, in my case it's ``` public function getDateTimeCreated() { return new \DateTimeImmutable($this->created->format('r')); } public function getDateTimeEnded() { if (empty($this->ended)) { return null; } return new \DateTimeImmutable($this->ended->format('r')); } public function getDuration() { $created = |
| # |
Sep 2nd 2019, 08:52 |
dereuromark |
I also have traits in place that expose the properties via methods, for a cleaner API where needed. |
| # |
Sep 2nd 2019, 08:52 |
dereuromark |
But I also sometimes add real methods. Mostly static ones though, to have some entitiy specific enum etc. |
| # |
Sep 2nd 2019, 08:51 |
dereuromark |
@mehov If you want it to be consistent with properties, you can use a _getAgeInDays() which then translates to a ->age_in_days property automatically :slightly_smiling_face: |
| # |
Sep 2nd 2019, 08:51 |
challgren |
You can do what ever you want with your virtual fields |
| # |
Sep 2nd 2019, 08:50 |
mehov |
`created` is an actual field holding DATETIME according to conventions. Or did i misunderstand you? |
| # |
Sep 2nd 2019, 08:49 |
challgren |
That would be a virtual field |
| # |
Sep 2nd 2019, 08:49 |
mehov |
Is there some info on what code you can and cannot put into entities? The doc at https://book.cakephp.org/3.0/en/orm/entities.html simply says *Entities contain methods to manipulate and access the data they contain* Say `Entity\Article.php` has a field `created`, is it okay to add `Entity\Article::getAgeInDays()` that'd only use the field to return how many days ago it was created? |
| # |
Sep 2nd 2019, 08:47 |
neon1024 |
Ah ok |
| # |
Sep 2nd 2019, 08:46 |
conehead |
At least at the moment it is not important for me as there aren't too many changes happening |
| # |
Sep 2nd 2019, 08:45 |
conehead |
Nope |
| # |
Sep 2nd 2019, 08:45 |
neon1024 |
@conehead Did you implement Elasticsearch as a datastore? |
| # |
Sep 2nd 2019, 08:45 |
neon1024 |
I need full audit trail too, so will probably implement the plugin |
| # |
Sep 2nd 2019, 08:44 |
neon1024 |
Didn’t really think about audit/activity feed having a crossover, but you’re totally right |
| # |
Sep 2nd 2019, 08:44 |
conehead |
There I got one table with the updated entities, the user that changed it and what action was performed |