Bonjour,
 
Y a pas mal de temps que j'ai pas développé en .php (2 ans) et je risque fortement de m'y remettre bientôt...
Le projet serait un site portail front end entre 15 et 20 pages et un back office pour gèrer 5-6 tables MySQL.
 
A l'époque je définissais mes pages modèles en HTML (en pleurant sur les différences entre IE et Firefox). Je définissais les pages.php qui allaient parser les templates avec vtemplate et je crées dans ces fichiers les eventuels tableau et formulaires (pas très maintenable)
 
Pour modifier le site j'allais aussi quelque fois modifier les template plus ou moins redondan directement dans un éditeur HTML. :-(
 
Finallement le temps de développement etait souvent long comparé à des appli executables...  
 
Ma question est de savoir si vous utilisez des méthodes plus efficace pour ce genre de projet ou des conseils (techniques, logiciels...)
 
Merci
 

|
 |
 |
 |
 |
 |
 V

J'ai bien vu ton topic MVC, mais franchement après avoir lu le quart des post je suis pas beaucoup plus avancé...  
 
De plus il est orienté niquement sur MVC peut etre il y a d'autres méthodes.
 
Merci

MVC, c'est pas une méthode de développement, c'est une architecture d'application (plus précisemment, un design pattern).

Non, il est censé parlé des architectures différentes. Là pour l'instant on a juste parlé d'MVC, mais tu peux y aller et lancer le débat Sinon le MVC est une architecture plutôt logique, ou au moins la partie VC

Je pense pas qu'il y ait vraiment des méthodes de dév propres à PHP. Ce n'est jamais qu'un langage de programmation (y compris orienté objet). Donc toutes les méthodes de conceptions de POO sont applicables (modélisation OMT ou UML) et je pense qu'un outil dans le genre de rationnal rose doit être capable de sortir à partir de l'uml le squelette des classes en PHP.
Sinon, y'a aussi les méthodes de dév dites "agile" comme XP (extreme programming) ou crystal, mais y'en a d'autres...

Mouais, l'UML c'est bien pour documenter, mais pour designer c'est bof

 
Perso, j'utilise OMT pour modéliser le MCD de mes BD. Ca prend moins de place que Merise où faut dessiner une grosse patate entre 2 tables pour écrire le nom de la relation
Comme je développe essentiellement des applis reposant sur une BD, le schéma de mes classes découle du MCD : 1 classe = 1 table
Jusqu'à présent, ça a toujours bien fonctionné...

rufo > une classe pour une table, c'est bien, mais il ne faut pas oublier que parfois un élément métier peut correspondre à un groupe de tables et dans ce cas, il est parfois plus pertinant d'avoir une classe par élément métier plustôt qu'une classe par table.
 
Edit : Correction d'ortographe.

 
J'suis d'accord, mais métier pas métié

 
Une classe peut très bien être constituée de plusieurs autres classes. Un grand classique, c'est lorsque t'as une relation 1-n
Imaginons une commande comportant plusieurs articles.
Moi, je vais faire une classe "Commande", une classe "Article" et dans ma classe "Commande", je vais avoir un attribut de type tableau qui contiendra la liste des instances d'articles qui composent la commande.

Donc ton équation est fausse : 1 classe = 1 table  
C'est plustôt 1 classe = 1 table ou plusieurs autres classes
 
Ton architecture ne découle donc pas totalement du MCD de la base de donnée vu que les couches les plus proches de l'utilisateur n'y sont pas décrites.

Ben si, j'ai bien une classe pour chaque table de ma BD. Ensuite, faut bien modéliser dans les classes les relations entre les tables. Donc, ça rajoute des attributs dans certaines classes.

La meilleure technique de dev PHP, c'est de ne pas utiliser du PHP

Application utilise framework, application utilise framework ( repete )

putin coupure de courant en plein message de 15+ lignes ...

Architecture en procédural typique

/
-index.php = controlleur

/include/
           -librairies
/modules/
           -appli1
                    /template1
           -appli2
                    /template2

/cache/

defs :

controlleur index.php

include = librairie de function

principe = 1 function = 1 tache

template et cache pour le template et cache

index.php = runtime :

tu appelles ton module par  $_GEt et include plus tard.

Jusque ici t'as un framework MVC, par contre à partir du moment ou tu codes un module tu en sors et tu entres dans l'enfer de la modification du code.

definition du module :

module = include librairie + mélange MC .

+ de l'architecture: simple et efficace . intuitif

- de l'archi = à supposer qu'un module dépasse une certaine compléxité( taille de code plus exactement ), ça devient ingérable.

Sinon tu fais comme 95 % des "développeurs" et tu t'installes un CMS ou tu serres les fesses et pisse des lignes.

Me pense qu'il faudrait arreter de contribuer pour rien  

kikoooooooooooooo