Comment décider de développer un composant front-end ou back-end?
Alors que nous (deux volontaires) allons développer un composant avec certaines fonctionnalités reflétant (une partie des) processus en cours dans la fondation (à but non lucratif), je me demandais s'il y aurait une règle de base pour déterminer si on développe une partie ou tout le composant dans la partie front-end de Joomla ou dans le backend administratif?
S'il s'agissait d'un site Web public, la décision de développer des composants front-end par rapport aux composants finaux serait plus claire. On voudra probablement montrer des choses dans le front-end tout en gérant les données du front-end dans le back-end.
Mais il est fort probable que ce sera un site intranet au sein de la fondation. Là où normalement le back-end gérerait les choses pour le front-end, dans ce cas, il n'y a pas vraiment de site Web à gérer, mais il y a des processus au sein de la société (tournant principalement autour de personnes ou de contacts) à gérer.
Si ce n'était que mon choix, je serais probablement satisfait de créer les fonctionnalités dans le backend administratif uniquement, en utilisant le style par défaut. Cela ferait probablement gagner du temps.
Bien que ce soit peut-être la base voudrait plus d'une expérience de style personnalisé. Donc, dans ce cas, je devrais probablement choisir le front-end sur le back-end administratif? Ou développez le composant pour le front-end ainsi que pour le back-end.
Toujours, en ce qui concerne ma question - "Comment décider de développer un composant front-end ou back-end?" - Existe-t-il des avantages ou des inconvénients importants dans le choix du back-end administratif par rapport au front-end ou inversement?
Comment itoctopus a dit, chaque réponse sur ce sujet est susceptible d'être subjective.
Vous pouvez hautement personnaliser le comportement et l'apparence de votre extension dans le backend (Easyblog, Akeeba, etc.). Vous n'avez pas à tout faire avec les outils et limitations Joomla donnés. Vous pouvez même créer un modèle d’administrateur différent pour les comptes d’utilisateur emyployee.
IMHO je localiserais la plupart du code de mon composant dans la partie administration et appellerais simplement contrôleur, assistant, fichiers de modèle depuis le frontend si nécessaire. (Gardez à l'esprit la sécurité!) Je ne vois pas le besoin de dupliquer les fonctionnalités du backend dans le frontend. (Ne te répète pas.)
Par exemple, vous pouvez avoir la gestion des clients dans le backend et charger la même gestion dans le frontal pour une fonction de compte d'utilisateur, à l'exclusion de certaines fonctions administratives telles que "supprimer l'utilisateur" en vérifiant les droits d'accès à la LCA.
Une autre question est la facilité d'utilisation pour l'utilisateur final, est-ce qu'il/elle fait d'autres choses dans l'interface qui pourraient se rapporter à votre composant et si, est-il judicieux de le localiser dans la zone d'administration avec une interface utilisateur différente sans flux dans le look frontend?
Pour les solutions intranet, je fournirais des fonctionnalités utilisateur dans la zone frontale et utiliserais le backend uniquement pour gérer les aspects administratifs du composant/système. Par conséquent, il est plus facile de gérer la structure de menus (vous pouvez utiliser SEF-URL ici), les modules et les pages com_component comme une page de référence. Et il est plus facile d’étendre la messagerie frontale IMO avec de nouvelles fonctionnalités encore inconnues ou des extensions tierces.
C'est une question intéressante et toute réponse que vous obtiendrez sera probablement subjective. Personnellement, je voudrais aller avec le backend, parce que, IMHO, les tâches de gestion de contenu doivent être limitées au backend. Cela vous donnera un peu plus de flexibilité au cas où l'entreprise voudrait afficher des choses publiques sur le front-end (par exemple pour tous les employés de l'entreprise).
Si vous optez pour le client, vous limitez essentiellement vos options en cas de modification des exigences.