Discussion :

[wilsakovi]

Bonjour,
J'ai un probleme (bizard) aves les custom methods. Apres avoir genere des classes attachees a une nouvelle table, je constate que les methodes de base a (getColum(), retrieveByPk(), ...) fonctionnent bien sur les classes de base et classes personnalisees. Mais les methodes personnalisees que j'ajoute a aux classes personnalisees ne fonctionnent pas.
J'ai copie-coller les memes methodes dans une des anciennes classes personnalisees, elles fonctionnent bien.

je m'explique autrement par des exemples:
J'ai ajoute une nouvelle table nomme localite,
j'ai fait generer les classes lib/model/ (Localite.PHP, LocalitePeer.php), lib/model/om/ (BaseLocalite.PHP, BaseLocalitePeer.php).
J'ajoute la methode suivante a la classe LocalitePeer.php

Code php :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
public static function testFunction() {
$testValue = "I work";
return $testValue;
}

J'appelle

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

 LocalitePeer::testFunction();

dans modules/client/actions.class.php il NE repond PAS.
J'appelle

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

LocalitePeer::retriveByPk(2);

dans modules/client/actions.class.php il repond bien.
Je copie-coller le contenu de la method testFunction() dans lib/model/ItemPeer.php
J'appelle

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ItemPeer::testFunction());

dans modules/client/actions.class.php il repond bien.
Je ne comprends pas pourquoi

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

LocalitePeer::testFunction()

ne repond pas.

J'ai déjà mis assez de temps dessus mais je ne trouve pas de solution.

Merci pour votre aide.

SYmfony 1.0.7 on Linux

[Michel Rotta]

Symfony 1.0.7 avec Propel.... de très vieux souvenirs...

Déjà, j'essayerais de passer le tout en 1.3 avec le module de compatibilité, au moins tu aurais un framework relativement à jour, même si la dernière modification de la 1.3 date de ce début d'année et qu'il n'y en aura plus d'autre, c'est toujours mieux que la 1.0 qui n'est plus maintenue depuis plus de 2 ans.

Ensuite, je pense qu'il faudrait décortiquer le code de l'objet de base, bien que je ne vois pas trop comment, il semblerait qu'il intercepte la demande avant que l'enfant ne la voie arriver. En effet, la méthode retriveByPk() n'existe pas en elle même, elle est traitée dynamiquement.

[wilsakovi]

Comment est-il possible que la classe de base (ou une classe de parent) intercepte une demande et ne pas la(damande) faire arriver a ses enfants?

[Michel Rotta]

Et bien ... (air pensif et désolé)

Je dirais que c'est impossible.

Mais je ne vois aucune raison pour que tes méthodes static ne marchent pas.

Donc, je me dis qu'il doit bien y avoir un truc plus space que la normale.

Vérifie dans ton cache, je n'ai plus la structure en tête pour 1.0 mais tu devrais avoir un fichier utilisé par l'autoload qui reprend dans une table (array) les dossiers où chercher pour faire de l'autoload. Vérifie si tu n'as pas deux dossier qui contiendraient deux versions différentes de ton objet LocalitePeer. Tu prendrais le premier (non modifié par toi) et le deuxième (modifié par toi) ne serait, lui, jamais chargé.

C'est un peu plus crédible comme erreur que le parent qui prend le pas sur l'enfant.

[wilsakovi]

Je ne l'ai pas vu. Pouvez vous me donner une idee de ce que ressemble ce fichier (qui me rend la vie dificile)?

[Michel Rotta]

Non, désolé.

Je n'ai plus aucune application qui tourne en 1.0. En fait, je n'en ai jamais eu, les développements commencés à cette époque ayant tous migré sous 1.1 (et maintenant 1.4) avant de passer en exploitation.

Je ne sais plus comment est géré l'autoload en sf 1.0.

Une solution pourrait aussi être d'essayer de tout basculer en 1.3 avec le module de compatibilité sf 1.0.