Projet

Général

Profil

Actions

Anomalie #17

fermé

Longueur du champ site web insuffisant

Ajouté par Denis LIARD il y a plus de 14 ans. Mis à jour il y a plus de 14 ans.

Statut:
Fermé
Priorité:
Normal
Version cible:
Début:
28/04/2010
Echéance:
% réalisé:

100%

Temps estimé:
Version ProxyEPN:

Description

Log : animateur
Fenêtre : administration/EPN/Modif
Objet : la longueur du champ site web est actuelement calée à 50 caractères, ce qui semble insuffisant pour certains sites. L'étendre à 255 caractères.

Mis à jour par Denis LIARD il y a plus de 14 ans

  • Version cible mis à EpnAdmin-CTN 1.1

Mis à jour par Grégory MARIGOT - TEICEE il y a plus de 14 ans

  • Statut changé de Nouveau à In Progress
  • % réalisé changé de 0 à 50

La valeur max pour le contrôle se trouve dans le fichier lib/form/base/BaseStructureForm.class.php
Si j'ai bien compris, tous les fichiers php se trouvant dans lib/form/base/ sont générés automatiquement lors du déploiement de l'applicatif à partir des structures des tables de la base données.

TODO :
- Modifier dans la table sql 'structure' le champs 'url' de varchar(50) à varchar(255)
- Voir comment doit être répercutée cette modification lors de la mise à jour de la version de prod : le fichier lib/form/base/BaseStructureForm.class.php est-il regénérable sans soucis ou vaut-il mieux l'éditer ?

Note :
- Augmenter également la taille pour les adresses email (50 actuellement)

Mis à jour par Marc CARLUCCI il y a plus de 14 ans

Pour mettre a jour la structure de la base de donnees:

1. Mis a jour du schema de la BdD

nano config/schema.xml

2. Generation des classes

php symfony propel:build-model
php symfony propel:build-sql
php symfony propel:build-forms

Mis à jour par Grégory MARIGOT - TEICEE il y a plus de 14 ans

  • % réalisé changé de 50 à 70

Mise à jour de la BdD et du schema.xml sur le serveur svn (r242).

Par contre, je dois avoir un soucis à l'exécution des commandes pour regénérer les classes, car au final je n'ai qu'un seul fichier qui est recréé (lib/model/om/BaseStructureGroupPeer.php) !

Ca bloque peut-être sur cette commande :

[root@papeete trunk]# php symfony propel:build-model
>> schema    converting "/mnt/mirror/trunk/p...lugin/config/schema.yml" to XML
>> schema    putting /mnt/mirror/trunk/plugi...erated-sfGuardPlugin-schema.xml
>> file+     config/generated-sfGuardPlugin-schema.xml
>> file-     /mnt/mirror/trunk/plugins/sfGua...erated-sfGuardPlugin-schema.xml
Buildfile: /mnt/mirror/trunk/lib/symfony/plugins/sfPropelPlugin/lib/vendor/propel-generator/build.xml
[resolvepath] Resolved /mnt/mirror/trunk/config to /mnt/mirror/trunk/config

propel-project-builder > check-project-or-dir-set:

propel-project-builder > check-project-set:

propel-project-builder > set-project-dir:

propel-project-builder > check-buildprops-exists:

propel-project-builder > check-buildprops-for-propel-gen:

propel-project-builder > check-buildprops:

propel-project-builder > configure:
     [echo] Loading project-specific props from /mnt/mirror/trunk/config/propel.ini
 [property] Loading /mnt/mirror/trunk/config/propel.ini

propel-project-builder > om:
    [phing] Calling Buildfile '/mnt/mirror/trunk/lib/symfony/plugins/sfPropelPlugin/lib/vendor/propel-generator/build-propel.xml' with target 'om'
 [property] Loading /mnt/mirror/trunk/lib/symfony/plugins/sfPropelPlugin/lib/vendor/propel-generator/./default.properties

propel > check-run-only-on-schema-change:

propel > om-check:

propel > om:
     [echo] +------------------------------------------+
     [echo] |                                          |
     [echo] | Generating Peer-based Object Model for   |
     [echo] | YOUR Propel project! (NEW OM BUILDERS)!  |
     [echo] |                                          |
     [echo] +------------------------------------------+
[phingcall] Calling Buildfile '/mnt/mirror/trunk/lib/symfony/plugins/sfPropelPlugin/lib/vendor/propel-generator/build-propel.xml' with target 'om-template'
 [property] Loading /mnt/mirror/trunk/lib/symfony/plugins/sfPropelPlugin/lib/vendor/propel-generator/./default.properties

propel > om-template:
[propel-om] Target database type: mysql
[propel-om] Target package: lib.model
[propel-om] Using template path: /mnt/mirror/trunk/lib/symfony/plugins/sfPropelPlugin/lib/vendor/propel-generator/templates
[propel-om] Output directory: /mnt/mirror/trunk
[propel-om] Processing: schema.xml
[propel-om] Processing: generated-sfGuardPlugin-schema.xml
[propel-om] Processing Datamodel : JoinedDataModel
[propel-om]   - processing database : propel
[propel-om]     + structure_group
[propel-om]         -> BaseStructureGroupPeer [builder: SfPeerBuilder]
[propel-om]         -> BaseStructureGroup [builder: SfObjectBuilder]
[phingcall] Unable to return 'affix' for unknown CreoleType: 

BUILD FINISHED

Total time: 0.2605 seconds
>> file-     /mnt/mirror/trunk/config/generated-sfGuardPlugin-schema.xml
>> autoload  reloading autoloading

Mais je n'ai pas la moindre idée du problème...

Question subsidiaire : La présence de fichiers dans plugins/sfGuardPlugin/lib/form/base/ sur le svn est-elle normale ?

Mis à jour par Grégory MARIGOT - TEICEE il y a plus de 14 ans

  • Statut changé de In Progress à Résolu
  • Assigné à mis à Grégory MARIGOT - TEICEE
  • % réalisé changé de 70 à 100

Le problème rencontré précédement à la génération des classes a été résolu en patchant le plugin sfPropelPlugin de la version de Symfony utilisée (1.1.7) pour le rendre compatible avec PHP 5.3 (utilisé sur la plateforme de test) :

--- lib/symfony/plugins/sfPropelPlugin/lib/vendor/creole/CreoleTypes.php    (révision 29635)
+++ lib/symfony/plugins/sfPropelPlugin/lib/vendor/creole/CreoleTypes.php    (copie de travail)
@@ -36,7 +36,7 @@
         const INTEGER = 5;
         const CHAR = 6;
         const VARCHAR = 7;
-        const TEXT = 17;
+        const TEXT = 30; //php 5.3.0 fix, using an unused int (old: TEXT = 17)
         const FLOAT = 8;
         const DOUBLE = 9;
         const DATE = 10;

Cf http://www.alexfilatov.com/2009/12/09/symfony-unable-to-return-affix-for-unknown-creoletype/

Note: Le framework Symfony étant embarqué avec EpnAdmin, mais en référence externe sur le dépôt SVN (svn d'origine), le patch ne peut être remonté et doit être appliqué à l'installation.

La question complémentaire sur la pertinence des classes générées de plugins/sfGuardPlugin/lib/form/base/ sur le svn a été réglé en les supprimant du dépôt (r258 et r259)

Mis à jour par Grégory MARIGOT - TEICEE il y a plus de 14 ans

  • Statut changé de Résolu à Fermé
Actions

Formats disponibles : Atom PDF