0

У меня есть две модели:Как подтвердить поле пароля, используя привязку класса ключевого слова play?

case class User(uid: Option[Int], email: String, password: String, created_at: Timestamp, updated_at: Timestamp) 

case class UserProfile(firstname: String, lastname: String, gender: Int, user_id: Int) 

Я связывающие его в том виде, в контроллере:

val date = new Date() 
    val currentTimestamp= new Timestamp(date.getTime()); 
    val registerForm = Form(
    tuple(
      "user" -> mapping(
      "uid" -> optional(number), 
      "email" -> email, 
      "password" -> nonEmptyText, 
      "created_at" -> ignored(currentTimestamp), 
      "updated_at" -> ignored(currentTimestamp) 
     ) (User.apply)(User.unapply).verifying("Email already exists.", fields => fields match { 
      case user => { 
       val result = userDao.findByEmail(user.email) 
       !result.isDefined 
      } 
      }), 
     "profile" -> mapping(
      "firstname"->nonEmptyText, 
      "lastname"->nonEmptyText, 
      "gender" -> ignored(0), 
      "user_id" -> ignored(0) 
     )(UserProfile.apply)(UserProfile.unapply)) 
    ) 

Как я мог иметь поле для ввода пароля подтверждения в виде связанного приложения? Я не могу его использовать в модельном классе, поскольку я использую его для своих операций DAO Slick, и не стоило бы иметь еще одно поле со схожими характеристиками.

Благодаря

+0

Я считаю, что у вас здесь два случая использования: один для создания пользователей, а один - для представления пользователя через ваше приложение. Поэтому я бы предложил вам разделить его: создать специальный класс case для создания пользователя и сохранить User и UserProfile для представления вашего пользователя в вашем приложении –

+0

@LouisF. да, я думал об этом, но не будет ли это против принципа DRY? – Maverick

+0

Я думаю, что вы не представляете одну и ту же информацию дважды: в одной руке вы хотите представить, что вы хотите создать пользователя, с другой стороны, вы хотите представлять пользователя. Я считаю, что это путь, иначе это приведет к неуклюжим хакам (вы уже можете наблюдать это с помощью '' '" created_at "-> ignored (currentTimestamp)' ''). Я думаю, вы должны попытаться представить в своих типах ваше намерение. –

ответ

1

я согласен с Луи F. выше, вы должны отделить получение пользовательских данных от настойчивости. вы могли бы иметь DTO:

case class UserData(email: String, password: String, passwordCheck: String) 

и использовать verifying так же, как вы делаете выше, чтобы гарантировать, что password == passwordCheck (поэтому форма только связывает, если они совпадают). то я хотел бы добавить к объекту User компаньона:

object User { 
    def apply(data: UserData): User = User(None, data.email, data.password, ...) 
} 

отмечает, что fields match { case user => ... } просто переименовывает эталонное «поле», чтобы «пользователь» и может быть сведена к телу саза.

+0

Где должен находиться объект-компаньон? В моделях.scala? – Maverick

+0

объекты-компаньоны должны находиться в том же файле, что и ваше определение класса (подробнее: http://docs.scala-lang.org/tutorials/tour/singleton-objects.html) – handler

+0

Спасибо за ваше решение – Maverick

 Смежные вопросы

  • Нет связанных вопросов^_^