J'essaie de créer un package intelligent pour l'application Meteor fournissant des capacités de surveillance et d'autres outils basés sur les fonctionnalités du package SMART. Pour plus de détails, lisez cette question .
Dans tous les cas, j'essaie de comprendre le meilleur moyen de créer une interface administrative pour ce paquet, qui sera bien sûr elle-même courante dans Meteor. Idéalement, j'aimerais quelque chose de similaire à Observatoire , sauf sur une partie distincte du site que le paquet peut contrôler ( ou même sur un autre port.)
La manière dont les membres de l'observatoire ont abordé ce problème est assez ingénieux - ils ont juste une pop up div sur la page d'application principale qui fournit les informations nécessaires. C'est bien, mais pas la manière optimale de révéler l'interface sur une application, à mon avis. Le problème avec l'utilisation des itinéraires est que le populaire Meteor Router que tout le monde utilise ne prend pas en charge plus d'une" pile "de pages et de meilleurs routeurs de météore développés ( Tels que Chris Mather dans devshop 5 ) n'ont pas encore été libérés .
Quelqu'un peut-il suggérer une bonne approche pour lutter contre ce problème? Idéalement, mon colis serait tout simplement en mesure de rendre ses propres modèles d'administration sur une partie distincte du site tel que / admin .
6 Réponses :
Ce n'est pas si faisable en utilisant simplement le routeur météore et les aides de modèle:
Spécifiez vos itinéraires: p> disons que vous avez une disposition de 3 colonnes. Créez votre modèle comme celui-ci: P> Spécifiez les aides de votre modèle: P> Template.body.helpers({
LeftLayoutName: function() {
switch (Meteor.Router.page()) {
case 'foo':
return 'foo_left';
case 'admin':
return 'admin_left';
}
},
MiddleLayoutName: function() {
switch (Meteor.Router.page()) {
case 'foo':
return 'foo_middle';
case 'admin':
return 'admin_middle';
}
},
RightLayoutName: function() {
switch (Meteor.Router.page()) {
case 'foo':
return 'foo_right';
case 'admin':
return 'admin_right';
}
}
});
C'est assez maladroit, non? Tout d'abord, votre page principale et votre page d'administration doivent avoir la même mise en page. De plus, vous avez toutes ces déclarations logiques répétitives. Et si ma page d'administration a besoin d'une mise en page complètement différente?
Le panneau d'administration et l'application doivent être séparés. C'est la solution et comment cela devrait être. Mais le problème est que la façon dont ils vont partager et connecter la même base de données.
Meteor-Router a été remplaçable par fer-routeur.
J'ai eu une question similaire. Il y a un exemple moins enclenché de faire cela dans l'exemple du paquet de météore du routeur.
https://github.com/tmeasday/ Météor-routeur / arborescence / maître / exemples / App-avec-layout
J'espère que cela aide.
Meteor-Router a été remplaçable par fer-routeur.
IronRouter prend en charge plusieurs mises en page.
Le routeur de fer n'existait pas quand j'ai posté ma question. Et non, ce n'est pas: Github.com/eventedmind/iron-Router/issues/ 41
Mise à jour, 4 mois plus tard: Maintenant, le routeur de fer prend en charge plusieurs mises en page (version 0.6.0+)
Veuillez jeter un oeil à mon projet à GitHub. J'ai une solution pour cela. Ce n'est peut-être pas le meilleur, mais cela fonctionne jusqu'à présent.
<template name="site">
<h1>Hello World!</h1>
<link rel="stylesheet" href="/css/site.css">
</template>
Vous voudrez peut-être élaborer un peu avec ce que vous avez fait exactement.
HI & Merci d'observatoire de référencement! Vous avez complètement raison de dire que cela pourrait éventuellement avoir une bonne gestion et une surveillance séparément et, en fait, nous travaillons dans cette direction récemment, ce qui sera également une direction principale, l'objectif est de surveiller, d'analyser les journaux. et fournir des capacités de gestion dans le cloud. Il a déjà une fonctionnalité de base - Vérifiez-le ici: http://vega.observatoirejs.com/demo
BTW, la façon dont nous avons géré votre problème dans l'observatoire d'origine - il suffit de créer un itinéraire distinct dans des pages ou du routeur de fer, etc. Modèle d'observatoire (ou de votre panneau d'administration) là-bas - dans notre cas {{> logs_bootstrap}}. De cette façon, il sera complètement séparé de l'application principale. Mais le nuage est encore meilleur :)
@J_HO Cette solution exige que l'utilisateur utilise une certaine présentation et de routeur lorsque vous l'ajoutez d'un package intelligent, qui est icky.
Comme James Hatfield a souligné, le routeur de fer soutient désormais plusieurs mises en page. Pour ceux qui frappent ce fil maintenant, c'est le meilleur moyen de gérer le scénario de mise en page multiple.
Router.map ->
@route 'home',
layoutTemplate: 'homeLayout'
path: '/'
@route 'dashboard',
layoutTemplate: 'dashboardLayout'
Oui, c'est maintenant la voie à suivre.
Je pense que le Q de l'OP peut être appliqué à cela également (dont je ne trouve pas de réponse). S'il vous plaît corriger si nécessaire. Mon site Web a une zone publique vendant le service. La partie «Premium» est ce qui est accessible avec l'adhésion. 90% du codeBase est destiné à la fonctionnalité «Premium». Meteor Forfait tout le code approprié pour le client qui le télécharge. C'est bien si vous vous préparez à vous connecter et à utiliser la section premium, mais semble un gaspillage pour le client. Q: Comment séparer ces deux codesbases? Merci.
Je séparais effectivement les deux bases de code, admin n'est pas compilée dans l'application. Il existe comme une application distincte et j'utilise une instance partagée de MongoDB pour les données. Dans une situation en direct, vous réutiliseriez la chaîne de connexion Mongodb et la base de code administrateur et ses fonctions ne sont jamais compilées dans, aucune chance d'ingénierie inverse, ce qui n'est pas là.