2011-06-22 5 views
5

Je suis nouveau dans le monde de la programmation Web, j'ai trouvé quelques règles de base pour la conception de mon premier projet. Est-ce que cela ressemble à des règles raisonnables, ou est-ce que mon code pour divers aspects du projet devrait être plus ou moins mélangé ou organisé différemment pour une raison quelconque? Des deux livres que j'ai lus concernant la programmation web (un sur HTML & CSS, l'autre sur PHP & MySQL), ni l'un ni l'autre ne l'a clairement traité. Toute opinion de développeurs web expérimentés sera grandement appréciée!Règles de base pour séparer des parties d'une application Web

Règles générales:

  1. Pour le contenu relativement statique, utilisez PHP pour générer des pages (à savoir, remplir une histoire de nouvelles) afin HTML et PHP sont mélangés juste un peu ici. Pour les fonctionnalités dynamiques, implémentez une API XML/en texte brut de sorte que le backend PHP ne soit pas mélangé avec une logique de présentation (par exemple, une API/service côté serveur est implémentée sans aucune connaissance de présentation, puis un client AJAX est développé et présenté à l'utilisateur)

  2. Déterminez comment découper le client AJAX en différentes pages en fonction du désir de l'utilisateur de pouvoir mettre en signet une page et naviguer avec le navigateur.

+0

chacun a son propre avis.Si vous êtes un programmeur OO, vous pouvez voir le modèle de conception MVC recommandé partout. cela sépare le routage, la logique métier et l'affichage et semble fonctionner assez bien pour beaucoup. Vous pouvez également vous intéresser aux frameworks libres qui impliquent déjà ce modèle de design (Zend Framework, CodeIgniter, Kohana). Vous voudrez peut-être regarder dans les livres sur les modèles de conception, et le développement agile, car ils aident à garder votre code malléable. – dqhendricks

Répondre

1

Voir le MVC pattern pour les applications Web. Vous n'avez pas besoin de recourir à XML/texte brut pour séparer la présentation de la logique. L'utilisation d'un framework PHP tel que Symfony ou Cake peut aider.

Il est peut-être préférable de développer une application Web en utilisant d'abord le code HTML, puis de saupoudrer de l'AJAX par dessus pour que votre application ait une solution de repli si AJAX échoue - par ex. appareils mobiles.

Hope qui aide

+0

Merci pour la réponse rapide! On dirait que le modèle MVC est la voie à suivre ici. J'ai vérifié la première partie de la documentation de CakePHP. Il semble qu'avec le modèle MVC, je puisse générer des pages avec le côté serveur de contenu, et optimiser facilement l'expérience utilisateur en créant une autre vue générant du XML/texte en clair (en fonction de la complexité des données) à traiter et inséré en AJAX. Suggérez-vous d'avoir un site de secours uniquement HTML sans les optimisations AJAX pour mobile? –

1

Vous pourriez vouloir enquêter sur la MVC Pattern qui est un excellent moyen d'organiser les applications et séparer la logique de commande de la logique de présentation.

Certains frameworks MVC PHP populaires incluent:

Un cadre plus "difficile" (mais celui que je préfère le meilleur), est Kohana

Je recommanderais de commencer par l'un des deux premiers.

+0

Je recommanderais CodeIgniter sur CakePHP, c'est plus rapide, plus petit et plus simple. – timw4mail

+0

@ timw4mail CodeIgniter sonne bien (moins "automagique", moins de configuration, et peut-être plus rapide). Je remarque sur le site de CodeIgniter qu'ils ont un "CodeIgniter est-il juste pour moi?" liste qui a "Vous n'êtes pas intéressé par les bibliothèques monolithiques à grande échelle comme PEAR." Je ne comprends pas ce que l'utilisation de PEAR a à faire avec la sélection d'un framework ... –

+1

Un framework comme CodeIgniter est livré avec un tas de bibliothèques, ils disent en gros "Nos bibliothèques sont meilleures que les bibliothèques PEAR!" sur lequel je n'ai pas vraiment d'opinion. (Jamais utilisé CodeIgniter) – LainIwakura

1

Petits sites statiques: HTML uniquement, ou PHP avec en-tête et pied de page inclus, et fonctions communes.

Plus complexe: framework MVC qui sépare Vues (modèles), modèles (appels de base de données et manipulation de données) et les contrôleurs (Routing)

AJAX: framework MVC sur le backend, routes page spéciale pour obtenir des données de la page (vérifiez les bons en-têtes), history.pushState w/sauvegarde hashbang pour les chargements partiels de page. Selon la complexité, peut-être avoir des modèles sur le client.

+0

J'aurais dû d'abord noter que je travaillais principalement sur PHP, HTML et CSS et que je viens de commencer à regarder JavaScipt/AJAX et j'essaie de comprendre comment toutes les pièces s'emboîtent bien. On dirait que regarder dans un cadre MVC est la prochaine étape. Pour votre dernier point, ai-je raison de comprendre que les URL history.pushState/hashbang permettent à l'utilisateur de naviguer comme d'habitude et de marquer des signets tout en utilisant une page pilotée par AJAX? En outre, des suggestions quant à l'endroit où rechercher des informations de modèle de côté client? On dirait que c'est la prochaine chose à apprendre après un framework MVC. Merci! –

+0

Je n'aurais recours à la création de modèles côté client que si vous avez une structure de mise en page extrêmement complexe et que vous devez remplacer des parties de pages très complexes. Pour l'essentiel, l'envoi de HTML pour remplacer différentes sections de la page est généralement suffisant. – timw4mail

+1

L'API d'historique vous permet de modifier l'URL de la page et de conserver le bouton Précédent avec des chargements de page partiels. Il vous permet d'utiliser les mêmes URLs avec et sans javascript. Les URLs Hashbang sont un hack qui vous permet d'avoir une URL qui fonctionne avec le bouton de retour, mais qui est inutile sans Javascript. Actuellement, Internet Explorer et Opera ne prennent pas en charge l'API d'historique. – timw4mail

Questions connexes