partial functions matchers, routes with global context params

[pbuszka]

The PF idea we discussed on gitter had some implications I didn't anticipated. Route's encode and matchPage both are total functions. At the moment the methods which construct the Route instances guarantee consistency between Page actual type and the route matching function logic. With PFs it is very easy to construct something that sooner or later requires an ugly asInstanceOf[] in encode to satisfy type checker. The solution I implemented is to replace encode and matchPage in Route private constructor with a single PF which performs task of matchPage and encode at the same time.

matchPagePF: PartialFunction[Any, Args]

The external object Route creation functions won't change thier signatures. The only breaking change is the function argsFromPage but I can't find any usage of it in the whole github :) It returns now an Option[Args] instead of Args which is better IMHO.

Both encode and matchPage are used only in the implementation of relativeUrlForPage which becomes

  def relativeUrlForPage(page: Any): Option[String] = {
    matchPagePF.andThen(Some(_)).applyOrElse(page, (_: Any) => None).map(createRelativeUrl)
  }

In CollectPageRenderer CollectPageSignalRenderer I removed type constraint which was unnecessary and conflicting with PF usage.

I included as well ContextRoute which I adapted from my project. It uses PF mechanism to easily generate global route context in url params (ie. language chooser, current business). The tests in ContextRouterSpec.scala show how to use it. My goal was to be able to separate the two concerns. Otherwise those context data would have to be included in each and every class representing pages increasing the boilerplate significantly.

[raquo]

Thanks, looking into it. Good idea with the global context thing.

I'm gonna make a bunch of changes to this branch.

[raquo]

@pbuszka Could you please check that the latest commit works for you? Will need minor source changes in your code to compile.

I have changed and renamed quite a few things but the basic idea is the same and the API is almost the same.

Some of the API changes off the top of my head:

• I used constructor params instead of the typeclass because I try to avoid requiring knowledge of advanced language features in my libraries. Easier for those just learning Scala. Seems like the right tradeoff here.
• I made the Route's decode param a partial function too, because otherwise the users would be very limited in how they could use matchEncode. The route needs to decode the same set of args as the set of pages that it can encode, otherwise you'd get a route that can decode a page but can't encode it again, which is not what we want
• Simplified collectStaticPF method signature and the underlying CollectPageRenderer class