Reprise du message précédent :
 
Alors une bonne idée serait de commencer par le début, genre apprendre les bases avant de commencer à coder un vrai site?

Apparemment non

tu sais , ce n'est pas grave de na pas savoir faire. Mais c'est débile ( surtout sur un forum) de faire comme si tu savais alors que non ( une boucle en base de données, c'est dans les 5 premiers cours en PHP)
 

'Jour à tous,
 
Voilà je me demandais ce que vous pensiez des singleton en PHP ? C'est bien ou c'est mal C'est pour un bdd, un objet Db avec des méthodes connect() et query().
 
merci

T'as plus général comme question?

Les singletons, c'est mal en général. C'est encore pire en php, vu son contexte d'exécution.

Dans l'absolu (qq soit le cas ou le language) c'est mal :
1/ ça suppose que t'aura jamais 2 instances alors que ça peut toujours arriver :
- pour des test unitaires
- si t'as plusieurs connexions
2/ ça fige son instanciation : tu ne peux pas vraiment donner d'arguments au constructeur ou faire une instanciation un peu complexe, vu que tout se fera dans un ::getInstance() interne qui ne prend pas d'arguments. Donc ce sera forcément couplé au contexte (donc inutilisable sans config instanciée etc).

Après, c'est comme tout, c'est pas interdit, mais tu sais les pbs que ça peut poser.
Je dirais même : fais-le, et tu verra quand tu seras emmerdé (si tu l'es)

Bah, en l'occurence, j'apprends et je connais pas bien, donc c'est sur que c'est un peu général

ok

Ok, mais pour un système de db pas besoin de contructeur très complexe ?
 
Merci.

Ca dépend

Si c'est pour un site pas trop complexe, ya pas trop à se géner je pense.

Ok, merci, je vais essayer ça.

Ok, et je vois cà dès que je finis mon singleton d'accès à la bdd
Merci Je vais partir là-dessus.

Putain c'est encore plus con ça, les "design patterns" existent à la base pour résoudre des problèmes, si t'as pas le problème t'as pas à implémenter le pattern
 
Dire aux gens "vous devez implémenter ce pattern" c'est comme leur dire "vous devez utiliser ce marteau". Pas de bol, l'un des étudiants moins con que la moyenne a décidé de monter son armoire avec des vis, et il se retrouve à clouer ses vis

et dans un script php ?  
 
sinon, ça devrait cocher la case, mais c'est sale, n utilie plus document.forms
ni form.nomDeLInput

Heuu...

document.forms[0][nomchk].value = 0

En fait t'as aucune idée de ce que t'écris c'est ça? Tu est un codeur PHP qui balance du code au pif dans l'éditeur et regardes ce que ça semble donner quand tu rafraichis ta page?

Tiens, une question pour voir.
Mettons que je suis dans un contexte MVC style zend/symfony/skevouvoulez, et que j'ai une action dans un controller qui va afficher un <form>.

Valider ce <form> va m'envoyer où, pour vous?
1) La même action du même controller, qui vérifie un truc du genre isPost().
2) Une autre action du même controller, qui se charge uniquement de valider le formulaire puis de forwarder vers une autre action
3) Autre?

La même pour moi, plus pratique pour tout : moins de code, moins de redirections, tout est centralisé etc.

Question suivante : il se passe quoi quand à la suite du premier formulaire tu veux un second formulaire, etc?

Jusque là, ça ne se passe pas

Mais bon ça change pas grand chose à ce niveau si l'action du post est séparée si ? Ah pardon, c'était une autre question

Je sais pas, si tout doit être sauvé au dernier moment je ferais ça en JS/ajax avec un seul gros formulaire DOM je pense.

Avec Django, ça se fait à coups de Form Wizards pour composer une série de forms en une séquence de vues.

Ouiii, Django machin nien nien nien.

 
avec symfony :  
j'ai des action différentes quand il s'agit du premier affichage du formulaire ( donc pré rempli avec d'eventuelles données présente en base ) ou d'un réaffichage ( données en base + données saisies par l'utilisateur )
concretement ça donne un truc comme ça  :

// pour l'action update 
$activite= Doctrine::getTable('Activite')->find($request->getParameter('id'));
$form = new ActiviteForm($activite);
$form->bind($request->getParamete('activite'):
if($form->isValid())
{
   $form->save();
}
 
//et sinon, ca reaffiche le formulaire avec les exceptions qui vont bien

Ça existe un micro-framework ultra léger/simple.

Mon besoin :

Gestion de formulaire (donc auto-remplissage lors de l'édition)
Micro-orm MySQL tout con, juste pour faciliter la manip des datas.

Habituellement, un micro-framework n'inclue que le routing/dispatching et à la limite des hooks pour le rendering de templates, la gestion des formulaires et le micro-ORM c'est géré par des libs externes. Genre phorms.

Je hais ce langage, à chaque fois je me fais avoir par ça :

class A{
  private $toto;
 
  function getToto(){
     return $this->toto
  }
}
 
class B{
 
 function __construct(){
   $this->toto = 'foo';
 }
}
 
$bar = new B;
 
echo $bar->getToto(); // NULL

Il pourrait pas péter au moins un warning ce con???????????

class A{
  private $toto;
 
  function getToto(){
     return $this->toto
  }
}
 
class B{
 
 function __construct(){
   $this->toto = 'foo';
 }
}
 
$bar = new B;
 
echo $bar->getToto(); // NULL

private ça pue du cul