Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Validation: referring to other fields #1

Open
pbrant opened this issue Jan 16, 2015 · 2 comments
Open

Validation: referring to other fields #1

pbrant opened this issue Jan 16, 2015 · 2 comments

Comments

@pbrant
Copy link

pbrant commented Jan 16, 2015

ML thread here: https://groups.google.com/forum/#!topic/liftweb/KeIJt01L20A

@Shadowfiend
Copy link
Member

To expand on this a bit, you can currently assign fields to a variable and refer to them:

val username = field[String](".username")
val password = field[String]("type=password") ? { newPassword =>
  if (username.value == Full("shadowfiend") && newPassword != "password") {
    Full("Shadowfiend can only have an insecure password.")
  } else {
    Empty
  }
}

However, the key here is that username.value will only be set if the username field
is submitted before the password field in the source form—so that's not ideal. We need
to decouple validation from value deserialization so that you can do the above; however,
the issue there becomes that you might look up the value of the username field even
though it's invalid (because if we don't run validation, the value will be Full instead of
Failure).

So maybe we do need a way to declare interdependencies or something of the sort.

@Shadowfiend
Copy link
Member

Btw, field groups offer a way of dealing with this issue now. You can use fieldGroup(field1, field2, ...) to build a group, and then invoke .withConverter or .withBoxedConverter to provide a function that reifies the group of fields into a single value with additional validations run. More on field groups in the relevant part of the README.

We're using these at Elemica now, though there are still some annoyances around reporting the errors back to the client in these cases, which I've captured in #17.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants