Architecture d'un site web (ajax)

guillaumech · 15 Juin 2009

Bonjour à tous,

Voilà, j'ai une interrogation qui me trote dans la tête depuis longtemps. Aujourd'hui, on prône la séparation contenu/traitement/GUI(en général j'entend). Or l'ajax est tout à fait le bien venu pour ça. Cependant comment faire pour conserver un arbre de lien. j'explique :

Page type (GUI) <-------------------- Pages traitements <---------------Pages récupération données

Donc l'utilisateur ne changera pas de page, il restera sur la page "type", et les données viendront à lui après être traités, à chacune de ses actions. Alors j'utilise une petite astuce pour avoir des liens au changement de page, mais c'est moyen je trouve. Je prend des liens signets "#", donc l'url en haut change, mais ne vas pas chercher une autre page (qui n'existerait pas en tant que telle en plus), et si une personne utilise cette url pour entrer sur le site, je la "parse" à son entrée, et je redirige cette personne sur la page qui correspond .... Mais c'est lourd. Alors j'aimerai savoir comment font les autres sites qui utilisent de l'ajax, pour avoir de "vrais" liens, mais conserver l'avantage de l'ajax (soit appeller une page et afficher son contenu dans une partie de la page appellante). Celà pose aussi un problème de référencement du coup ....

Voilà, merci bien à toutes vos futures réponses.
Guich

guillaumech · 16 Juin 2009

Un sujet qui n'inspire pas grand monde

zeb · 17 Juin 2009

Bof, pas tellement :/

( :hello:

guich )

guillaumech · 17 Juin 2009

Lol, rooo

Bin mais comment font les sites posés sur cette archi ? Comme par exemple un site utilisant les jsp, comment fait t'il pour avoir des liens ? Liens externes, pour pouvoir atteindre les pages directement depuis l'extérieur. C'est quand même fou ça

Les nouvelles technologies oublies cette histoire de lien, et du coup de référencement ... hum :??:

( :hello:

zeb

)

maverick911 · 18 Juin 2009

Allez je me lance

guillaumech, ton approche d'AJAX n'est pas la bonne !

AJAX est une approche du développement web très puissante, mais qui ne doit pas être utilisée pour soutenir toute l'architecture d'un site web.
Un bon site internet doit pouvoir se passer de javascript et fonctionner quand même correctement, AJAX est un plus que tu peux utiliser pour perfectionner l'ergonomie, la réactivité, ajouter des fonctionnalités, ou réduire le traffic client/server en ne proposant que le rechargement de donnée essentielles dans certains cas de figure.

Pour schématiser, la construction d'un site web se présente ainsi :
- Etude des différentes pages / plan du site
- Identification des fonctionnalités pouvant-être gérées par AJAX (par exemple la validation d'un pseudo dès que l'utilisateur a entré son choix dans la textbox...)
- Construction du site (les pages)
- Ajout des fonctionnalités asynchrones

Il faut savoir que javascript est exécuté différemment en fonction des navigateurs, et que de ce fait plus tu mets de javascript, plus tu t'exposes à des prises de tête lors du développement.
A ce sujet, si tu souhaites barder ton site de javascript, je t'invite à te renseigner sur quelques API's dont tu ne pourras te passer (jQuery par exemple).

Quand aux jsp... je crois que tu confonds java et javascript.
Ce ne sont pas du tout (mais alors... pas du tout !) les mêmes langages.
Java est un langage de développement objet avec lequel il est possible de réaliser des sites web dynamiques, le java est alors exécuté par le serveur et génère des pages web qui sont envoyées au client. Celui-ci appelle donc des pages .jsp (jsp = Java Server Pages). Comme .php sur un site PHP, ou .aspx sur un site .NET / ASP.
Javascript est un langage exécuté exclusivement par le client !

Bon voila alors pour résumer :
- Tu choisis ta techno serveur (PHP, Java, .NET)
- Tu fais ton site normalement, avec des pages et tout
- Tu t'amuses à ajouter du javascript si tu veux pour améliorer ton site

guillaumech · 19 Juin 2009

Je comprend bien, mais où est alors la séparation contenu/contenant ? L'avantage que j'avais d'utiliser l'ajax, c'est d'avoir exclusivement mes données à part, ainsi que mes traitements, et mon contenant faisait QUE des appels à ces données. Et non unmélange contenant/contenu ... qui est entre nous très lourd à gérer lorsque le site est important. J'utilise bien entendu des framework adaptés maverick911 (prototype, scriptaculous ...). Se que je souhaite, c'est avoir un site très très facile à faire évoluer (ajout de contenu ... modification de traitement ...). Je ne souhaite pas aller chercher un bout de code au milieu d'une page de plus de 500 lignes, après avoir passé 20min à trouver LA page en question. Ma structure actuelle est une page "mère", qui fait appel à ces pages "fille", qui sont son contenu. Imaginon que je souhaite modifier la "structure" de mes pages, ajouter un bloc nbVisiteurs par exemple, sur mon architecture, je n'ai qu'a modifier une unique page. Alors après oui, il y a la solution "include" php, mais tout se complique lorsqu'on à jusqu'a 5 niveaux de sous dossier pour gérer les liens ... Il faut des fichiers (fichier que l'on inclu et qui comporte des liens sur d'autres pages) différents pour chaque niveau, sinon les liens ne sont plus valide, car il faut "remonter" à chaque fois (../../lien.php) ... Enfin que de complications je trouve.

Merci pour ta longue réponse.
Guich

guillaumech · 21 Juin 2009

Re

Je complète ma réponse, sa en fera parler peut être d'autres ...
J'ai utilisé l'architecture décrite plus haut pour me coller au modèle MVC. Est-ce mauvais ? L'ai-je mal mis en oeuvre ? :??:

maverick911 · 23 Juin 2009

guillaumech,

Le modèle MVC est un peu particulier en ce qui concerne les applications Web, c'est surtout un design pattern utilisé sur des applications de type client lourd, ou côté serveur pour des applications Web.

Pour répondre à tes besoins, tout dépendra de la technologie que tu utiliseras.
Si tu utilises du Java ou du .NET, les environnements de développement offrent des tas d'outils pour développer des architectures adaptées à des gros projets :
- Premièrement, le développement côté serveur se fait avec des langages full object (Java, C#, VB...) qui te permettront d'adopter n'importe quel pattern (MCV par exemple), séparer tes couches applicatives (données persistantes dans une base, objets contenant tes données en mémoire, couche contrôle, couche graphique...)
- Pour ajouter un composant à une page, le développement du composant en lui même peut se faire complètement à part, puis être intégré tel quel à une page par la suite (http://msdn.microsoft.com/en-us/library/26db8ysc.aspx)

Si ce n'est pas déjà fait, et si tu n'as pas de compétences en Java/.NET, je t'invite fortement à te documenter sur la conception Web avec ces technos.

En ce qui concerne le PHP, il est également possible de développer des architectures très puissantes, mais ça demande plus de rigueur et d'organisation étant donné qu'il n'existe pas de véritable environnement de développement.

Au final, c'est bien de vouloir développer une architecture par couches, mais toute l'intelligence de cette architecture doit se situer au niveau du serveur, la reposer sur AJAX n'est pas une bonne solution.

Je terminerai par quelques remarques à ta réponse :

où est alors la séparation contenu/contenant ?

Côté serveur :
- Données persistantes : dans une base ou un/des fichiers
- Couche applicative données : dans des classes spécifiques (Java Beans pour Java par exemple)
- Couche applicative contrôle : dans des classes de traitement
- Couche applicative UI : des contrôles graphiques intégrés à tes pages (UsersControls pour .NET par exemple)
Le client ne fait que recevoir des pages générées par le serveur (avec pourquoi pas du JS)
En pratique, ton site ne peut comprendre qu'une Master Page, le reste du site étant composé que de composants unitaires imbriqués (et faisant chacun l'objet d'un fichier bien sûr)

Je ne souhaite pas aller chercher un bout de code au milieu d'une page de plus de 500 lignes, après avoir passé 20min à trouver LA page en question

Architecture complexe ne veut pas forcément dire sac de noeuds, mais c'est un métier, et si ce n'est pas le tien tu vas au devant de grosses prises de têtes

t1cable:
En règle générale, si une classe fait plus de 200-300 lignes, c'est que quelque part (sauf exception/gros algorithme) il y a un problème d'architecture.
Après tout dépend de la manière dont ton code est organisé (architecture object, répartition en packages/répertoires, commentaires de code...)
Là encore les environnements de développement offrent des outils pour aider à la compréhention du code (génération de doc, réduction automatique de portions de code...)

Imaginon que je souhaite modifier la "structure" de mes pages, ajouter un bloc nbVisiteurs par exemple, sur mon architecture, je n'ai qu'a modifier une unique page.

En utilisant les UsersControls

Se que je souhaite, c'est avoir un site très très facile à faire évoluer (ajout de contenu ... modification de traitement ...)
Enfin que de complications je trouve.

Oui c'est complexe.
Et ça tombe bien parce que justement il existe des outils pour éviter cette complexité.
Cette dernière remarque me pousse à te conseiller l'utilisation d'un CMS. Si tu n'es pas familier avec ces outils, je t'invite à te documenter, il en existe pas mal de gratuits (Joomla par exemple).
Tout dépend de tes besoins, mais si tu souhaites un site :
- Peu coûteux
- Facile à maintenir
- Doté d'outils de gestion de contenu
- Proposant des interfaces d'administration (pour un client par exemple)
La solution CMS est toute adaptée.
Ceci dans la mesure où tu ne souhaites pas développer toi même une architecture bien sûr

guillaumech · 23 Juin 2009

Waou, que de longueur

Un grand merci premièrement. Alors voilà ma réponse, qui sera beaucoup plus concise :sol:

Pour les CMS, je connais, mais c'est complétement incompatible avec mon site. Et je me rend compte que je n'ai pas présenté le site en question ... donc ... c'est une plateforme d'échange pour météorologues, avec 20 à 25 personnes qui l'administrent au court du temps. Cette plateforme a pour but principal l'échange de données dans le domaine de la météo. Des prévisions sont donc réalisées, manuellement par l'équipe, automatiquement par des serveurs internes avec divers algorithmes tournant en continu. Le site est donc assez important, et il m'aurait été impossible de partir d'un existant tel qu'il soit, même de type CMS. Pour le .NET ou son concurent JAVA, je ne développe pas dessus, même si ceux-ci offrent d'impressionnantes possibilitées (que j'ai déjà pu apprécier lors d'ancien travaux). J'ai donc aujourd'hui décidé de produire un modèle interne basé sur le MVC, le voici dans les grandes lignes :
[fixed]
''''''''''''''''controleur ------------- > modèle
index.php'''''''''''^'''''''''''''' \--- > vue
''''|_______________|
[/fixed]

L'utilisiteur arrive en index, à chaque actions son controleur est appellé, celui-ci vérifie la configuration du moment, appelle le modèle passé en parametre, puis sa vue (avec des controleurs/modèles/vues générique si besoin). Couplé à de l'url rewriting, la plateforme est solide, et la séparation en couche bien présente.
Qu'en penses-tu ?

Merci
Guich

PS : désolé pour les ' dans le schéma, mais c'est assez complexe pour en réaliser un, vu que les espaces ne sont pas pris en compte

maverick911 · 23 Juin 2009

A vue de nez, je dirais que la complexité d'une telle application réside dans sa base de données.
Une base bien architecturée contiendra toutes les données entrées par l'équipe et les algorithmes.

Ton application sert à exploiter / visualiser / entrer ces données, elle doit donc être assez simple.
En quoi diffère-elle d'un site/application classique ?

Quand à ton architecture, je ne suis personnellement pas fan de l'index dictatorial par où tout doit passer.
On en arrive souvent à une master page hyper lourde, et à se prendre les pieds dans le tapis alors que c'est ce qu'on voulait éviter...
Ma manière de faire :
- Un index simplement chargé de vérifier si la page demandée est valide / réveiller la session...
- Chaque page a un rôle précis (visualisation d'articles / envoi d'email / page de discussion...)
- Chaque page est responsable de ses données, de ses traitements
- Les briques d'interface et fonctions récurrentes sont placés dans des fichiers (dans un répertoire inc par ex), et sont appelées dans les pages en temps voulu (par include)
- Les données persistantes (droits utilisateur par ex) sont stockées dans une session

Quand à l'url rewriting, pourquoi faire ? L'intérêt de l'url rewriting est d'améliorer l'indexation des pages par les moteurs de recherche... A moins que le référencement ait son importance...

En te lisant j'ai l'impression que tu souhaites absolument utiliser ce modèle MVC, c'est une de tes contraintes ?

guillaumech · 23 Juin 2009

On en arrive souvent à une master page hyper lourde, et à se prendre les pieds dans le tapis alors que c'est ce qu'on voulait éviter...
Chaque page est responsable de ses données, de ses traitements

C'est bien le cas ici ... arrivé en index, l'utilisateur va déclencher une action (soit un lien en général), ce lien pointe sur un controleur indépendant, et c'est bien tout là que réside la réponsabiblité propre à chaque page. A chaque action, un controleur est appellé, qui celui appellera sa/ses vue/s avec les données produites par son/ses modèles. Tu comprendras vite l'intérêt d'une telle architecture lorsque tu te verras demandé la réalisation d'un module par une personne tiers. En effet, cette personne, sous tes directives, ne touchera qu'a ses parties, soit une nouvelle vue s'il y en a besoin, sinon tu lui dirais d'utiliser la vue par défaut, idem pour le modèle. Il n'y aura pas de création de pages hors contexte, cette personne tiers ne fera qu'un simple bout de vue à l'intérieur de ton site, il ne touchera pas au reste, et ne réalisera que de petits appel ou traitement dans son modèle. Le controleur sera générique (pour tes sessions par exemple). Donc chaque page est responsable de ses traitements/données.

Ton application sert à exploiter / visualiser / entrer ces données, elle doit donc être assez simple.

Tu vois d'autres actions toi ? :heink: (traiter, récupérer, organiser, visualiser, inserer .... des données) Me je ne vois pas ...

J'utilise cette architecture car le site commence à être important, en nombre de pages, mais est également amenné à évoluer. Chaque évolution se font par ajout de modules, soit pour la prochaine évolution, l'ajout d'un module de soirée à thèmes sur la base de salons de discussions (réalisé ici en ajax).

Quand à l'url rewriting, pourquoi faire ?

L'intérêt est de rendre transparent l'architecture ... car j'ai des url du type

Vous devez être connecté pour voir les liens.

(tu comprendras donc tout seul l'utilité de la chose

)

Je n'ai pas d'obligation, vu que je suis "chef". Mais ce modèle me parait être assez puissant dans mon cas. Regarde sur la toile, le MVC est ainsi porté pour des sites web. (dans les grandes lignes)

maverick911 · 23 Juin 2009

Ok la sémantique près en fait on raconte à peu près la même chose

Va pour l'architecture, et désolé pour les digressions mais je découvre ton projet au fil de la discussion :sweat:

Mais pourquoi se reposer sur AJAX pour récupérer les pages ?
En fait tu as une master page (controleur.php dans ton exemple d'url) qui reçoit un ordre d'action et va chercher les bons modules en fonction de cette demande.
Je ne vois toujours pas l'utilité d'un mode asynchrone

Quand aux exemples sur le net, si tu en as à me montrer je suis preneur, ça me permettra sans doute de mieux cerner le problème.

guillaumech · 23 Juin 2009

Je laisse maintenant l'ajax, car je re-fait le site sour l'architecture décrite plus haut. Au début sa me permettait de ne pas à avoir à recharger chaque page, d'avoir une grande réactivité à l'utilisateur ... bref, tout les avantages, et ces appels n'allaient chercher QUE des données, et non des info de styles ... mais là n'est plus la question

(l'ajax pour le module de soirée à thème est indispensable)
Je n'ai pas de master page, mais une page générique à utilisé si besoin est, sinon à créer une autre version pour le problème posé. Les actions dites essentielles passent par cette page, les actions plus précises ont leurs propres controleurs. Ceci dis, ces actions sont casi inexistante si ta page générique est bien faite, car elle doit gérer les sessions utilisateurs, les droits, les connexions distantes, puis après vérification de l'existance du modèle et de la vue associés à l'action, les insérer. Les actions sont passées en var GET. Les fichiers utiles javascript sont eux aussi associés à l'action. Du coup, lors d'une demande d'une page par exemple de stats sur une base de données distante, ou même une lecture de flux RSS, la personne développant ceci fera sa vue, et son modèle qui traitera les données (base, RSS ...), pour les envoyer à sa vue après. Il utilisera le controleur générique, qui incluera vue/modèle en question. L'association action ---> modèle/vue/fichier js se fait avec un tableau associatif dans un fichier de configuration.

Pour les exemples il y a des choses sur le site du zero, sur developpez (mot clé, site web mvc)

maverick911 · 25 Juin 2009

Tu as pensé à aller voir du côté des frameworks PHP ?
Il en existe un : CakePHP qui utilise le pattern MVC auquel tu as l'air de tenir :
http://cakephp.org/

Vous devez être connecté pour voir les liens.

Un incontournable à mon avis, parce que si tu pars "from scratch" la pente sera savonneuse :sweat:

guillaumech · 29 Juin 2009

J'aurais l'avantage d'être propre :sol:
et qui plus est d'avoir conservé mon intimité en mettant lavé tout seul

(Un certain modérateur te le dira. Je préfère partir les mains dans le camboui, pour finir avec les mains manucurés, que me retouver les mains manucurés pleines de camboui)

maverick911 · 30 Juin 2009

Justement, en utilisant un framework tu t'évites bien des opérations fastidieuses (architecture, code, algos...) qui peuvent salir ton projet si tu n'as pas de pratique dessus. Le but étant de partir sur des bases réfléchies et de ne pas réinventer (bien ou mal) la poudre.

Ton projet ne s'en portera que mieux : plus propre, moins coûteux, et fonctionnel.
Tu t'évites en plus de nombreux tests unitaires puisque la base de ton projet a déjà été testée.
Partant de là rien ne t'empêche de mettre tes doigts dans la machine, de prototyper à ta sauce et d'adapter ce qui te sembles être le mieux dans le framework puisque tu disposes des sources.

Leur vision de l'architecture MVC est conforme à celle que tu souhaites mettre en oeuvre à une différence près : il n'existe pas de contrôleur général, mais un dispatcheur qui appelle le contrôleur spécifique à l'action demandée dans l'url (donc pas de différence entre actions essentielles / précises). -

Vous devez être connecté pour voir les liens.

guillaumech · 30 Juin 2009

Je préfère de loin le réaliser une fois tout seul. C'est beaucoup plus formateur. Après on verra

maverick911 · 30 Juin 2009

Ca me rappelle un projet de webmail full ajax.
Le bouzin était bardé de Javascript que j'avais codé avec mes blanches main car je ne voulais pas utiliser d'api et tout apprendre tout seul.
Le résultat : un webmail qui marche mal

Heureusement ce projet était un projet d'école limité sur 3 mois

Avec du recul, je me rend compte qu'il aurait été bien plus bénéfique de choisir un framework (prototype, jquery...), d'apprendre comment il fonctionne, comment on l'utilise, et puis coder autour. Pour peu que l'on cherche à comprendre comment la magie opère sous les couches du framework, c'est très formateur !
Je suis pratiquement sûr qu'alors j'aurais bouclé mon webmail dans les trois mois, et que celui-ci fonctionnerait.

Maintenant c'est clair que j'ai appris des trucs en faisant des bêtises dans mon coin, mais si c'était à refaire je procéderai autrement.

Enfin à ta guise, tu peux au moins consulter la doc pour voir comment ils ont conçu leur truc

guillaumech · 3 Juillet 2009

Un point de vue qui se tiens pour certain, mais que je ne tiendrais

Je ne conçois pas qu'on puisse se lancer à l'assaut de framework alors qu'on ne connait pas le dit langage (ou concept, ou se que tu voudras

)
J'ose espérer que tu aurais fais pareil si sa avait été à refaire

(sa me rassure d'espère ça, si si). On apprend pas a conduire une WRC alors qu'on à fait que du velo ... Alors on pars sur son vélo, puis on essai les ptites motos, puis les voitures, tout doucement. Lorsqu'on est bien familiarisé avec tout ça, on tombe dans les sportives. Cependant, on peut très bien trafiquer sa petite voiture, pour en faire une voiture de sport, on se fait la main, et on à surtout se que l'on souhaite (de nombreuses voitures de ce type gagne les rallyes français

comme quoi ... on peut faire des choses bien).

Non non, moi je fonctionne pas ainsi. Je ne connaissais pas assez le concept MVC, je l'ai appris, assez pour arriver à le reprendre moi même. Aujourd'hui il est pleinement oppérationnel, sans fioriture. Comme j'ai fais pour tout se que j'ai appris. Je n'aurais jamais appris le C++ avant le C, pourtant tout est casi fais en C++ avec les bonnes librairies, alors que tout est à faire en C. Mais au moins j'ai appris à marcher avant de s'avoir courir, et je préfère dans ce sens

.

Sa me fait penser à un fameux langage que j'ai utilisé, qui pour moi est la pire des choses : le windev. Alors oui, c'est bien, oui on utilise tout se qu'il y à derrière, mais après ? Sans ça ? Je suis incapable de programmer 1/1000ème de se que peut produire cette suite logiciel.
J'ai buté, rebuté, encore et encore sur des appels javascript. Quand j'ai bien compris les concepts, j'ai découvert avec splendeur ses plus grandes librairies (prototype, scriptaculous, jquery ...). Et je suis content de l'avoir fait dans ce sens, même si commencer par ça aurait pris beaucoup beaucoup moins de temps.

Voilà

L'homme se construit avec son expériences propres (ses questionnement, ses bétises, ses erreurs ...)

maverick911 · 3 Juillet 2009

Il me reste à te souhaiter bonne continuation alors :hello: