2010-01-29 16 views
1

J'ai eu quelques 'problèmes' avec le générateur d'admin (version Propel). Le comportement de génération HTML entre la vue liste et la vue formulaire est très différent, et j'aimerais savoir pourquoi, car la vue formulaire fonctionne mieux (et comme prévu) par rapport à la vue liste.Comportement administrateur Symfony (Propel) - Pourquoi cela fonctionne-t-il de la sorte?

je l'YAML suivante pour l'action 'modifier',

edit: 
    actions: 
    custom: { confirm: 'Run this custom action?' } 
    _list: ~ 
    _save: ~ 

Cela génère le code HTML/PHP suivant pour l'action personnalisée spécifiée,

// Snip ... 
<li class="sf_admin_action_custom"> 
<?php if (method_exists($helper, 'linkToCustom')): ?> 
    <?php echo $helper->linkToCustom($form->getObject(), array( 'confirm' => 'Run this custom action?', 'params' => array(), 'class_suffix' => 'custom', 'label' => 'Custom',)) ?> 
<?php else: ?> 
    <?php echo link_to(__('Custom', array(), 'messages'), 'users/ListCustom?id='.$user->getId(), array()) ?> 
<?php endif; ?> 
</li> 
// Snip ... 

Maintenant, si j'ajoute mon habitude action à la YAML pour la vue de la liste,

list: 
    object_actions: 
    custom: { confirm: 'Run this custom action?' } 
    _edit: ~ 
    _delete: ~ 

je suis le code HTML suivant généré,

// Snip ... 
<li class="sf_admin_action_custom"> 
    <?php echo link_to(__('Custom', array(), 'messages'), 'users/ListCustom?id='.$user->getId(), array()) ?> 
</li> 
// Snip ... 

Là, il y a quelques différences distinctes ici que je trouve très étrange,

  1. Les contrôles sous forme de code d'actions pour voir s'il y a une méthode sur l'aide, et utilise le cas échéant, retombant à un fonction standard link_to() sinon. Cependant, le code des actions de liste utilise simplement la fonction link_to(), sans même essayer d'utiliser l'assistant.
  2. Le code d'actions de formulaire transmet mon message de confirmation personnalisé à la méthode d'assistance personnalisée, mais aucun des modèles ne la transmet au link_to(). Pourquoi est-ce? J'espère que c'est un bug.

Si quelqu'un pouvait expliquer pourquoi les deux génèrent différemment, je l'apprécierais vraiment.

Merci.

Répondre

0

Le générateur d'administration utilise des modèles qui génèrent le HTML/PHP ci-dessus. Le thème par défaut est situé à:

sfConfig::get('sf_symfony_lib_dir')/plugins/sfPropelPlugin/data/generator/sfPropelModule/admin/. (Version 1.2)

ou

$sf_symfony_data_dir/generator/sfPropelAdmin/default/ (version 1.0)

Le code HTML/PHP est différent parce que les modèles utilisés pour générer ces fichiers sont différents, mais vous pouvez les modifier à vos prédilections en créant votre propre thème et spécifiez que dans le generator.yml. .: par exemple

generator: 
    class: sfPropelGenerator 
    param: 
    model_class:   BlogArticle 
    theme:     customTheme 

Pour plus d'informations sur la façon de le faire, lisez http://www.symfony-project.org/book/1_2/14-Generators

+0

que je pouvais, et je suis maintenant, utilisez un générateur personnalisé. Cependant, il y a des bugs et des différences dans le thème par défaut pour des raisons que je n'arrive pas à comprendre. J'ai soumis un ticket sur le symfony trac. Cela me semble juste faux. –

+0

Bien que je ne pense pas que ce soit la bonne réponse, cela résout mon problème et c'est ce que je vais obtenir de plus proche. À votre santé. –