Discussion :

[wadabush]

Bonjour à tous,

Je suis developpeur de logiciel embarque depuis maintenant 7 ans, et connais relativement bien les languages suivants : Asm, C, C++, ObjetiveC, Java, Python - pour les utiliser tous les jours. Pas mal de programmation réseau à mon actif (j'ai écrit des serveurs d'applications, avec les applications qui vont avec - le plus souvent pour de l'embarqué). Bref tout ça pour dire que j'ai quelques connaissances en programmation.

Depuis peu, j'ai des idées de créations webs. Cela-dit, a part avoir écrit un petit blog (jamais publié) avec du PHP et du javascript (pour faire des animations sympas dessus), et suivit quelques tutorials sur le net pendant mes heures perdus, on ne peut pas dire que je sois un expert.

Je souhaiterai écrire un site relativement simple, mais qui suit toutes les règles de l'art.

En gros, voilà les points importants du site:

- Gestion utilisateur.
- des formulaires sont fournis a l'utilisateur(de façons dynamiques si possible).
- un espace administrateur qui me permettra de générer mes formulaires.
- J'aimerai que ces formulaires soient transmis de manière sécurisée.
- Une base de donnee que je pourrai aller consulter via d'autres applications.
- A base de ces formulaires remplis, le server va lancer des scripts ou des applications pour générer des fichiers (doc, pdf, autres...?), et éventuellement les envoyer par mail à l'utilisateur, ou les proposer en téléchargement. Bien sur, le tout de manière sécurisée aussi.
- Je voudrais avoir un truc un minimum sympa (sans flash ou autres joyeusetés), donc je pense que le javascript s'impose pour avoir des animations par exemple. Il vaut mieux partir sur AJAX?
- Bien entendu, je voudrais faire les choses de manière a ce que le référencement ne devienne pas une horreur quand je décide de m'y coller.
- Je veux écrire des blocs réutilisables. Si demain je veux implémenter d'autres applications en ligne (j'ai en tete un googledoc par exemple - meme si l'idee de base n'est pas ca), je peux recuperer mes blocs parce qu'ils ont ete fait de maniere generiques.

Du coup, mes questions sont les suivantes:

- En partant de ce que je viens de décrire, je pense que si le CMS peut avoir des atouts (rapidement en ligne), il va me bloquer tres rapidement (le googledoc pas forcement possible)? J'apprends un Framework? - sachant que l'idee n'est pas de trouver du travail par la suite. Je pars de zero et je me constuis mon propre FWK - c'est con de reinventer la roue avec une gestion d'user, des soucis de securite, les problemes browser specific... par exemple non? Y'aurait pas des trucs entre deux?
- D'apres vous, Javascript, html, css et PHP ca suffit pour faire mon bousin? (si on parle d'un googledoc)
- Est-ce que d'autres personnes ayant le meme profil que moi se sont deja lances dans l'aventure? Si oui, en combien de temps vous etes vous sentis a l'aise avec les langages?
- Je n'ai pas a l'heure actuelle de deadline concernant mon projet. Cependant, j'aimerai que les premieres versions soient dispo d'ici 5-6 mois. Vous pensez que c'est raisonnable (en faisant du code tout propre et de qualite bien sur)?
- Pensez-vous qu'il est raisonnable de partir sur un projet comme ca tout seul et de s'occuper de tout (serveur, client, design, referencement, base de donnee...)? Vaut-il mieux penser a sous traiter certaines parties (en prenant le risque de perdre la main sur les choses)?


Je pense que ca sera tout dans un premier temps. Je rebondirai au besoin dependant des reponses que j'aurai!

Merci d'avance!!

[Rakken]

Quelques éléments de réponses :

- D'apres vous, Javascript, html, css et PHP ca suffit pour faire mon bousin?

Oui, absolument.

Pour le CMS, effectivement, tu vas avoir un tas de trucs tout fait qui font que le départ sera très rapide, mais tu risques de te heurter à des problèmes pas forcément très amusant quand tu voudras faire des trucs un peu spécifiques (ce qui arrive *toujours*).
Entre le CMS (ou tu remplis les cases que le site te fournis) et le tout-à-la-main, il y a les framework, qui te fournissent un cadre pour le développement et un tas d'outil tout fait. Tu réinventes pas la roue, mais tu dois réapprendre à pédaler à chaque framework... Zend Framework, CakePhp sont deux exemples, mais il y a en a plein d'autres.

Pour te sentir à l'aise avec le php, si tu sais déjà bien coder par ailleurs, ça devrait aller assez vite. Pour le javascript... perso, je ne suis toujours pas à l'aise parce que je m'en sert seulement au besoin et que je limite ce besoin au maximum.

Pour les effets & autres, il y a des libs javascript, du genre jquery qui sont très bien. J'aime bien ce genre de lib, parce que c'est une boite à outil dans laquelle tu peux piocher.

Cinq/six mois pour un projet, ca ne veut rien dire... si tu fais ça sur tes soirées ou à temps complet, c'est très différent. A temps complet, avec ce temps là, en extrapolant un peu à partir des morceaux de fonctionnalité dont tu as parlé, j'aurai très largement le temps de le faire.

Pour ce qui est du référencement, un bon truc, c'est de regarder ton site sous Lynx (un navigateur en mode texte), tout ce que tu peux lire sous lynx peut être lu par google, si ça passe sous lynx, le référencement sera, au pire, correct.

[wadabush]

Merci Rakken pour toutes ces réponses.

J'ai par ailleurs chercher de moi même, et il me semble que je vais partir sur un framework. J'ai pas mal regardé symphony qui me plait bien pour le moment. Mais je vais prendre le temps de bien étudier les autres pour bien me rendre compte des avantages/inconvénients.
Concernant le javascript, en effet, je ne compte pas en abuser, et je vais certainement me limiter à faire des anims ( j'avais en effet regardé jquery qui m'avait eu l'air d'être pris en main assez rapidement).

Concernant mon projet, ca sera le soir après le boulot. J'ai déjà eu l'occasion de bosser de cette manière pour d'autres projets, et j'arrive à dégager environ 20h par semaine. Si on fait un rapide calcul, ca fait 2,5x26 = 65md. J'ai tendance à penser que ca sera suffisant pour une V1 (eventuellement pas full feature).

D'un point de vue technique, j'ai en tête l'architecture globale. Par contre, il y'a des points sur lesquels je bloque.

En gros voilà les parties qui me font le plus soucis:

- Premièrement, j'aimerai faire quelque chose du style:
- Je suis super admin.
- Un client qui créé un compte d'une certaine façon est admin de son compte.
- Un client du client qui créé un compte est simple utilisateur, mais n'a accès qu'aux informations du compte auquel il est rattaché.
Est-ce qu'il y'a des FWK qui permettent de faire un mechanisme pareil sans trop forcer? J'ai vu dans symphony la gestion des users, mais je n'ai pas vu 3 niveaux de droits (enfin 4 avec le mode non connecté).

- Deuxièmement, j'ai du mal à concevoir comment gérer mes comptes.
Mon idée, serait quelque chose du style (c'est amené à évoluer):
Une database pour le compte super administrateur.
Une database par compte administrateur + un folder où stocker les informations qui ne rentre pas dans la database + un folder pour chaque compte dans ce compte administrateur (bien entendu en lien avec la database).

Est-ce que c'est quelque chose qui a du sens? (sachant que mon nombre d'utilisateur risque d'être grand (~1000 compte admin + 10000 comptes user chacun, mais que les données pour chaque user relativement petites)) Est-ce que vous avez déjà utilisé un truc du style? Niveau sécurité, c'est OK? (en partant du prédicat que le code PHP est bien fait...) Avez-vous d'autres propositions?

- Enfin, je compte écrire un soft en C++ qui pourra faire du traitement sur ces informations lorsque le server lui réclame. Pas de soucis à ce niveau là?

Encore merci pour ton aide.

[Rakken]

Etant, à titre personnel, peu friand des frameworks, je n'en connais pas qui fassent déjà ce que tu veux. Ceci étant, ça ne semble pas insurmontable. Le truc, c'est vraiment de bien penser ton architecture avant. Si le boulot en amont est bien fait (et il n'est pas très différent pour un site web que pour une appli "classique"), ça ira.
Après, faut trouver un framework qui "t'aide" à faire un module user personnalisé comme celui que tu veux et pas qui t'empêche d'avancer. Mes compétences s'arrêtent là. Perso, je le ferai intégralement à la main je pense, ce qui ne veut pas dire que c'est la meilleure solution.

65md, ca fait trois mois à temps plein. C'est assez pour une première version. Après, faut voir à quel point tu apprends vite ou pas ;-)

Si l'estimation de ton volume d'utilisateurs est correcte, 1000 * 10000, on arrive vite à dix millions d'utilisateurs, tu vas avoir des problèmes de perfs. A minima il te faudra ta base de donnée et ton serveur apache sur deux serveur physique différent (quand tu regardes un sites tourner, y a deux trucs qui mangent du proc, c'est la bdd et le traitement php pur). Plus probablement, tu devras mettre en place un système de load balancing (sur la même ip vont se cacher plusieurs serveurs), avec tous les problèmes de synchro inter-serveur que ça va engendrer.
Par contre, la sécurité dépends quasi exclusivement de ta manière de coder.

Pour le soft en c++, à priori, aucun problème, le php peut appeler des programmes externes.
Tu peux même envisager un système de "webservice", ou sur une url non destinée à être vue par un utilisateur, tu passes des infos (genre getStatBrutes.php?date=...) et le php te retourne (par exemple), un xml que tu pourras traiter. Dans le même genre, il existe php-cli, qui est un php destiné à être utilisé comme un script shell, sans passer par apache, ce qui est pas mal approprié pour un prog c++ qui tourne sur le même serveur.

Dernier point, pour tes multiples bases de données... perso, dans tous mes projets je n'ai toujours utilisé qu'une seule base. Je ne saurais pas te dire à quel point il peut être pertinent de les dupliquer pour chaque admin.
A froid, j'aurai tendance à dire que ce n'est pas utile, mais vu le nombre d'user que tu vises, ca peut peut-être être intéressant quand même pour diviser le boulot sur plusieurs serveurs.
Éventuellement, tu peux poser cette question précise dans le sous-forum qui va bien tu auras une réponse plus pertinente que la mienne.

Dans tous les cas, bon courage ;-)

[wadabush]

Merci encore de ta contribution.

Concernant la charge. Je me suis pas bien exprimé. En fait j'aurais en effet 1000 clients "admins", mais les 10000 autres ne seront pas des clients régulier, seulement des clients du client qui viendront répondre à un questionnaire (certainement une seule fois dans leur vie).
En bref, on sera loin des 10 Millions de users en même temps, mais plutôt des phases, ou un client va fournir un questionnaire à une liste de ses clients, qui eux vont venir y répondre et populer la database du client admin.

En gros, je vais avoir des databases relativement grosses avec des millions d'entrée (au bout d'un certain temps bien sur), mais un traffic journalier relativement raisonnable (j'imagine mal plus de 1000 connections par jour - et encore en étant laaaaaaaaaaaaarge).

De plus je préfére avoir une database par client admin, car je pourrai l'exporter plus facilement il me semble.

Concernant le fait de tout faire from scratch sans FWK, je pense que si je le fais bien, je gagnerai évidemment du temps dans mes développements futurs, mais j'ai peur qu'en tant que novice je tombe dans tout un tas de pièges qu'un FWK me fera éviter par défault.

Ton avis perso à toi:

Le plus rapide (pour la première application seulement) est d'apprendre à se servir correctement d'un FWK, ou de partir de zéro et de créer mes modules en fonction de mes besoins ? (on est pas à la minute près, mais si c'est du x2, ca devient intéressant)

Parce que par analogie, si tu prends un FWK graphique en C/C++, le temps est incomparable, et il est plus rapide - et de loin - d'apprendre à bosser sur un SDK plutot que de tout faire from scratch.

[dev14]

Bonjour,

personnellement je conseillerais le "tout-à-la-main" surtout pour faire ses armes. La gestion intégrale du site de A à Z est le meilleur moyen pour tout comprendre.

Cela amène à s'arrêter sur un incertain nombre de points :
d'abord niveau technos :

- Le langage PHP forcément, mais si tu as fais tu Java/C++, alors il ne faut pas se priver du PHP5 orienté objet.

- Php/Mysql

- Le XHTML/CSS3 pour les styles

- le javascript + librairies comme jquery citée plus haut

- éventuellement plus tart, la technologie Ajax

Puis ensuite voir les questions liées à la performance, sécurité, etc..

url_rewriting, compressions, etc...

De toute façon, qu'un site passe par un CMS, framework ou autre, il est toujours en chantier.

Alors c'est sûr que la version 1.0 semblera éloignée des objectifs fixés, mais dans 4 mois, ce sera l'inverse.

[wadabush]

Merci dev14 pour ta participation.

En effet, le tout fait à la main a des avantages, mais j'ai peur de créer des failles de sécurité (même si c'est pas catastrophique dans le cas de mon site), si je pars de zéro.
Concernant le PHP OO, en effet je comptais partir la dessus, car j'ai des bases solides en orienté objet, ce qui me fera gagner pas mal de temps aussi.

Je pense qu'avec vos réponses relativement rassurantes, je vais dans un premier temps me faire l'architecture globale du site (en détaillant mes classes PHP au maximum). Une fois que j'aurai fait ca, j'aurais une vision plus globale de ce que j'ai à faire, et donc une estimation du temps de développement global. A partir de là, je pourrais faire mon choix de prendre ou non un FWK (je laisse de côté le CMS).

Je pense que viendrais régulièrement vous questionner sur les bonnes méthodes.

Dans un premier temps, est-ce que vous auriez un tutorial à me proposer pour implémenter un accès membre totalement sécurisé (sans FWK)? Si j'ai cette base, je pourrai l'adapter à mes besoins relativement facilement - et comprendre à partir de quel moment on dit qu'un site est "sécurisé"!

Encore merci.

[dev14]

A part le C, et Java, je ne connais pas les environnements sur lesquels tu as travaillé, mais en terme de sécurité, de ce que j'ai vu en entreprise, il y a minimum à savoir, le reste relève de la psychose.

Tant que ce n'est pas un site bancaire, une boîte de messagerie. Tant qu'on ne stocke pas de données sensibles et ultra confidentielles, que risque-t-on?

Après on est jamais à l'abris d'une attaque idéologique ou autre. Mais avec des sauvegardes des fichiers et de la base de données régulières, on s'en sort.

J'ai constaté dernièrement une faille immense sur un site dont je tairai le nom même si je ne les apprécie pas et vous verrez pourquoi... Au moment de payer ils passent le montant dans le GET (dans l'URL), le b-a ba pour tout dire. Je les ai appelés pour le leur dire par gentillesse et pour leur rendre service, et ils m'ont poliment renvoyé sans rien entendre. bref. Le fait est que, malgré leur immense faille, ils semblent ne pas avoir subi grand chose comme attaques ! Sinon ils se seraient bougés !

Alors cela ne veut pas dire que le risque n'existe pas. Mais il faut relativiser.

Personnellement je pense qu'il n'y a pas de plus grand framework que celui qu'on façonne au quotidien On a chacun sa logique et je préfère suivre la mienne plutôt que de me contraindre à de lourds frameworks qui m'offrent tout un tas de modules dont je ne me servirai pas.

Ensuite pour bien débuter, ce que je peux déjà te conseiller :

Formulaire : toujours passer par des méthodes "post". Les méthodes "GET" font passer les variables dans l'url. Ce qui n'est pas un problème en soi pour certaines actions de navigations comme lorsque je poste cette réponse, et que je vois do=newreply dans ma barre d'adresse.

Quand tes utilisateurs vont s'authentifier, on va tester login/mot de passe. Le mot de passe peut être crypté par différentes fonctions php qui le permettent. (md5(), crypt(), ...). Il faut prévoir d'éviter les SQL-injection.

C'est à dire que dans le formulaire, comme on va taper dans la base, il faut éviter qu'on puisse y entrer du code SQL. Pour cela, passer ses données par des fonctions comme mysqli_real_escape_string().

Ensuite une fois que l'utilisateur est connecté, utiliser des variables de sessions et des cookies pour que si il quitte le site et qu'il revient, il n'ait pas à se reconnecter. Détruire les cookies au bout d'un certain temps (prédéfini) histoire que si c'est une personne lambda utilise le même ordinateur et revient sur le site le lendemain, il soit déconnecté.

Et puis toujours : éviter de stocker des informations sensibles.

Ensuite bien voir tous les aspects liés au .htaccess qui est un fichier de configuration Apache qui permet entre autres de gérer l'url_rewriting. L'url_rewriting permettant par exemple de "travestir" nos pages réelles en des pages "façades". Par exemple la page : www.monsite.com/folder1/folder2/gestion.php se transformerait en : www.monsite.com/autrechose

Ce qui a pour effet qu'on ne puisse pas voir notre arborescence, et par conséquent tenter des accès à différents fichiers.

Gérer les droits des fichiers en 604. Là dessus, si quelqu'un n'est pas d'accord, qu'il n'hésite pas à le dire.

Interdire les accès à certains fichiers du serveur (toujours dans le .htaccess), par exemple :
<Files *.ext>
Deny from all
</Files>

Et puis pour vraiment restreindre encore plus des accès, utiliser un .htpasswd pointé par le .htacess, qui sur des pages voulues demande pour visiter la page un login/mot de passe crypté.

On peut aussi restreindre les accès par rapport à l'IP de l'utilisateur. Ce qui peut être que provisoire si ce sont des IP dynamiques. Mais sur une connexion à un site, on peut très bien jouer sur les IP également.

Et puis surtout, il faut absolument dans un premier temps développer son site en local pour bien faire ses tests avant de le déployer.

Pour cela, WampServer, ou Xamp, ou d'autres serveurs locaux feront l'affaire.

En local, afficher ses erreurs, et le désactiver en ligne. Ce serait dommage qu'un utilisateur lambda tombe sur une erreur de type mysql ou php indiquant un nom de fichier, le type de l'erreur etc...

[wadabush]

Je vais garder ce post en règles à suivre, et faire bien attention de m'y plier.
J'avais identifié certains points, cela-dit pas tous, donc je te remercie.

Concernant le FWK, je suis d'accord avec toi. Cela dit rien ne t'empêche de te faire une couche supplémentaire à un FWK afin de te retrouver avec les interfaces qui te conviennent dans ta façon de faire. Alors oui ca rajoute de la lourdeur, mais des fois, cela parait dommage de repartir de zéro - et ca te permet aussi de changer de FWK le jour où il y'a besoin. Avec le recul, et après avoir regardé les FWK disponible, j'ai cependant tendance à penser que - en PHP - les FWK ne sont pas si gros et importants que dans les technos que j'ai pu utiliser par le passé. Bref, comme je l'ai dit plus haut, ma décision n'est pas prise, et je la prendrais une fois mon architecture bien détaillée (en gros si j'arrive à la détailler assez, ca voudra dire que je n'ai pas besoin de FWK).


Une autre question (j'ai envie de dire dernière, mais j'ai comme l'impression que ca ne sera pas le cas).
Je pense partir comme je l'ai décris plus haut, vers un modèle ou chaque client aura un directory à lui + une database (ou une table dans une database, à voir).

Qu'est ce que je risque avec ce directory - en terme de sécurité? Est-ce que c'est vraiment une bonne solution, ou il vaut mieux que je me débrouille à mettre toutes les informations dans une database? La database va me gérer toutes les transactions, et j'amoindris les risques de fichiers corrompus et autre, mais elle me restreint aussi en terme de possibilités (fichiers binaires en autres - je sais que c'est possible, mais j'ai tendance à penser que c'est pas l'idéal si les fichiers sont gros), d'où mon avis est de faire un mix des deux en aillant les urls dans ma database, et mes fichiers dans une arborescence par client.


J'étais un peu déçu les premiers jours de mon post, à cause du manque de réponses, finalement l'impatience c'est un défault, parce que vous m'avez tous les deux bien éclairés sur mes questions, et je vous en remercie!

[dev14]

Là j'ai l'impression que ta vision des autres environnements empiète sur la philosophie web Php.

Ce n'est pas avec une arborescence client/fichiers que j'architecturerais mes données.

Mais par la bdd. Par contre, j'ignore ce que tu comptes stocker comme données. Mais une base de données entière par client, ça fait cher le client !

Je verrais plutôt pour commencer une base de données avec une table clients avec infos de base (login, mdp, mail, ...), liée à d'autres tables représentant les données.

Après ne connaissant pas le projet, peut être qu'il y a mieux.

[wadabush]

En fait, c'est pas encore clair dans ma tête ce que je veux stocker comme informations. Mais dans le but d'être le plus générique possible - parce que ca évoluera forcément, j'aimerai être sur que mon architecture me permette de stocker des fichiers binaires (word, pdf, video?, audio, exe...). D'où mon idée de stocker un chemin dans la BDD et le fichier directement sur le disque. Maintenant peut-être que tout mettre dans une BDD est la solution. C'est quelque chose qui se fait?

L'idée principale était en effet d'avoir une première database avec les login/mdp/infos... du client avec un lien vers une database client. Ca c'était dans le but de faciliter l'export de la base de donnée au client.

Imaginons - c'est pas encore prévu - que je propose en parallèle un soft à installer localement chez le client qui exploite cette base de donnée, et que pour une raison X ou Y, mon client décide de récupérer ses informations, il me semble que ca sera plus facile si ma database est complétement détachée du reste, non? (a part bien sur si je fais aussi un script d'export - qui devra être fait dans tous les cas en fait...) En fait, en quoi ca fait "cher" le client? C'est plus couteux (en terme de perf) d'aller taper dans une nouvelle database que dans une table de la première database?
Après, ca va aussi me permettre de rediriger mes clients vers des serveurs différents ou seront stockés leur database - je vois très loin, ne pensez pas que je suis trop ambitieux, j'essaye juste de penser aux éventuéls problèmes en cas de succés...

[dev14]

Ah oui en ce qui concerne les fichiers de tout genre, on les stocke sur le serveur là d'accord.

Ce n'est pas une question de performance que je ne considère pas nécessaire d'avoir une db par client. C'est simplement qu'une petite db peut contenir des centaines de milliers d'informations, et que j'ai du mal à imaginer qu'un client puisse nécessiter autant de ressources. Toujours en gardant en tête qu'en db, il n'y aura que des caractères, des liens éventuellement vers des fichiers, mais les fichiers seront stockés eux sur le/les serveurs.

[wadabush]

Ok, on est d'accord sur le principe des databases. Je vais aller plus loin dans mon étude, et je prendrais la décision en fonction!

Je me suis baladé sur le forum, et je suis tombé sur quelque chose d'intéressant:

http://www.developpez.net/forums/d73...isir-php-java/

Bon alors en effet ce genre de débat est relativement stérile, parce que ca finit toujours en - Oui la techno A est mieux parce que $(pleins d'arguments qui ont l'air très pertinent)... (mais en fait inconsciemment c'est surtout: ca fait 5 ans que je m'investis dans cette techno, et ca me ferait chier que la techno B soit la mieux).

Bref, toujours est-il qu'il semblerait que java soit en train de grapiller assez rapidement des parts de marché à PHP. Etant donnée que j 'ai une certaine expérience de java (surtout du dev Android à dire vrai), est-ce qu'il ne serait pas judicieux de partir dans cette direction plutot?

Toujours dans un but de me projeter dans l'avenir:
- Si demain mon site évolue vers une suite de logiciel en ligne, ca me semble plus judicieux de partir sur Java.
- Si demain, le site marche, et j'ai besoin de recruter - encore une fois, c'est pas forcément le but recherché, je veux juste me poser toutes les questions possibles - C'est plus facile de trouver des gens compétent java ou PHP? Le travail en équipe sur PHP semble être pas forcément évident, c'est vrai?
- Concernant le fait de faire une application que le client pourra installer localement, si le serveur est en java, et bien structuré, je devrais pouvoir en sortir une version standalone qui marche avec un code commun. Ce point est quand même un sacré argument en faveur de Java.
- Peut-être pas besoin de faire des softs en C++ qui moulinerait les databases, et je ferai tout en java.
- Je viens de languages typés, passer à du PHP ou je perds ce typage est un point noir...

D'un autre côté:
- Pour la V1, le PHP est largement suffisant, JAVA fait un peu usine a gaz.
- J'ai l'impression que j'irai quand même plus vite en PHP (même si je connais JAVA).
- J'ai trouvé plus de tutos, de bouts de code à réutiliser en PHP.

Je suis désolé de poser toutes ces questions, mais j'ai envie de faire les bons choix d'entrée - de toutes façons, les autres questions que j'ai posé sont valables sur Java comme sur PHP.

[dev14]

Pour un gros projet, Java me semble plus stable d'après ce que j'ai vu en entreprise. Après Facebook est géré en php et ça ne pose pas vraiment de problème.

Concernant les tendances, PHP orienté objet a apporté un + quand même.

[bob633]

J'interviens juste rapidement sur cette conversation pour l'utilisation d'un framework.

Au début j'étais très réticent. J'aimais bien coder mes petits sites à la mano avec notepadd++, en activant 2 - 3 paramètres, ca me convenait.

Après quelques sites, je me dit que un jour il faut évoluer quand même. Je me suis décider à me lancer sur symfony2 (ca fait 2 semaines, quel exploit ).

Et bien je te le conseil ! J'utilise l'IDE netbeans PHP, qui intègre parfaitement symfony2, le tout se fait facilement. Ce framework se base sur le pattern MVC (modèles - vues - contrôleurs), ce qui rend le développement très sain à mon sens. De ce plus, le tout utilisant le PHP5 (biensûr) et HTML5.

Côté base de données, symfony utilise doctrine. En gros, plus de requêtes ! Tu créés tes objets, et symfony créé tes tables, tes requêtes insert, select, ... avec PDO (à l'actualité en terme d'accès à la BDD sur PHP).

Je vais pas parler de toutes les options proposées par Symfony2, mais n'hésite pas !

Puis un framework veut aussi dire un niveau de sécurité très bon (base de données, champs formulaires, ...).

Pour finir symfony utilise un système de "bundle". En gros ce sont des parties de sites réutilisables sur n'importe quel projet. Tu en trouves sur internet des gratuites, et il y en a un connu pour la gestion utilisateur (avec droits d'accès, niveau, inscription, gestion de profil, ...).

Le travail en équipe ne poste pas plus de soucis que ça sur PHP. Tu peux très bien utiliser un SVN comme tout langage et chacun bosse sur sa partie. Avec l'histoire des bundles, chaque développeur peut bosser sur sa partie (bundle News, bundle voiture, bundle covoiturage, ...).

Je suis pas convaincu par l'utilisation de J2EE (on parle bien de ça quand tu dis Java ?) dans le web. Je trouve ça lourd, surtout à la mise en place (je manque certainement d'XP sur le sujet).

Mais PHP c'est APACHE + Éditeur de texte et c'est partie, le tout en gratuit.

Mettre des objets en BDD ? J'utilise toujours des chemins et je stocke en local sur le disque (symfony propose une gestion d'upload des fichiers).

Non non je travaille pas pour symfony 2

[bob633]

Pour un gros projet, Java me semble plus stable d'après ce que j'ai vu en entreprise. Après Facebook est géré en php et ça ne pose pas vraiment de problème.

Concernant les tendances, PHP orienté objet a apporté un + quand même.

j'ai vu récemment que Facebook était du PHP compilé en C++ .. donc on sait pas vraiment le moulin qu'il y a derrière ...

[Rakken]

Je suis assez d'accord sur le fait que J2EE, c'est somme toute assez lourd à mettre en place pour un gain pas forcément évident. Ça peut valoir sur le coup sur de très gros projets, mais vu ce qui se dessine du tien, le php me semble tout à fait adapté.
Trouver des gens qui savent faire du php/java, ca n'est difficile ni pour l'un, ni pour l'autre. Au pire, un codeur java confirmé n'aura pas trop de mal à se faire rapidement à du php.

Maintenant que tu as précisé pour ton nombre d'user, sans hésitation, une seule base. Mon site le plus gros gérait 10000 connexions (non simultanée) par jour pour de la saisie de planning, ce qui a rapidement donné des tables avec plusieurs millions de lignes, sans que ça ne pose de problème (les index, c'est la vie). Si tu as des fichiers, un répertoire qui les stocke, et une table qui fait lien entre le nom et un id, et le tour est joué.

Pour framework ou pas... Je ne sais pas quoi dire. Ceux que j'ai tenté ne m'avaient pas convaincu à l'époque, mais ça date un peu. Du coup, j'ai codé le mien que j'utilise et qui, s'il a des défauts, correspond au moins à ma façon de penser.

[dev14]

symfony2

Vu qu'on avait les mêmes habitudes, j'ai voulu essayer symfony, et Zend que j'avais déjà, j'ai fait un tuto. Eh non je n'accroche pas. Surtout pour ce que ça fait. C'est trop balisé, et pour faire 3 pauvres pages d'un formulaire, ça sort l'artillerie lourde. Bref.

Ca date du 26-27 octobre mes essais.

Nous sommes le 30, j'ai voulu utiliser un site en local, et vous voyez, c'est typique de ce qui m'énerve avec les framework, voilà que mon site lorsqu'une de mes fonctions appelle un la fonction unlink(), ERREUR ! Permission denied.

Alors après avoir cherché 1H à comprendre : pourquoi la dernière fois où je l'utilisais, tout fonctionnait bien alors que là ça ne fonctionne plus ! Sachant qu'aucune ligne de code n'a été modifiée. Après avoir comparé avec ma dernière sauvegarde.

Alors littéralement l'erreur indiquait un problème de droits utilisateurs... Super, j'ai tous les droits sur tous mes dossiers, je suis admin du PC, bref.

Et donc et donc, après avoir tout essayé ou presque, je me suis rappelé que l'installation et la manipulation des frameworks avait modifié des configurations Apache, PHP, et peut être d'autres fichiers de conf. J'avais tout installé par ligne de commandes.

Donc > Restauration Système au 24 octobre avant l'install des framework. Et hop ! Ca remarche !...

Bref, ça confirme mon rejet des frameworks. n'en déplaise aux pro frameworks

[cactusbapt]

Bonjour,

Je me pose une question.
Tu dis que tu as une expérience en Python. Dans ce cas, pourquoi pas partir sur le framework Django ? Ça nécessiterait une période d'adaptation, mais surement moindre que de devoir faire le site en html, css, javascript et php.

[wadabush]

Hello tout le monde,

Je reviens à la charge pour quelques précisions supplémentaires.

J'ai bien pesé le pour et le contre, je me suis penché sur les différentes technos, framework ou non, et mon choix va se porter sur PHP et Zend Framework. Je n'ai pas encore commencé à coder, cela dit j'ai déjà une bonne architecture en tête. Tout ce que j'ai fait pour le moment est bien entendu complétement indépendant de la techno.

Par contre, j'arrive maintenant à un autre dilemme. A terme, je souhaiterai que mon application server soit disponible via des applications mobiles (android, iOS, accessoirement le reste).

Quel sont les choix qui s'offrent à moi?

- Une version du site web pour mobile... J'ai toujours trouvé ca bofbof. Dans l'idéal, je préférerai une application native (j'ai les connaissances nécessaires pour faire les applis).

- J'écris un serveur avec des sockets qui vient taper dans ma base de donnée directement. Bonnes perfs, mais je me tape 2x le travail ce qui est dommage - j'ai déjà un serveur générique que j'avais écris pour un autre projet qui pourrait me resservir (a base de format perso pour la communication).

- Etant donné que je compte bien me forcer à garder une architecture MVC côté serveur, je devrais pouvoir faire en sorte d'avoir plusieurs vues. Une qui me sort du html pour les browsers, et une qui me sort du xml/jason/autre format pour les applis.

Bien entendu, la 3eme possibilité est de loin la meilleure (meme si la 1ere me demandera moins de travail). Alors avez-vous des tutos sur comment faire ça? Quelqu'un peut-il me détailler rapidement l'idée générale?

Je dirai en gros que l'appli fait un requête HTTP sur mon site avec un certain argument pour lui notifier que c'est une appli et non un browser, et mon modèle va alors me rediriger vers la vue XML à la place de la vue HTTP. J'ai bon?

Merci à tous!