Smarty Vs. Javascript / AJAX

Question

j'ai un doute: - Existe-t-il une norme / convention que je devrais utiliser quand "Smarty templating"? et quand dois-je utiliser les appels Javascript Ajax pour produire le contenu? Je peux utiliser les appels Ajax / Javascript pour produire le contenu de manière dynamique.

Mon application utilise à la fois Ajax et Smarty , mais je souhaite définir une règle pour les développeurs

.

Answer 1

Vous devez utiliser les appels AJAX uniquement pour charger des données dynamiques inconnues au moment du chargement de la page . Par exemple, lorsque vous cliquez sur le lien "Commentaires". lien pour une question / réponse donnée sur Stack Overflow, un appel AJAX est effectué pour charger dynamiquement les données. Cela résulte du fait que l'utilisateur a cliqué sur le lien de commentaires et non du chargement de la page. Vous ne savez pas que vous devez afficher ces commentaires au moment du chargement de la page. Il est donc approprié de passer un appel AJAX dans ce cas.

Vous devez utiliser des modèles pour afficher les données connues au moment du chargement de la page . Il est plus facile de traiter avec des personnes dont le langage Javascript est désactivé (je sais, pas beaucoup) et qui sépare clairement la logique de la présentation. L’utilisation de modèles est un autre avantage important qui permet de réduire considérablement le nombre de requêtes HTTP émises par le navigateur du client.

Ceci est particulièrement important dans le monde de la navigation mobile où la latence, et non la bande passante, est votre principal obstacle. Dans Safari pour mobile, par exemple, une seule requête HTTP adressée à une page modèle Smarty se chargera beaucoup plus rapidement qu’une demande de chargement d’une page JavaScript contenant cinq ou six requêtes HTTP supplémentaires. Cela est particulièrement vrai lorsque vous utilisez EDGE, 3G et d'autres services de données mobiles non wifi. En fait, c’est tellement important que c’est la première indication de Meilleures pratiques pour accélérer votre site Web .

Idéalement, vous devez également dégrader gracieusement les fonctionnalités lorsque Javascript est désactivé . Un bon exemple est un champ de recherche à remplissage automatique. C’est vraiment bien d’avoir des termes de recherche suggérés comme par magie lors de la frappe, mais si vous désactivez Javascript, vous avez toujours un champ de recherche fonctionnel. C'est un exemple classique d'une bonne dégradation du service. Stack Overflow fait généralement un excellent travail en fournissant une solide expérience non-Javascript. Il y a un endroit qui manque, c'est dans les commentaires. Lorsque Javascript est désactivé, seuls les commentaires les plus populaires sont affichés et la publication de nouveaux commentaires est désactivée.

À moins que cela ne soit absolument nécessaire, vous devriez considérer le Javascript comme une fonctionnalité supplémentaire qui pourrait ne pas être activée, et non comme un élément à utiliser pour construire des éléments critiques de votre site Web . Il y a évidemment des exceptions (certaines choses ne peuvent tout simplement pas être faites sans Javascript). Vous remarquerez, par exemple, que Stack Overflow est très utilisable avec Javascript désactivé. Vous n'obtiendrez pas les mises à jour en temps réel lorsque de nouvelles réponses sont publiées, ni les aperçus de Markdown en temps réel, mais les fonctionnalités de base sont toujours là. Tous les & "; levage lourd" & est fait avec HTML et CSS. Javascript est juste une cerise sur le gâteau (certes très bonne cerise sur le gâteau). C’est un peu une note de côté, mais c’est assez important à mentionner.

Answer 2

Cela dépend probablement du type de travail que vous effectuez dans vos modèles. Personnellement, je déteste faire beaucoup de choses de style lourd / mise en page strictement en Javascript. Si vous pouvez charger le gros de votre mise en page via. Smarty et ne modifiez que des éléments de données spécifiques (uniquement les données , et non le balisage / style, si possible) qui pourraient constituer un bon point de départ pour la normalisation au sein de votre propre équipe de développeurs.

Answer 3

Utilisez des modèles pour la génération côté serveur et DHTML / AJAX pour tout ce qui suit le chargement de la page d'origine (sans actualisation). Même dans ce cas, la réponse du serveur pour l’appel AJAX lui-même peut être assemblée avec un modèle, ce qui convient mieux pour tout contenu non trivial.