Cela semble être une petite phrase vague. S'il vous plaît datant s'il vous plaît. Maintenant···
Par exemple, il y a une page TOP sur un site d'achat ou quelque chose du genre, et il y a une partie de nouveaux articles, et la fréquence d'ajout de produits est élevée, et les clients exigent l'immédiateté, mais la page TOP inclut les nouveaux articles. Supposons qu'il ait été conçu pour être écrit fermement côté serveur avec un seul morceau de HTML. Si vous le faites, vous devrez recharger toute la page TOP pour recharger les nouveaux éléments, de sorte que vous puissiez soit recharger automatiquement la page entière avec JS, soit non, ce n'est pas le cas, alors faites-le Ajax. Ce sera une recharge partielle.
Il existe généralement deux méthodes de conception Ajax considérées ici.
En d'autres termes, le HTML est généré côté serveur. Plus précisément, du côté du serveur, cela ressemble à la suppression d'un modèle partiel pour les nouveaux éléments et à l'ajout d'une nouvelle route et d'un contrôleur :: method ().
En d'autres termes, le HTML est généré côté client. Plus précisément, côté client, il est judicieux d'intégrer le modèle de la partie Nouveaux éléments à l'aide de jQuery-template ou AngularJS, d'attribuer le JSON reçu par Ajax et de le rendre. Oh, nous allons également ajouter route et controller :: method ().
(Une troisième méthode hybride consiste à exporter le premier JSON dans le cadre de text / html, même si je ne l'ai jamais fait).
Maintenant, comparant les deux, Le premier en termes de ** facilité ** Ce dernier en termes de ** polyvalence de l'API **, Sont susceptibles d'être supérieurs les uns aux autres.
Je recommande ce dernier. C'est un beau design, et dans certains cas, cela peut être un tremplin pour proposer des API ouvertes (= créer de nouveaux emplois). Eh bien, c'est bien ...
Maintenant, si vous choisissez ce dernier au lieu du premier, en plus de jQuery et AngularJS Gonyo Gonyo, il y aura encore un problème. Le moteur de modèle fourni avec le cadre d'application côté serveur aura généralement une fonction de filtre et certains l'utiliseront, vous devrez donc le remplacer par une implémentation JS.
Par exemple, dans le contrôleur $datetime = '2014-03-13T12:34:56.888Z'; Dans le moteur de modèle, la valeur affectée comme
<?php echo date('Y année n mois d jour h:m', strtotime($datetime)); ?>
C'est un peu difficile si vous l'écrivez comme ça. Vous pouvez calculer la partie date (...) côté serveur et la passer en JSON, mais si vous le faites, la polyvalence en tant qu'API diminuera fortement.
https://github.com/kvz/phpjs C'est rapide car vous pouvez utiliser les puissantes fonctions de PHP dans JS avec la même interface. Si vous l'utilisez et le réécrivez dans JS, ce sera facile. Je suis heureux.
Au fait, il y a quelque chose de similaire dans Python Django. https://github.com/dryan/django-filters-js (Ruby n'a pas été trouvé ...)
C'est une approche sournoise, mais c'est une bonne option. Je pourrai peut-être rentrer tôt ce soir.
C'est tout!
C'est une publicité, mais cette entrée est également liée,
http://j.inthemaking.net/ J'ai essayé de le faire. Vous pouvez le voir sur votre PC, mais c'est pour les smartphones. Si cela ne vous dérange pas, je serais heureux si vous pouviez l'utiliser pour tuer le temps.
Recommended Posts