Vous n'êtes pas identifié(e).
Pages : 1
Salut Pierrot,
Si tu prends le zip https://github.com/pure/pure/archive/master.zip
Et que tu l'unzip, il y a un répertoire /tutorial
Il y a aussi une page /index.html que tu peux ouvrir avec quelques exemples.
Pour notre appli, il y a une IFRAME qui charge dynamiquement les pages HTML+JS+CSS.
Ça peut paraître bizarre, mais ça laisse alors au browser le travail de charger les pages(avec cache), interpréter le JS et CSS.
Ensuite les noeud DOM du template, un objet javascript et les style CSS sont collectés, et insérés dans la page principale.
Il me semble que de cette manière on profite du parallèlisme qu'offre le browser a charger/interpréter plusieurs resources en même temps.
Alors que par ajax on est limité par javascript à un seul thread.
Il y a un post sur le forum avec un exemple similaire à ce que nous utilisons encore aujourd'hui:
https://groups.google.com/forum/#!msg/P … -5fclrVcoJ
C'est finalement un choix. Tu peux garder une approche radicale qui respecte scrupuleusement le rôle des directives et du template.
Mais pour moi, un petit mix de temps en temps, c'est pas si grave, c'est simple et rapide.
Salut moijhd,
Dans le cas d'un SELECT/OPTION c'est difficile de faire autrement, si tu veux vraiment un tiret entre val et name.
Par contre dans d'autre cas, tu pourrais effectivement être plus clean, et avoir le tiret dans le template, p.ex:
<span class="val"></span> - <span class="name"></span>
Pour un attribut tu peux utiliser la notation + pour faire une concaténation avec l'existant.
Le template:
<div id="element_id_"></div>
Et la directive:
'div@id+': 'element.id'
Qui donnerait, p.ex:
<div id="element_id_2345"></div>
Jc,
Une page HTML statique ou PHP venant du serveur, offre le même degré de protection SOP(same origin policy).
Dans les deux cas, on peut ensuite appeler le même domaine par un appel AJAX.
Ou appeler un autre domaine par JSONP, et ce aux risques de l'utilisateur.
Le templating javascript n'intervient qu'après, quand le JSON est là.
Peu importe la manière utilisée.
Salut Jc,
L'avantage du rendu client est en général:
HTML vide + JSON < HTML Rempli par le server
En Kb qui voyagent et en process serveur.
Le navigateur qui d'habitude n'a pas grand chose à faire qu'attendre la réponse, fait le rendu.
Libérant ton server de ce travail.
Ajoutes à cela la gestion normale de la cache des fichiers statiques: HTML/JS et CSS, comme tu le dis, mais pas avancée.
Ce que tu ne peux pas faire sur des HTML dynamiques venant du sever.
Et tu as une architecture très performante, aussi bien au niveau réseau, usage du server que vitesse de rendu.
Pour info, je suis l'auteur de pure.js, que nous avons écrit pour notre appli SaaS.
Tu peux l'essayer pour te faire une idée de la vitesse. Tout le rendu se fait au client.
Le gros point qui reste en faveur du rendu server, c'est le SEO.
Même si Google permet les hash tags, c'est plus fastidieux.
moijhd, n'hésite pas à me contacter si tu as des questions sur pure.js!
Pages : 1