Besoin d'aide ?

Aide sur logique pour gérer les notifications database

  • Avatar de yagrasdemonde
    Membre depuis :
    01/02/2018
    Messages :
    3

    Bonjour à tous,

    Sur mon application, je suis en train de mettre en place les notifications selon les actions d'utilisateurs.

    Je suis en réflexion sur ce systeme mais j'avoue nager un peu et me tourne vers vous pour plein de suggestions.

    Alors l'idée que je souhaite mettre en place :

    Mettre en place un NotificationController qui gérera donc la mise en markAsRead, delete etc de facon a centraliser les methodes pour les notifications au meme endroit.

    La ou je seche c'est justement le lien de la notification, je souhaite passer donc par mon controleur NotificationController pour le marquer en lu, puis aller sur la page d'édition ou show correspondant à la notification.

    Comment feriez vous, quelle est la méthodologie à appliquer ?

    En vous remerciant

  • Avatar de bestmomo
    Membre depuis :
    07/04/2013
    Messages :
    1901

    Salut,

    Il n'y a pas de règle, il faut suivre sa propre logique sans vouloir être trop rigide. L'organisation du code doit être telle qu'il est facile à lire et à comprendre lorsqu'on le reprend au bout de quelques temps.

    J'utilise toujours un contrôleur NotificationController mais pour ce qui est de l'affichage de ces notifications en général ça passe par un contrôleur d'utilisateur ou d'administration. Ca dépend un peu du contexte de l'application...

  • Avatar de yagrasdemonde
    Membre depuis :
    01/02/2018
    Messages :
    3

    Salut bestmomo,

    Tout d'abord merci pour cette réponse, j'ai pu me poser un certain temps pour 'réfléchir' à ma logique pour la gestion de mes Notifications.
    Et ensuite un grand merci car tes différents tuto sur Laravel (https://laravel.sillo.org/) m'ont grandement aidé (et m'aident au quotidien) dans la prise en main de Laravel, et je dois dire que je suis conquis par ce Framework => tu as su me le faire découvrir et l'apprendre.

    Voila ce que j'applique comme logique, à titre d'information.

    (Je suis bien sûr preneur de tout commentaire.)

    J'ai créé un trait : NotificationTrait dans lequel je répertorie mes différentes actions que je souhaite pour la gestion des notifications.

    <?php
    namespace App\Traits;

    use Illuminate\Support\Facades\Input;
    use Carbon\Carbon;

    trait NotificationTrait
    {
    public function markasReadAll()
    {
    auth()->user()->unreadNotifications->markAsRead();
    return redirect()->back();
    }

    public function markasRead()
    {
    $notificationId = Input::get('id');
    $notification = auth()->user()->notifications()->findOrFail($notificationId);
    $notification->markAsRead();

    if(isset($notification->data['id'])){
    return redirect()->action(
    'PostController@edit', ['id' => $notification->data['id']]
    );
    }else{
    return redirect()->back();
    }
    }

    public function deleteNotification()
    {

    /Recupere la notification lue et ayant XX jours /
    $notification = auth()->user()->readNotifications()->get();
    foreach($notification as $n){
    if($n->read_at < Carbon::now()->subDays(1) ){
    $n->delete();
    }
    }

    }
    }
    ?>

    J'appelle ce trait dans un middleware ClearanceMiddleware qui gère l'accès aux différentes pages selon les roles attribués aux utilisateurs, en particulier la méthode deleteNotification() pour nettoyer la table notifications en supprimant les notifications lues ayant x jours.

    <?php
    namespace App\Http\Middleware;

    use Closure;
    use Illuminate\Support\Facades\Auth;

    use App\Traits\NotificationTrait;

    class ClearanceMiddleware {
    use NotificationTrait;

    public function handle($request, Closure $next) {
    //Supprime les vieilles notifications de la BDD
    $this->deleteNotification();

    if (Auth::user()->hasPermissionTo('SuperAdmin')) {
    return $next($request);
    }

    ...

    }
    ?>

    Et pour utiliser les méthodes markasReadAll() et markasRead() j'utilise un controlleur NotificationController ou j'importe le trait pour utiliser ces méthodes.

    <?php
    namespace App\Http\Controllers;

    use Illuminate\Http\Request;

    use Illuminate\Support\Facades\Input;

    use App\Traits\NotificationTrait;

    class NotificationController extends Controller
    {
    use NotificationTrait;

    }
    ?>

    De cette manière je concentre toutes les actions liées aux notifications dans le trait.
    Peut être y'a t'il une autre manière de procéder, car ça me fait quand meme bizarre que mon NotificationController soit vide et qu'il ne contienne que l'appel au trait. est ce tout de même une 'bonne' méthodologie ?

    Merci

  • Avatar de bestmomo
    Membre depuis :
    07/04/2013
    Messages :
    1901

    Salut,

    Conceptuellement un trait sert à faire du partage de code horizontal, entre classes indépendantes. Ici tu ne fais pas de partage puisque les deux classes qui utilisent le code ne se servent pas des même méthodes.

    Personnellement j'aurais créé un service de notification pour rassembler les fonctionnalités, appelé dans les deux classes (le middleware et le contrôleur). Du coup j'aurais deux méthodes dans le contrôleur pour les deux routes correspondantes et dans ces méthodes appel du service. Ainsi il y aurait un répartition claire des tâches entre le service et le contrôleur (réception requête et compostion d ela réponse).

  • Avatar de yagrasdemonde
    Membre depuis :
    01/02/2018
    Messages :
    3

    Merci bestmomo mais j'ai pas tout bien compris.
    Quand tu parles de créer un service de notification, tu parles d'un repository ?

  • Avatar de bestmomo
    Membre depuis :
    07/04/2013
    Messages :
    1901

    Non, pour toutes les fonctionnalités particulières je crée un dossier app/Services avec mes classes.

Vous ne pouvez pas répondre à ce sujet.