Il existe des implémentations pour History.back dans Micrososft Ajax et JQuery ( http: //www.asual .com / jQuery / adresse / ). J'ai déjà JQuery et ASP.NET AJAX inclus dans mon projet, mais je ne suis pas sûr de la mise en œuvre de l'histoire.back.
Mieux pour moi est:
Quelqu'un sait-il lequel est le meilleur?
EDIT:
Un autre plugin JQuery est http://plugins.jquery.com/project/history Il est recommandé dans le livre de recettes JQuery. Celui-ci a bien fonctionné jusqu'à présent.
4 Réponses :
Une alternative à adresse jQuery est la belle jQuery Historique Plugin. Il existe également URL Utils . < / p>
Référence: Histoire et signets Ajax .
J'ai aimé la screencast "Histoire Ajax et Signets". Il utilise des utils d'URL qui sont superposés par JQuery BBQ, mais c'est toujours un très bon point de départ.
Voici un article décent avec des liens vers jquery.pager.js, microtempates.js et jquery.ba-bbq.js Stephenwalther.com/blog/archive/2010/04/08/...
L'adresse de JQuery ne fonctionne pas avec la nouvelle version de JQuery. Voir ma réponse ci-dessous.
Si vous construisez une application ASP.NET, l'utilisation de ASP.NET AJAX Framework vous donne de nombreux avantages et une API agréable à utiliser le côté serveur.
ci-dessous Vous trouverez un exemple qui utilise l'historique du navigateur avec ASP.NET AJAX
Les deux ont un large support de plage dans les navigateurs.
Pour moi, il est plus facile d'intégrer Microsoft Ajax framework dans une page ASP.NET à nouveau à nouveau si vous avez une page .ASPX IT
Si vous n'avez pas besoin exactement d'Ajax, c'est-à-dire que la mise à jour que des parties du site sur demande est suffisante pour vous, vous pouvez utiliser Invisible Exemple, mais pas dans ASP: kociszkowo.pl (site polonais)
Lorsque vous cliquez sur là dans l'icône de la section et que votre navigateur prend en charge JavaScript, le lien est modifié avant d'être récupéré - la cible est modifiée en iframe et HREF est suffixé avec .DHTML pour informer le serveur, que nous sommes intéressés par une version spéciale de la page. Si vous appuyez sur la page de votre navigateur JS-équipé, la page IFrame précédemment récupérée est chargée du cache. Simple, mais nécessite des décisions au niveau architectural.
Cette modification de liaison n'est pas pertinente ici, c'est juste le résultat de la combinaison du monde JS / Non-JS. iframe comme cible pour le chargement du fichier HTML généré contenant uniquement un script JS qui met à jour / réinitialise les parties "mise à jour" du site. C'est une solution de navigateur croisée et n'a pas besoin de vote d'adresse.
Dans mon expérience, votre meilleur pari utilise la même chose que vous avez la plupart (sinon toutes) de vos appels Ajax. Par exemple, si vous utilisez ASP: UpdatePanel's, utilisez la MS One - si vous utilisez jQuery.ajax, utilisez le plug-in JQuery History. Si vous faites un mélange (ce que j'ai essayé d'éviter dans mes projets), j'étiendrai personnellement tester avec les deux et voir ce qui se comporte mieux - s'ils testent tous les deux bien, alors c'est un peu de préférence. Certains peuvent discuter que Microsoft One aurait un meilleur support, mais le plug-in Histoire de JQuery peut être plus utilisé et plus mature.
http://msdn.microsoft.com /en-us/library/system.web.ui.updatepanel.aspx
Dépend de ce que vous entendez par un support de navigateur large ainsi que par qui utilisera l'application. Si sa communauté est diversifiée utilisant de nombreux navigateurs différents, je dirais le numéro 1, car le fonctionnement est probablement la partie la plus importante de tout type de logiciel.
Je n'ai jamais mis en œuvre cette situation particulière, mais je roule avec JQuery chaque fois que possible et que je suis rarement déçu, surtout lorsque le "support de navigateur large" est nécessaire.