symfony 管理生成器表单对象答案

【问题标题】：symfony admin generator form objectsymfony 管理生成器表单对象
【发布时间】：2011-05-26 12:43:14
【问题描述】：

大家好，我已将 Symfony admin generator 用于模块。

一切正常，但是当我的模型的表单被实例化时，我需要传入我自己的选项。

我可以自己通过覆盖 myModuleActions.class.php（扩展 myModuleAutoActions）中的 executeNew、executeCreate 函数来实现。

但我希望有一个更简洁的解决方案？

也许重写其中一个配置类是可行的方法。我基本上需要将当前的sf_user 对象（$this->getUser）添加为表单的“sf_user”选项，以避免在myModuleForm 中使用sfContext。

有什么想法吗？

【问题讨论】：

覆盖 myModuleGeneratorConfiguration 中的“sfModelGeneratorConfiguration::getForm”方法可以工作，但仍然需要我使用 sfContext 来获取当前的 sf_user 对象

标签： php forms symfony1 admin-generator

【解决方案1】：

欢迎来到 Stack Overflow，jolly18。

我只会使用 sfContext。例如，在我的应用程序中，我有一个子表单，它创建一个新的 Note 对象并将用户分配给它。在我的表单configure() 中，我有：

$new_note->setAuthor(sfContext::getInstance()->getUser()->getUsername());

我看到the book calls this "The fastest but ugly way" 是因为它使“表单和上下文之间存在很大的耦合，使测试和可重用性变得更加困难”。但在实践中......这很好，我可以继续前进。

【讨论】：

【解决方案2】：

如果模块是使用 admin-generator 生成的：

在apps/backend/modules/books/actions/actions.class.php

修改：在

executeEdit(){

//leave rest unchanged

$values=array('activity_id'=>$activity_id, 'book_id'=>$book_id, 'todo_id'=>$todo_id, 'user_id'=>$this->getUser()->getGuardUser()->getId());


    $this->form = new TabelBooksForm($TabelBooks, $values);
}

修改：在

executeNew(){

//leave rest unchanged

$values=array('activity_id'=>$activity_id, 'book_id'=>$book_id, 'todo_id'=>$todo_id, 'user_id'=>$this->getUser()->getGuardUser()->getId());

    $this->form = new TabelBooksForm(array(), $values);
}

在 TabelBooksForm.class.php 中

public function configure()
  {

   if ($this->isNew()) {
    $this->setWidget('book_id', new sfWidgetFormInputHidden());
    $this->setDefault('book_id', $this->getOption('book_id'));    

    $this->setWidget('activity_id', new sfWidgetFormInputHidden());
    $this->setDefault('activity_id', $this->getOption('activity_id'));    

    $this->setWidget('todo_id', new sfWidgetFormInputHidden());
    $this->setDefault('todo_id', $this->getOption('todo_id'));  
  }
}

【讨论】：

【解决方案3】：

我遇到这个问题已经有一段时间了，但 symfony 总是用一些我不知道的简洁代码让我感到惊讶。

我假设您使用的是 sfPropelPlugin，非常标准，如果您检查缓存中生成的代码（注意：一旦您尝试从浏览器打开模块，此代码将可用，所以首先尝试查看它，所以我们不要惹麻烦：P）你可能会看到类似的东西：

cache/{application_name}(generally frontend or backend)/dev(enviromnemt)/autoModule_name( look here for the module)/:

库
动作

action 文件夹包含一个 action.class.php 文件，该文件定义了生成器生成的所有操作（executeNew、Edit、Create、Update 等）。如果你看一下 executeNew 和 executeEdit 的实现，你可以看到他们要求一个配置实例来显示实际的表单，这里是一个例子：

  public function executeNew(sfWebRequest $request)
  {
    $this->form = $this->configuration->getForm();
    $this->PaymentOrder = $this->form->getObject();
  }

配置变量包含我前面提到的 lib 文件夹中定义的配置类的实例。该类调整表单以适应对象需求（通常通过设置新的对象实例）。

所以神奇的是，您在模块中看到的类是从缓存中的类扩展而来的，所以按照纯逻辑，如果您修改主模块/lib 文件夹中的 getForm() 方法以满足您的需求，您将不会拥有通过在不应该的地方获取用户评估器来破解表单。

希望这会有所帮助！

【讨论】：