Comment le "verrouillage" du contenu est-il géré dans les composants personnalisés?
Le noyau par défaut de com_content a un système intégré qui, lorsqu'un article spécifique est modifié par un utilisateur, est "verrouillé", de sorte qu'aucun autre utilisateur ne peut le modifier en même temps. Si l'utilisateur ferme la fenêtre ou laisse la session expirer sans fermer correctement cet article (en cliquant sur "enregistrer" ou "annuler", par exemple), ce contenu est "coché" et une icône de verrou est affichée dans le fond à côté, qu’un superadmin devra déverrouiller.
Ma question est: comment cela est-il ajouté à un composant personnalisé qui possède ses propres tables de contenu? D'après ce que j'ai pu trouver, il me semble que tant que vous utilisez JTable pour manipuler ce contenu, il s'agit alors d'une fonctionnalité intégrée pour les méthodes de cette classe ... est-ce exact? Ou dois-je utiliser quelque chose d'autre comme JTableContent? Dois-je ajouter quelque chose aux tables utilisées pour stocker du contenu (des colonnes spécifiques)?
Vous avez raison, mais vous n'avez pas besoin de descendre à JTable si vous suivez la méthode Joomla et utilisez JControllerForm comme base de votre contrôleur de vue, par exemple.
class MycomponentControllerMycontent extends JControllerForm {}
et en utilisant JModelAdmin comme base pour vos composants Modèle par ex.
class MycomponentModelMycontent extends JModelAdmin {}
L’extension de JControllerForm vous donne une méthode intégrée edit() qui configure votre modèle et votre table, et vérifie l’accès à l’enregistrement en question et indique si la table prend en charge les extractions (par vérifier qu’une colonne checked_out existe). Si tel est le cas, il tente de checkout() enregistrer via le modèle.
En étendant JModelAdmin, vous héritez de ses méthodes getItem(), checkIn() et checkOut(). Comme mentionné précédemment, le modèle appelle checkout() ( dont il hérite de JModelForm) et s'assure qu'en plus de la colonne checked_out votre table en a aussi une qui s'appelle checked_out_time.
À ce stade, l'une des deux choses qui se passe si l'une ou l'autre de ces colonnes n'existe pas, JModelForm la simule et renvoie true (indiquant que le travail est terminé). Autrement, les utilisateurs actuels seront récupérés, puis la première tentative de vérification sera effectuée pour vérifier si elle a déjà été extraite par un autre utilisateur. À ce stade, si finalement appelle la mise en œuvre JTable de checkOut() (si vous ne l’avez pas remplacée par votre propre définition de table, qui dans J3 n’est généralement pas requise).
JTable effectue exactement les mêmes vérifications de colonne et, si tout est correct (c’est-à-dire qu’il a un ID valide), met à jour les colonnes checked_out et checked_out_time pour l’enregistrement en cours de modification.
En remarque, lorsque vous edit() un élément, getItem() est appelé, il charge l’enregistrement via un JTable (c’est-à-dire qu’il effectue un getTable() suivi de load($pk). (À ce stade, JTable déclenche également votre onBeforeLoad et onAfterLoad événements pour les plugins qui est Nice)
L'enregistrement est renvoyé dans votre version de JModelAdmin, qui le convertit en un objet de base stdClass (il s'agissait auparavant d'un JObject). Si l’enregistrement (maintenant l’objet) contient un params colonne/attribut, il le convertit en un objet JRegistry pour un accès facile.
Ainsi, vous obtenez gratuitement beaucoup de choses utiles en utilisant la méthode Joomla. :)
Vous avez raison dans vos hypothèses. Vous avez besoin de la table avec la logique associée pour accomplir ce que vous essayez de faire.
Alors que j'apprenais Joomla 3+, j'utilisais Component Creator pour créer un composant extrêmement simple avec une seule table et uniquement la fonctionnalité Joomla que je suis intéressé à apprendre. Le code généré est très bon et facile à suivre sans toutes les complexités des composants habituels installés.