@
Barryvdh Ik wil hiervan ID's gaan bijhouden, maar misschien uiteindelijk eindigen als dit:
code:
1
2
3
| [{
['id' => 1, 'viewed_on' => *date*, 'duration' => *int* ..]
}] |
Je kunt het zo gek niet verzinnen. Dat is ook wat zo leuk is aan JSON, je kan er alles mee en ik hoef geen tabellen te verzinnen. En als het er niet is, dan is het er niet.
@
Stemis Met casting is het gelukkig ook eenvoudiger geworden:
code:
1
2
3
4
5
6
7
8
9
| class User extends Authenticatable
{
/**
* @var array
*/
protected $casts = [
'preferences' => 'array',
];
} |
JSON wordt dan automatisch omgezet naar array en vervolgens geserialized in de database.
Ik denk dat je dan het extra package niet meer nodig zou hebben.
Voor je laatste oplossing, was ik aan het denken aan een trait:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
| <?php
namespace App\Support;
trait JsonSerialize
{
/**
* @param string $key
* @param mixed $value
* @param string $column
*
* @return array
*/
public function setJsonData(string $key, $value, string $column = 'metadata'): array
{
$metadata = $this->{$column}; // prevent overload error
return data_set($metadata, $key, $value);
}
/**
* @param string $key
* @param null|mixed $default
* @param string $column
*
* @return array
*/
public function getJsonData(string $key, $default = null, string $column = 'metadata'): array
{
return data_get($this->{$column}, $key, $default);
}
} |
Mogelijk dat ze daar in de toekomst nog verder op gaan inspelen.
Dat vind ik overigens wel soms het probleem met Laravel, dingen veranderen snel en de documentatie is niet altijd duidelijk.
Ben ik de enige die soms dingen mist of gegeven voorbeelden niet direct begrijp?
@
Anoniem: 419552 Normalizeren is onzin.

NoSql is zeker een hype, maar ik zie opzicht wel nut hiervan.
Ik hoef nu niet allemaal tabellen aan te maken, kan gewoon de ID's hierin stoppen en kan het indien gewenst ook nog per item bijwerken.
Het LoginEvent was inderdaad niet zo netjes, dat heeft natuurlijk hier niets mee te maken.
Nu heb ik toch nog een vraagje:
Bij Events wordt er gesproken in het verleden (v.b. Shipped), maar vervolgens doe je toch allemaal tegenwoordige acties:
- SendNotification/SendEmail
- SendTrackAndTrace
Is het een regel? Want stel ik doe het volgende:
code:
1
2
3
4
5
6
7
8
9
10
11
| /**
* @param Product $product
*
* @return Response
*/
public function show(Product $product)
{
event(new ProductWasViewed($product));
return view('..');
} |
Dan komt de view pas erna en is het dus nog niet bekeken.

Kan je dit bijvoorbeeld oplossen via
subscribers?
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
| <?php
namespace App\Listeners;
class ProductEventSubscriber
{
public function onShow($event) {
dd($event); // geen response, was geregistreerd als listener
}
public function subscribe($events)
{
$events->listen(
'product.show',
'App\Listeners\ProductEventSubscriber@onShow'
);
}
} |
Dit deed helaas niks bij mij - of begrijp ik de logica hiervan verkeerd?
[
Voor 17% gewijzigd door
HollowGamer op 14-02-2018 10:44
]