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

New validation api #1904

Closed
wants to merge 177 commits into
base: master
from

Conversation

Projects
None yet
@jto

jto commented Oct 24, 2013

No description provided.

@mandubian

This comment has been minimized.

Show comment
Hide comment
@mandubian

mandubian Mar 11, 2014

Collaborator

So it would mean there would be :

  • an external lib called "something-json" containing only JSON AST + utils (zipper+interpolators)
  • an external lib called "something-validation" containing the new validation API for example?
  • an external lib called "something-json-validation" depending on both previous & maybe "something-form/xml-validation" (that could be put in "something-validation" as modules)

Finally, pickling is an interesting question... pickling is more at the level of jackson in some way. As you said, it's more about marshalling/unmarshalling than validating even if when you unmarshal, you also validate. But this validation is more structural. Yet, I believe we could create Rules macros based on Pickling instead of other libs like Jackson or XML or Form... maybe we could have a module "something-pickling-validation" as we will have "something-json-validation"...

The question after that is : how to do all of that ;)

Collaborator

mandubian commented Mar 11, 2014

So it would mean there would be :

  • an external lib called "something-json" containing only JSON AST + utils (zipper+interpolators)
  • an external lib called "something-validation" containing the new validation API for example?
  • an external lib called "something-json-validation" depending on both previous & maybe "something-form/xml-validation" (that could be put in "something-validation" as modules)

Finally, pickling is an interesting question... pickling is more at the level of jackson in some way. As you said, it's more about marshalling/unmarshalling than validating even if when you unmarshal, you also validate. But this validation is more structural. Yet, I believe we could create Rules macros based on Pickling instead of other libs like Jackson or XML or Form... maybe we could have a module "something-pickling-validation" as we will have "something-json-validation"...

The question after that is : how to do all of that ;)

@julienrf

This comment has been minimized.

Show comment
Hide comment
@julienrf

julienrf Mar 11, 2014

Contributor

I’m deviating from the original topic, but writing a scala-pickling backend for JsValue is definitely a good idea.
scala-pickling is not yet very mature but seems very promising.

Contributor

julienrf commented Mar 11, 2014

I’m deviating from the original topic, but writing a scala-pickling backend for JsValue is definitely a good idea.
scala-pickling is not yet very mature but seems very promising.

@jto

This comment has been minimized.

Show comment
Hide comment
@jto

jto Mar 11, 2014

Hi @jroper,

I think I could try to pull out the library out of play. This API has only a few dependencies on Play, hopefully the Job should be pretty easy.

I have one question though. Assuming the current form API is deprecated, and eventually removed from Play, most users would have to find something to replace it. If they're going to use this API (which is probably what most of them would do), they'll end up having not only both API (Json + Validation), but also a duplicated JSON AST. It seems like a less than ideal solution to me. What's your take on that ? Do you think there's a way to avoid the replication (maybe pulling out the Json AST)?

I'm also very interested in pickling, although I'm not familiar enough with it to tell if it makes sense to merge the two.

jto commented Mar 11, 2014

Hi @jroper,

I think I could try to pull out the library out of play. This API has only a few dependencies on Play, hopefully the Job should be pretty easy.

I have one question though. Assuming the current form API is deprecated, and eventually removed from Play, most users would have to find something to replace it. If they're going to use this API (which is probably what most of them would do), they'll end up having not only both API (Json + Validation), but also a duplicated JSON AST. It seems like a less than ideal solution to me. What's your take on that ? Do you think there's a way to avoid the replication (maybe pulling out the Json AST)?

I'm also very interested in pickling, although I'm not familiar enough with it to tell if it makes sense to merge the two.

@jto

This comment has been minimized.

Show comment
Hide comment
@jto

jto Mar 11, 2014

@jroper I started extracting the API here: https://github.com/jto/validation, and replicated the Json AST. It's missing the docs, but tests are green. It's also missing the Form helper, since it requires a few modifications in Play.

jto commented Mar 11, 2014

@jroper I started extracting the API here: https://github.com/jto/validation, and replicated the Json AST. It's missing the docs, but tests are green. It's also missing the Form helper, since it requires a few modifications in Play.

@jroper

This comment has been minimized.

Show comment
Hide comment
@jroper

jroper Mar 14, 2014

Member

Actually, my thought was that initially, this would depend on play-json, that way it could use the Play JSON AST, which would make it more convenient to use in Play. Eventually, the JSON AST will be moved out of Play and into this (or some completely different library).

I think only JsPath would need to be replicated, since you add some traits to it.

Member

jroper commented Mar 14, 2014

Actually, my thought was that initially, this would depend on play-json, that way it could use the Play JSON AST, which would make it more convenient to use in Play. Eventually, the JSON AST will be moved out of Play and into this (or some completely different library).

I think only JsPath would need to be replicated, since you add some traits to it.

@jroper

This comment has been minimized.

Show comment
Hide comment
@jroper

jroper Mar 14, 2014

Member

So just to explain the end goal, I think we should aim for something like this:

  • An external lib that contains just the JSON AST
  • An external lib for validation (would probably include the play-functional stuff)
  • An external lib that provided JSON + validation integration
  • Something in Play that provided forms + validation integration (could be outside of Play, but not sure how useful people would find it outside of Play)

As a first step to getting there, I think we should:

  • Have one JSON AST, that being in play-json
  • Keep play-functional where it is
  • Have an external lib that does validation that depends on play-functional. Maybe not strictly necessary that it depends on play-functional, but perhaps nicer to limit duplication now.
  • Have an external lib that integrations the validation with play-json AST. It probably will also need to provide things like an equivalent to Json.fromJson/toJson.
Member

jroper commented Mar 14, 2014

So just to explain the end goal, I think we should aim for something like this:

  • An external lib that contains just the JSON AST
  • An external lib for validation (would probably include the play-functional stuff)
  • An external lib that provided JSON + validation integration
  • Something in Play that provided forms + validation integration (could be outside of Play, but not sure how useful people would find it outside of Play)

As a first step to getting there, I think we should:

  • Have one JSON AST, that being in play-json
  • Keep play-functional where it is
  • Have an external lib that does validation that depends on play-functional. Maybe not strictly necessary that it depends on play-functional, but perhaps nicer to limit duplication now.
  • Have an external lib that integrations the validation with play-json AST. It probably will also need to provide things like an equivalent to Json.fromJson/toJson.
@jto

This comment has been minimized.

Show comment
Hide comment
@jto

jto Mar 14, 2014

Sounds like a plan :).
I'll continue working on the extracted version of the lib, it only depends on play-validation.

JsPath could be kept in it's current (master) state. I modified it hoping for backward compatibility, but looking back, I think it was a mistake. IMHO it's a lot cleaner if we just let it the way it is.

The only modification needed in play is the Form trait. It's not breaking anything, and gives us the opportunity to get rid of the old validation form API without losing the template helpers.

Concerning the Json AST, it's fairly easy to extract it. It currently have a bunch of methods related to Reads/Write, but they could be provided using implicit conversion.

For the rest, see my comments below:

  • Have one JSON AST, that being in play-json
    • @mandubian may be interested in extracting the AST ?
  • Keep play-functional where it is
    • Totally agree. It's already useable as a standalone lib.
  • Have an external lib that does validation that depends on play-functional. Maybe not strictly necessary that it depends on play-functional, but perhaps nicer to limit duplication now.
    • Appart from doc, we pretty much have that already here.
  • Have an external lib that integrations the validation with play-json AST. It probably will also need to provide things like an equivalent to Json.fromJson/toJson.
    • It's here There's already something similar to from/to Json in validation-core I can rewrite it the only have 1 explicit param on application.

I'll try to have a look at pickling. My first intuition is that we could start by providing an implicit Rule and a Write that uses pickle to marchal / unmarchal Array[Byte]. Basically it would replace Jackson for Json, and you'd use it like this way:

Rule.of[Array[Byte], Json] compose validationRule

Where of implicitly finds an instance of Rule[Array[Byte], Json]. That instance would be provided by something like:

def fromPickler[I: Unpickler, O]: Rule[I, O] =  ???

I'll try to do that for json and see where it goes.

Let me know if I can do more to help!

jto commented Mar 14, 2014

Sounds like a plan :).
I'll continue working on the extracted version of the lib, it only depends on play-validation.

JsPath could be kept in it's current (master) state. I modified it hoping for backward compatibility, but looking back, I think it was a mistake. IMHO it's a lot cleaner if we just let it the way it is.

The only modification needed in play is the Form trait. It's not breaking anything, and gives us the opportunity to get rid of the old validation form API without losing the template helpers.

Concerning the Json AST, it's fairly easy to extract it. It currently have a bunch of methods related to Reads/Write, but they could be provided using implicit conversion.

For the rest, see my comments below:

  • Have one JSON AST, that being in play-json
    • @mandubian may be interested in extracting the AST ?
  • Keep play-functional where it is
    • Totally agree. It's already useable as a standalone lib.
  • Have an external lib that does validation that depends on play-functional. Maybe not strictly necessary that it depends on play-functional, but perhaps nicer to limit duplication now.
    • Appart from doc, we pretty much have that already here.
  • Have an external lib that integrations the validation with play-json AST. It probably will also need to provide things like an equivalent to Json.fromJson/toJson.
    • It's here There's already something similar to from/to Json in validation-core I can rewrite it the only have 1 explicit param on application.

I'll try to have a look at pickling. My first intuition is that we could start by providing an implicit Rule and a Write that uses pickle to marchal / unmarchal Array[Byte]. Basically it would replace Jackson for Json, and you'd use it like this way:

Rule.of[Array[Byte], Json] compose validationRule

Where of implicitly finds an instance of Rule[Array[Byte], Json]. That instance would be provided by something like:

def fromPickler[I: Unpickler, O]: Rule[I, O] =  ???

I'll try to do that for json and see where it goes.

Let me know if I can do more to help!

@julienrf

This comment has been minimized.

Show comment
Hide comment
@julienrf

julienrf Mar 14, 2014

Contributor

What is the point of pulling the JSON algebraic data type out of the current play-json artifact? Why not keep it as it is and have a general validation library depending on nothing but eventually play-functional, and then a library integrating validation + JSON ?

Contributor

julienrf commented Mar 14, 2014

What is the point of pulling the JSON algebraic data type out of the current play-json artifact? Why not keep it as it is and have a general validation library depending on nothing but eventually play-functional, and then a library integrating validation + JSON ?

@jto

This comment has been minimized.

Show comment
Hide comment
@jto

jto Mar 14, 2014

@julienrf Because currently Json is 80% Validation and JsValue and Json have dependencies on Reads/Write and Jackson. Plus extracting it should be an easy job ;)

jto commented Mar 14, 2014

@julienrf Because currently Json is 80% Validation and JsValue and Json have dependencies on Reads/Write and Jackson. Plus extracting it should be an easy job ;)

@julienrf

This comment has been minimized.

Show comment
Hide comment
@julienrf

julienrf Mar 14, 2014

Contributor

Why not just deprecate the validation parts in the actual JSON API?

Contributor

julienrf commented Mar 14, 2014

Why not just deprecate the validation parts in the actual JSON API?

@jto

This comment has been minimized.

Show comment
Hide comment
@jto

jto Mar 14, 2014

We would eventually remove the deprecated part, and get to the same point. Let's do that immediately and not mix the new API with the deprecated API.

jto commented Mar 14, 2014

We would eventually remove the deprecated part, and get to the same point. Let's do that immediately and not mix the new API with the deprecated API.

@mandubian

This comment has been minimized.

Show comment
Hide comment
@mandubian

mandubian Mar 14, 2014

Collaborator

I would add that an external pure JSON library will allow to go far further
than current library in Play.
I'd like to integrate JsZipper, interpolators and maybe dynamic types and
lenses if they are needed.
There are other libraries like argonaut or json4s that do almost the same
but the strength of this json library would be that it's part of the
typesafe eco-system.
Moreover, I believe we could go further and make an abstraction of Jackson
parser in the JSON parser and allow to use alternatives like pickling...

On Fri, Mar 14, 2014 at 10:29 AM, Julien Richard-Foy <
notifications@github.com> wrote:

What is the point of pulling the JSON algebraic data type out of the
current play-json artifact? Why not keep it as it is and have a general
validation library depending on nothing but eventually play-functional, and
then a library integrating validation + JSON ?

Reply to this email directly or view it on GitHubhttps://github.com//pull/1904#issuecomment-37629526
.

Collaborator

mandubian commented Mar 14, 2014

I would add that an external pure JSON library will allow to go far further
than current library in Play.
I'd like to integrate JsZipper, interpolators and maybe dynamic types and
lenses if they are needed.
There are other libraries like argonaut or json4s that do almost the same
but the strength of this json library would be that it's part of the
typesafe eco-system.
Moreover, I believe we could go further and make an abstraction of Jackson
parser in the JSON parser and allow to use alternatives like pickling...

On Fri, Mar 14, 2014 at 10:29 AM, Julien Richard-Foy <
notifications@github.com> wrote:

What is the point of pulling the JSON algebraic data type out of the
current play-json artifact? Why not keep it as it is and have a general
validation library depending on nothing but eventually play-functional, and
then a library integrating validation + JSON ?

Reply to this email directly or view it on GitHubhttps://github.com//pull/1904#issuecomment-37629526
.

@jroper

This comment has been minimized.

Show comment
Hide comment
@jroper

jroper Mar 17, 2014

Member

The main reason why I'd like to keep JsValue in Play for now is to minimise impact on Play... we've got to keep the same package name (though type aliases in the play.api.libs.json package may help somewhat there).

The other reason is that, if nothing else, a shared JsValue library is definitely called for in Scala. The most controversial thing about it would be if we used Play's, then we get JsUndefined. Apart from that, it's pretty uncontroversial whose we use. So rather than a two step hop, into some external one and then into an official Scala one, I thought it would make more sense to do it in one step.

Member

jroper commented Mar 17, 2014

The main reason why I'd like to keep JsValue in Play for now is to minimise impact on Play... we've got to keep the same package name (though type aliases in the play.api.libs.json package may help somewhat there).

The other reason is that, if nothing else, a shared JsValue library is definitely called for in Scala. The most controversial thing about it would be if we used Play's, then we get JsUndefined. Apart from that, it's pretty uncontroversial whose we use. So rather than a two step hop, into some external one and then into an official Scala one, I thought it would make more sense to do it in one step.

@stanch stanch referenced this pull request Apr 6, 2014

Closed

JSON #5

@AhmedSoliman

This comment has been minimized.

Show comment
Hide comment
@AhmedSoliman

AhmedSoliman Apr 12, 2014

did this eventually come to a state where we can play with it? is the factored-out library ready somewhere? Can we do something to help?

AhmedSoliman commented Apr 12, 2014

did this eventually come to a state where we can play with it? is the factored-out library ready somewhere? Can we do something to help?

@jto

This comment has been minimized.

Show comment
Hide comment
@jto

jto commented Apr 14, 2014

@themodernlife

This comment has been minimized.

Show comment
Hide comment
@themodernlife

themodernlife May 3, 2014

Hi all,

This looks really interesting! I'm trying to look through the docs but I'm running into some build issues. I can compile the main project via sbt compile, but the documentation doesn't compile.

I'm trying to compile like this:

$ cd documentation
$ sbt -Dplay.version=2.3-SNAPSHOT run
[info] Loading global plugins from /Users/ihummel/.sbt/0.13/plugins
[info] Loading project definition from /Users/ihummel/Development/themodernlife/validation/documentation/project
[error] /Users/ihummel/Development/themodernlife/validation/documentation/project/Build.scala:5: object console is not a member of package play
[error] import play.console.Colors
[error]             ^
[error] /Users/ihummel/Development/themodernlife/validation/documentation/project/Build.scala:9: object Keys is not a member of package play
[error] import play.Keys._
[error]             ^
[error] /Users/ihummel/Development/themodernlife/validation/documentation/project/Build.scala:10: object SBTDocHandler is not a member of package play.core
[error] import play.core.{ SBTDocHandler, SBTLink, PlayVersion }
[error]        ^
[error] /Users/ihummel/Development/themodernlife/validation/documentation/project/DocValidation.scala:10: object console is not a member of package play
[error] import play.console.Colors
...

Note that I'm using a version of Play framework 2.3-SNAPSHOT pulled from master and published-locally. Seems like maybe some packages have been renamed (play.console.Colors?).

themodernlife commented May 3, 2014

Hi all,

This looks really interesting! I'm trying to look through the docs but I'm running into some build issues. I can compile the main project via sbt compile, but the documentation doesn't compile.

I'm trying to compile like this:

$ cd documentation
$ sbt -Dplay.version=2.3-SNAPSHOT run
[info] Loading global plugins from /Users/ihummel/.sbt/0.13/plugins
[info] Loading project definition from /Users/ihummel/Development/themodernlife/validation/documentation/project
[error] /Users/ihummel/Development/themodernlife/validation/documentation/project/Build.scala:5: object console is not a member of package play
[error] import play.console.Colors
[error]             ^
[error] /Users/ihummel/Development/themodernlife/validation/documentation/project/Build.scala:9: object Keys is not a member of package play
[error] import play.Keys._
[error]             ^
[error] /Users/ihummel/Development/themodernlife/validation/documentation/project/Build.scala:10: object SBTDocHandler is not a member of package play.core
[error] import play.core.{ SBTDocHandler, SBTLink, PlayVersion }
[error]        ^
[error] /Users/ihummel/Development/themodernlife/validation/documentation/project/DocValidation.scala:10: object console is not a member of package play
[error] import play.console.Colors
...

Note that I'm using a version of Play framework 2.3-SNAPSHOT pulled from master and published-locally. Seems like maybe some packages have been renamed (play.console.Colors?).

@jto

This comment has been minimized.

Show comment
Hide comment
@jto

jto May 5, 2014

hi @themodernlife. This work is being pulled out in a standalone library. It currently lives on it's repository: https://github.com/jto/validation. The documentation is currently broken, but the library itself works perfectly.

jto commented May 5, 2014

hi @themodernlife. This work is being pulled out in a standalone library. It currently lives on it's repository: https://github.com/jto/validation. The documentation is currently broken, but the library itself works perfectly.

@themodernlife

This comment has been minimized.

Show comment
Hide comment
@themodernlife

themodernlife May 5, 2014

Thanks @jto. Played with this over the weekend and got the docs building (PR sent). Can't wait to see what happens with this project, I really love the API.

themodernlife commented May 5, 2014

Thanks @jto. Played with this over the weekend and got the docs building (PR sent). Can't wait to see what happens with this project, I really love the API.

@sam

This comment has been minimized.

Show comment
Hide comment
@sam

sam May 8, 2014

"The other reason is that, if nothing else, a shared JsValue library is definitely called for in Scala."

@jroper It seems like there's a lot of (for lack of a better word) between Play/Akka/Spray teams. Why not just use spray-json for the JsValue library? It's a sore point to me that (because we're using Cloudant, which stores objects as JSON documents) I have two different JsValue systems in my project. The parsers/validators in Play's version seem like they could just as easily work with Spray's data-types.

Is this in the cards for a future release maybe?

sam commented May 8, 2014

"The other reason is that, if nothing else, a shared JsValue library is definitely called for in Scala."

@jroper It seems like there's a lot of (for lack of a better word) between Play/Akka/Spray teams. Why not just use spray-json for the JsValue library? It's a sore point to me that (because we're using Cloudant, which stores objects as JSON documents) I have two different JsValue systems in my project. The parsers/validators in Play's version seem like they could just as easily work with Spray's data-types.

Is this in the cards for a future release maybe?

@jroper

This comment has been minimized.

Show comment
Hide comment
@jroper

jroper May 8, 2014

Member

There are a few reasons why we can't just switch to spray-json's JsValue today.

  1. Spray's JsValue's are terrible to work with directly. They don't define a \ operator, for example.
  2. Spray's JsValue does not define a JsUndefined type. JsUndefined is useful in a number of ways, for example, it means that you can \ on a property that doesn't exist, without throwing an exception (used in combination with asOpt, this is quite nice).
  3. Spray's methods on JsValue do not provide a way to deserialise a JsValue without throwing an exception. This makes them much more clumsy to work with in Play's monadic view of Json parsing.

If you ask me, it should be the other way around, akka should dump spray-json in favour of play-json, and this will be the more likely thing to happen (or rather, play-json will be pulled out of Play to somewhere neutral, to be used by both).

Member

jroper commented May 8, 2014

There are a few reasons why we can't just switch to spray-json's JsValue today.

  1. Spray's JsValue's are terrible to work with directly. They don't define a \ operator, for example.
  2. Spray's JsValue does not define a JsUndefined type. JsUndefined is useful in a number of ways, for example, it means that you can \ on a property that doesn't exist, without throwing an exception (used in combination with asOpt, this is quite nice).
  3. Spray's methods on JsValue do not provide a way to deserialise a JsValue without throwing an exception. This makes them much more clumsy to work with in Play's monadic view of Json parsing.

If you ask me, it should be the other way around, akka should dump spray-json in favour of play-json, and this will be the more likely thing to happen (or rather, play-json will be pulled out of Play to somewhere neutral, to be used by both).

@sam

This comment has been minimized.

Show comment
Hide comment
@sam

sam May 9, 2014

I've found spray-json really nice for "strict" protocols (we use CouchDB so the JSON we send back and forth needs to be reasonably strict or it'd generate a lot of extra work in queries and such). The big deal for me is composing Formats and the case class helpers. You can serialize/deserialize some fairly complex hierarchies with really very little code.

But I thought it was just a question of the base types and possibly extractors. I'd (probably incorrectly) assumed the parsing and pathing stuff was in play-functional and could work with the Spray types with minor modification.

Probably not really the place for it, but incidentally, I find the play-json functional stuff very "magical" in a way that reminds me of some Ruby libraries (and not in a good way). To be fair I don't know it very well so maybe it's just a knee-jerk defense mechanism over frustrations with "it reads like English!" APIs.

sam commented May 9, 2014

I've found spray-json really nice for "strict" protocols (we use CouchDB so the JSON we send back and forth needs to be reasonably strict or it'd generate a lot of extra work in queries and such). The big deal for me is composing Formats and the case class helpers. You can serialize/deserialize some fairly complex hierarchies with really very little code.

But I thought it was just a question of the base types and possibly extractors. I'd (probably incorrectly) assumed the parsing and pathing stuff was in play-functional and could work with the Spray types with minor modification.

Probably not really the place for it, but incidentally, I find the play-json functional stuff very "magical" in a way that reminds me of some Ruby libraries (and not in a good way). To be fair I don't know it very well so maybe it's just a knee-jerk defense mechanism over frustrations with "it reads like English!" APIs.

@jroper

This comment has been minimized.

Show comment
Hide comment
@jroper

jroper May 12, 2014

Member

play-functional can easily (for some value easy...) be applied to other types, but that's not the only way that people use play-json, some people use the much more imperative \ style of parsing/data extraction, this is not provided by play-functional.

Magical means very different things to different people. The power of type systems can be quite magical to newcomers. But the difference between play-json and ruby libraries, is in Play JSON, the type system is completely transparent, and the behaviour of your code can be completely derived from it. If it compiles, then you know it does exactly how it reads (assuming you know how the type system should read). The behaviour of your code in Ruby libraries though can only be determined by reading the source code of the Ruby libraries, to see how they reflect on runtime types. In this sense, Ruby is at one extreme, very magical, lots of hidden details, providing the illusion of something that works as it reads, while play-json is at the other, completely transparent, since what you read is what you get.

Member

jroper commented May 12, 2014

play-functional can easily (for some value easy...) be applied to other types, but that's not the only way that people use play-json, some people use the much more imperative \ style of parsing/data extraction, this is not provided by play-functional.

Magical means very different things to different people. The power of type systems can be quite magical to newcomers. But the difference between play-json and ruby libraries, is in Play JSON, the type system is completely transparent, and the behaviour of your code can be completely derived from it. If it compiles, then you know it does exactly how it reads (assuming you know how the type system should read). The behaviour of your code in Ruby libraries though can only be determined by reading the source code of the Ruby libraries, to see how they reflect on runtime types. In this sense, Ruby is at one extreme, very magical, lots of hidden details, providing the illusion of something that works as it reads, while play-json is at the other, completely transparent, since what you read is what you get.

@julien-lafont

This comment has been minimized.

Show comment
Hide comment
@julien-lafont

julien-lafont Jul 22, 2014

Is there any news on this subject?

julien-lafont commented Jul 22, 2014

Is there any news on this subject?

@benmccann

This comment has been minimized.

Show comment
Hide comment
@benmccann

benmccann Aug 16, 2014

Contributor

@jto there are merge conflicts

Contributor

benmccann commented Aug 16, 2014

@jto there are merge conflicts

@jto

This comment has been minimized.

Show comment
Hide comment
@jto

jto Aug 18, 2014

@benmccann The PR is 10 months old, one would expect merge conflicts... From what I understand, the API is now expected to live as standalone project, which it is: https://github.com/jto/validation. I'll publish v1 in a few days. There's been some discussions at some point about json4s, which is now supported.

I didn't have updates about the status of this project from you guys for monthes, so I've more or less renounced to see this work integrated in play at some point...

jto commented Aug 18, 2014

@benmccann The PR is 10 months old, one would expect merge conflicts... From what I understand, the API is now expected to live as standalone project, which it is: https://github.com/jto/validation. I'll publish v1 in a few days. There's been some discussions at some point about json4s, which is now supported.

I didn't have updates about the status of this project from you guys for monthes, so I've more or less renounced to see this work integrated in play at some point...

@graphex

This comment has been minimized.

Show comment
Hide comment
@graphex

graphex Nov 5, 2014

Would really be great to revisit this and see if this validation project can become the best practice validation library to be used in Play. A web framework without a robust and consistent validation system for JS/Forms/XML seems ludicrous, but that seems to be where Play stands right now if you look at it as a new arrival to the ecosystem. Disparate APIs for JSON request validation vs. Form validation smell pretty bad.

graphex commented Nov 5, 2014

Would really be great to revisit this and see if this validation project can become the best practice validation library to be used in Play. A web framework without a robust and consistent validation system for JS/Forms/XML seems ludicrous, but that seems to be where Play stands right now if you look at it as a new arrival to the ecosystem. Disparate APIs for JSON request validation vs. Form validation smell pretty bad.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Dec 1, 2014

What is the plan for this ?

ghost commented Dec 1, 2014

What is the plan for this ?

@jroper

This comment has been minimized.

Show comment
Hide comment
@jroper

jroper Dec 2, 2014

Member

The plan is that this is now an external library that can be used with Play:

https://github.com/jto/validation

Due to the breaking changes in both the JSON and the form APIs, and because we're considering moving to json4s which is another big breaking change, Play's own validation API likely won't be deprecated in favour of using this until Play 3.

Member

jroper commented Dec 2, 2014

The plan is that this is now an external library that can be used with Play:

https://github.com/jto/validation

Due to the breaking changes in both the JSON and the form APIs, and because we're considering moving to json4s which is another big breaking change, Play's own validation API likely won't be deprecated in favour of using this until Play 3.

@jroper jroper closed this Dec 2, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment