Dans Backbone.js, quel est l'équivalent de HttpResponseRedirect dans Django?
Dans un Backbone.View, je dois soumettre des données au serveur, puis rediriger l'utilisateur vers une autre vue. Comment cela marche-t-il? Dois-je utiliser un événement ou un routeur?
Merci!
Il est important de comprendre que Backbone n'est pas un serveur Web sans état , donc une "redirection" peut ressembler à ce que vous voulez, mais ce n'est probablement pas le cas. Si vous avez une expérience dans la création d'applications de bureau avec état, tirez parti de cette expérience et de la façon dont vous passeriez d'un écran à un autre. Si vous n'avez aucune expérience client de bureau, je vous recommande fortement de mettre une partie de cela à votre disposition, car une application Backbone est une application avec état, il se trouve qu'elle s'exécute dans un navigateur.
En supposant que vous ayez une certaine connaissance de l'application avec état, vous avez quelques options pour que cela fonctionne.
Une fois que votre appel au serveur est revenu, vous pouvez appeler la méthode navigate
de votre routeur: myRouter.navigate("/myRoute", true)
. Assurez-vous de passer l'argument true
comme deuxième paramètre. Ou, comme le suggère JasonOffutt, mettez à jour manuellement le fragment de hachage de l'URL et c'est en fait la même chose.
je n'aime pas ça , mais certaines personnes le sont.
Vous pouvez créer un objet très simple qui sait afficher la bonne vue à l'écran lorsque vous appelez une méthode. Par exemple, si vous devez afficher une vue appelée "WidgetView", créez un objet avec une méthode appelée showWidgetView
. Rendez l'objet avec cette méthode disponible n'importe où dans votre code en l'attachant à un espace de noms, en le passant à votre code en cours d'exécution ou à une autre technique. Lorsque votre appel au serveur revient, appelez la méthode showWidgetView
de l'objet et laissez-la afficher la vue suivante pour vous.
C'est fonctionnel, mais cela devient rapidement désordonné dans autre chose que de très petites applications. Je le fais dans de petites applications, cependant. Lorsque vous accédez à des applications larget, vous devez penser au flux de travail événementiel et aux architectures événementielles.
Après le retour de votre appel serveur, déclenchez un événement en utilisant quelque chose comme n agrégateur d'événements , en faisant savoir aux autres parties de votre système que quelque chose d'important vient de se produire. Ces autres parties du système peuvent alors déterminer ce qu'il faut faire en réponse, y compris le code d'appel qui remplace la vue actuelle par une nouvelle, met à jour la route des URL, etc.
Lorsque vous suivez le chemin de l'utilisation des événements, vous finirez par tomber sur un cluster de code qui ne semble pas convenir à n'importe où, bien. Il s'agit généralement de vos gestionnaires d'événements et est généralement le signe d'un objet/problème qui veut être encapsulé. La création d'objets de flux de travail de niveau supérieur dans Backbone est une bonne idée si vous utilisez une architecture pilotée par les événements.
Ces objets de workflow sont généralement chargés de lancer un workflow en mettant en place toutes les bonnes vues et modèles, puis contiennent des gestionnaires d'événements pour vos vues et/ou agrégateur d'événements. Les méthodes du gestionnaire d'événements vérifieront l'état de l'application via les arguments passés par la méthode ou en examinant un autre état et détermineront ce qui doit se produire ensuite. Ensuite, l'application changera à quoi elle doit ressembler, en fonction du nouvel état.
En outre, un objet de flux de travail est pas une construction dorsale . C'est quelque chose que vous construirez vous-même, en utilisant simplement du vieux JavaScript.
...
J'espère que cela pourra aider.
Voici l'approche que j'ai adoptée:
En supposant que vous ayez un routeur défini avec des itinéraires comme ceux-ci:
var MyRouter = Backbone.Router.extend({
routes: {
'first-route': 'first',
'second-route': 'second'
},
first: function() {
// render first view
},
second: function() {
// render second view
}
// ...
});
J'utilise généralement des balises et je définis l'attribut href sur le hachage vers lequel je veux rediriger:
<a href="#first">First</a>
Alternativement, si vous souhaitez "rediriger" depuis votre JavaScript, vous pouvez définir explicitement le hachage de l'emplacement:
window.location.hash = 'first';
Je ne suis pas sûr à 100% que ce dernier soit la "meilleure pratique", mais je l'ai vu faire dans un certain nombre de bons tutoriels.
// Éditer
Ainsi, après avoir relu votre question d'origine, vous pouvez `` rediriger '' après la synchronisation des appels depuis le serveur simplement en définissant le hachage de l'emplacement.