2010-06-18 4 views
0

Cela m'a battu. J'essaie de créer un tableau de champs dans cakePHP 1.2.5 & PHP 5.3.2 Le tableau est basé sur zéro. Sur la première itération, le nombre de $ == 0. Pour une raison quelconque la concaténation de chaîne semble convertir en nul ou unset qui gâteau interprète alors comme « nom du modèle insérer ici », à savoir:formulaire helper chaîne concat convertir zéro à unset dans cakephp

for($count=0;$count<$num;$count++) 
{ 
    echo $form->input($count.'.NodeDescriptor.title'); 
} 

<input name="data[NodeDescriptor][NodeDescriptor][title]" type="text" id="NodeDescriptorNodeDescriptorTitle" /> 
<input name="data[1][NodeDescriptor][title]" type="text" id="1NodeDescriptorTitle" /></div><tr><td><div class="input select"> 
... 

J'ai essayé lancer la valeur, la straver, des guillemets simples, des guillemets, des guillemets et {} en vain. Est-ce une fonctionnalité de PHP, un CakePHP unrobustness ou moi d'être stupide?

Répondre

1

J'ai rebasé le tableau à 1 et il fonctionne bien et comme prévu.

+0

Vous devriez déposer un ticket à ce sujet. Les erreurs d'index sonnent mal et si c'est un véritable bug, je mange humblement mes commentaires. –

+0

Cela semble être un bug. Il a été corrigé pour 1.3 et un scénario de test a été ajouté pour 1.2.7: http://cakephp.lighthouseapp.com/projects/42648/tickets/867-formhelper-string-concatenation-converting-zero-to-unset-in -cakephp – Leo

0

Pouvez-vous vous en tenir aux conventions de CakePHP et mettre le nom du modèle en premier, suivi de l'index?

echo $form->input('NodeDescriptor.'.$count.'.title'); 
+0

Quelle convention est-ce? Cela rendrait les données postées un peu plus difficiles à gérer dans le contrôleur. Je ne suis pas le seul à briser cette 'convention'. Chris Hartjes semble avoir la même idée: http://groups.google.co.uk/group/cake-php/browse_thread/thread/5822f70716e1c66d/b230b98f465fdacb?hl=fr&lnk=gst&q=dynamic+form+][#b230b98f465fdacb – Leo

+0

J'allais par le format attendu par la méthode 'saveAll()'. – Mike

+0

Je vois votre point et merci pour votre commentaire, mais j'utilise rarement saveAll(), et comme il a une utilisation limitée de toute façon (comme indiqué dans le livre) la structure des paramètres constitue à peine une convention. Cependant, rien de tout cela n'aboutit au nœud du problème, à savoir qu'une valeur d'index zéro est convertie en nom de modèle, tandis qu'une valeur non nulle conserve sa valeur numérique. Je suis à peu près sûr que ce n'est pas PHP. Je ne pense pas être bête, alors je suppose que ça doit être un bug dans CakePHP. Que je sois ou non censé le faire de cette façon, je peux, mais le comportement n'est pas cohérent. – Leo

1

En premier lieu, il est une convention que si vous les champs enregistrez mis en correspondance avec le même modèle et que vous voulez multiples db insère que le tableau de données doit être formaté comme Mike dit ci-dessus.

-à-dire le modèle {n } .field

vous pouvez voir clairement qu'ils explicitement dire que lorsque vous enregistrez le même nom de champ dans le même modèle à plusieurs reprises que cette est la convention comme le titre de la section du manuel est le nom « Naming Champ Conventions "

http://book.cakephp.org/view/1390/Automagic-Form-Elements#Field-naming-convention-1391

Vous ne pouvez pas vraiment appeler le problème d'entrée d'un bug CakePHP si la méthode d'entrée n'a pas été écrit pour vous accueillir en utilisant la méthode de façon non intentionnelle. La méthode scinde explicitement la chaîne passée sur le "." caractère et suppose que si vous utilisez une chaîne avec le "." Deuxièmement, lorsque je teste votre code à ma fin, il présente un bug légitime - il utilise les index numériques I attendre, mais les doublons ..

-à-dire [0] [0] [descripteur] [titre], 1 [descripteur] [title]

Lorsque je déplace l'index où la sauvegarde * fonctions attendent que ce soit , l'analyse est parfaite.

à savoir [descripteur] [0] [titre], Descriptor [titre]

Donc, si vous voulez utiliser les aides que vous devriez être de les utiliser dans la façon dont ils sont censés travailler. Ce n'est pas un bug si vous inventez votre propre casse qui n'était pas destiné à être supporté par l'assistant pour commencer. À en juger par votre exemple, il n'y a aucune raison de ne pas utiliser saveAll de toute façon. Avez-vous une raison de l'éviter? Cela semble être la bonne façon de faire ce que vous demandez.

** RÉVISÉ POUR FIXER BILLET http://cakephp.lighthouseapp.com/projects/42648/tickets/867 **

App ce que app/views/app_view.php

<?php 

App::import('View', 'View', false); 

class AppView extends View { 

    /** 
    * Constructor 
    * 
    * @param object $controller 
    */ 
    function __construct(&$controller){ 
      parent::__construct($controller); 
    } 

    /** 
    * Temporary View::entity fix for 1.2.5 
    * Returns the entity reference of the current context as an array of identity parts 
    * 
    * @return array An array containing the identity elements of an entity 
    * @access public 
    */ 
    function entity() { 
     $assoc = ($this->association) ? $this->association : $this->model; 
     if (!empty($this->entityPath)) { 
      $path = explode('.', $this->entityPath); 
      $count = count($path); 
      if (
       ($count == 1 && !empty($this->association)) || 
       ($count == 1 && $this->model != $this->entityPath) || 
       ($count == 2 && !empty($this->fieldSuffix)) || 
       is_numeric($path[0]) && !empty($assoc) 
      ) { 
       array_unshift($path, $assoc); 
      } 
      return Set::filter($path); 
     } 
     return array_values(Set::filter(
      array($assoc, $this->modelId, $this->field, $this->fieldSuffix) 
     )); 
    } 
} 
?> 

votre contrôleur d'utiliser la vue avec sa propriété publique de vue $.

<?php 
    class FooController extends Controller { 
     ... 
     ... 
     var $view = 'App'; 
     ... 
     ... 
    } 
?> 
+0

La convention à laquelle vous faites référence aussi explicitement _explicitly_ "... qui peut être sauvegardé en une seule fois avec saveAll() ...". J'ai de bonnes raisons de ne pas utiliser saveAll, que je n'ai pas besoin d'utiliser ici. On m'a toujours appris à coder pour toutes les exceptions, c'est-à-dire si un paramètre est incorrect, le manipuler. Mon exemple était nécessairement simpliste pour éviter d'obscurcir le problème que j'avais, alors n'en jugez pas. J'aurais pensé que si Chris Hartjes suggérait mon approche, alors ça devrait être bon de partir. Il était - et peut-être encore - un développeur principal chez CakeDC, après tout. – Leo

+0

Je ne comprends pas le bug que vous décrivez. Je ne comprends pas non plus pourquoi vous le décrivez comme un bug légitime (où le mien ne l'est pas) parce qu'il ne se comporte pas comme prévu tout en disant qu'il ne devrait pas être utilisé de cette façon. Une contradiction là-bas, sûrement? – Leo

+0

Je ne me suis pas référé au commentaire - I ** renvoyé à la documentation, que j'ai liée - sous la rubrique Formulaire Naming Conventions - * Deuxièmement, le bug que j'ai mentionné est une erreur d'analyse de chaîne - C'est un bug avec la classe String qui gère la conversion de "." chaînes séparées dans des chemins de tableau. La mienne arrive si j'utilise la classe directement ou par procuration via l'assistant de formulaire. Donc non, je ne pense pas être contradictoire. Vous voulez l'utiliser mal, cela fonctionne mal. Quant à Chris suggérant votre approche - c'est bien mais il * contredit directement les règles de nommage explicitement requises ... –