Доступ к данным в валидации коаны - PullRequest
Новая
       12

Доступ к данным в валидации коаны

0 голосов
/ 10 июля 2010

Я постараюсь быть максимально понятным.

Я работаю над проверкой формы, используя замечательный фреймворк кохана.Однако я попал на перепутье и не уверен, является ли мой выбор мудрым выбором.

По сути, у меня есть селектор даты, использующий несколько полей выбора (я играл с идеей использования средств выбора даты в JavaScript, нополя выбора оказались более подходящими для моей цели) и поле даты в базе данных.Я хотел объединить эти поля выбора в поле даты, чтобы его можно было проверить, чтобы убедиться, что он действителен.

protected $_rules = array(
    'mydate'        => array(
        'not_empty'       => NULL,
         'date'           => NULL,
     ),
);

Теперь для меня наиболее разумно включить проверку в модель, поскольку именно здесь слой данных находится в шаблоне MVC, поэтому я решил создать некоторые атрибуты класса с именем $ _rules, $_filters и $ _callbacks, каждый из которых установлен как защищенный и с применением моих основных правил.И затем функция в модели, которая устанавливает объект проверки с использованием этих атрибутов и возвращает его любому вызывающему контроллеру, затем контроллер может просто выполнить проверку и задание выполнено.

Моя проблема возникает, когда я хочу объединить эти блоки выбора, для меня наиболее целесообразно создать собственный фильтр и передать данные поста, но с правилами фильтров и обратными вызовами, являющимися атрибутами, я не могудобавить любые переменные к ним.Мое текущее решение состоит в том, чтобы вручную добавить дополнительный фильтр, когда функция настройки проверки запускается примерно так: 

public function setupValid($post) {
    $this->_filters['mydatefield'] = array(
        'MyClass::MyConcat'    =>   array($post);
    );

    //creates a validation object and adds all the filters rules and callbacks
}

Но я не думаю, что это самое чистое решение, я, наверное, невыбирая как решение работает так, как мне нужно.Однако я не уверен, был ли фильтр когда-либо предназначен для такой вещи, или это должен быть обратный вызов, так как обратный вызов имеет доступ к массиву по умолчанию, но опять же обратные вызовы вызываются последними, что будет означать, что яне может применять какие-либо правила, например, not_empty (в данном случае это не важно, поскольку они предварительно заполнены полями выбора, но могут быть и в другом случае)

Так что я думаю, что мой вопрос: использую ли я фильтрыони были предназначены для использования?

Надеюсь, мне удалось объяснить это ясно.

Спасибо

1 Ответ

2 голосов
/ 10 июля 2010

вам нужно помнить, что вы должны проверять только те поля внутри $ _rules, которые очень важны для вашей базы данных или бизнес-логики.

Так, например, если вы попытаетесь настроить другую форму где-то еще в вашем приложении или вы предоставите API-интерфейс restfull для вашего приложения, проверка поля 'day_field_(that_doesnt_exists_in_the_database_and_is_used_to_privide_a_better_ux_in_this_one_form)' => array('not_empty' => NULL) затруднит вам это.

поэтому я предлагаю вам сохранить ваши $ _rules такими, как они есть сейчас, и предоставить некоторую логику для вашего метода values ​​(): 

// MODEL:
public function values($values)
{
    if ( ! empty($values['day']) && ! empty($values['month']) && ! empty($values['year']))
    {
        $values['mydate'] = $values['year'].'-'.$values['month'].'-'.$values['day'];
    }

    return parent::values($values);
}


// CONTROLLER:
if ($orm->values($form['form_array'])->check())
{
    $orm->save();
}
else
{
    $this->template->errors = $orm->validate()->errors('validation');
}
...