From b5cdc9d91c5582a26a6d2e2c8e81b67c593d14ac Mon Sep 17 00:00:00 2001 From: Li Haoyi Date: Wed, 4 Feb 2015 09:11:44 -0800 Subject: second pass at updating cross-built chapters for 0.6.0 --- .../scalatex/book/handson/ClientServer.scalatex | 23 ++++++++++------------ .../book/handson/PublishingModules.scalatex | 13 ++++++------ examples/crossBuilds/simple/jvm/shared | 1 - 3 files changed, 17 insertions(+), 20 deletions(-) delete mode 120000 examples/crossBuilds/simple/jvm/shared diff --git a/book/src/main/scalatex/book/handson/ClientServer.scalatex b/book/src/main/scalatex/book/handson/ClientServer.scalatex index f79c4b5..50f9850 100644 --- a/book/src/main/scalatex/book/handson/ClientServer.scalatex +++ b/book/src/main/scalatex/book/handson/ClientServer.scalatex @@ -26,22 +26,19 @@ @sect{A Client-Server Setup} @p - Getting started with client-server integration, let's go with the simplest configuration possible: a Spray server and a Scala.js client. Most of the other web-frameworks (@lnk.misc.Play, @lnk.misc.Scalatra, etc.) will have more complex configurations, but the basic mechanism of wiring up Scala.js to your web framework will be the same. Our project will look like this: + Getting started with client-server integration, let's go with the simplest configuration possible: a Spray server and a Scala.js client. Most of the other web-frameworks (@lnk.misc.Play, @lnk.misc.Scalatra, etc.) will have more complex configurations, but the basic mechanism of wiring up Scala.js to your web framework will be the same. Just like our project in @sect.ref{Cross Publishing Libraries}, our project will look like this: @hl.bash $ tree . ├── build.sbt - ├── client - │   ├── shared/main/scala/simple/FileData.scala - │   └── src/main/scala/simple/Client.scala - ├── project - │   └── build.sbt - └── server - ├── shared -> ../client/shared - └── src/main/scala/simple - ├── Page.scala - └── Server.scala + ├── project/build.sbt + └── app +    ├── shared/src/main/scala/simple/FileData.scala +    ├── js/src/main/scala/simple/Client.scala +    └── jvm/src/main/scala/simple/ + ├── Page.scala + └── Server.scala @p First, let's do the wiring in @code{build.sbt}: @@ -49,10 +46,10 @@ @hl.ref(wd/'examples/'crossBuilds/'clientserver/"build.sbt") @p - We have two projects: @code{client} and @code{server}, one of which is a Scala.js project (indicated by the presence of @hl.scala{enablePlugins(ScalaJSPlugin)}). Both projects share a number of settings: the presence of the @code{shared/} folder, which shared code can live in (similar to what we saw in @sect.ref{Cross Publishing Libraries}) and the settings to add @lnk.github.Scalatags and @lnk.github.uPickle to the build. Note that those two dependencies use the triple @code{%%%} instead of the double @code{%%} to declare: this means that for each dependency, we will pull in the Scala-JVM or Scala.js version depending on whether it's being used in a Scala.js project. Note also the @hl.scala{packageArchetype.java_application} setting, which isn't strictly necessary depending on what you want to do with the application, but this example needs it as part of the deployment to Heroku. + Again, we are using @hl.scala{crossProject} to define our @code{js/} and @code{jvm/} sub-projects. Both projects share a number of settings: the settings to add @lnk.github.Scalatags and @lnk.github.uPickle to the build. Note that those two dependencies use the triple @code{%%%} instead of the double @code{%%} to declare: this means that for each dependency, we will pull in the Scala-JVM or Scala.js version depending on whether it's being used in a Scala.js project. Note also the @hl.scala{packageArchetype.java_application} setting, which isn't strictly necessary depending on what you want to do with the application, but this example needs it as part of the deployment to Heroku. @p - The @code{client} subproject is uneventful, with a dependency on the by-now-familiar @code{scalajs-dom} library. The @code{server} project, on the other hand, is interesting: it contains the dependencies required for us to set up out Spray server, and one additional thing: we add the output of @code{fastOptJS} from the client to the @code{resources} on the server. This will allow the @code{server} to serve the compiled-javascript from our @code{client} project from its resources. + The @code{js/} sub-project is uneventful, with a dependency on the by-now-familiar @code{scalajs-dom} library. The @code{jvm/} project, on the other hand, is interesting: it contains the dependencies required for us to set up out Spray server, and one additional thing: we add the output of @code{fastOptJS} from the client to the @code{resources} on the server. This will allow the @code{server} to serve the compiled-javascript from our @code{client} project from its resources. @p Next, let's kick off the Spray server in our Scala-JVM main method: diff --git a/book/src/main/scalatex/book/handson/PublishingModules.scalatex b/book/src/main/scalatex/book/handson/PublishingModules.scalatex index 44cefb7..44bad45 100644 --- a/book/src/main/scalatex/book/handson/PublishingModules.scalatex +++ b/book/src/main/scalatex/book/handson/PublishingModules.scalatex @@ -15,11 +15,12 @@ $ tree . ├── build.sbt - ├── app - │   ├── js/src/main/scala/simple/Platform.scala - │   ├── jvm/src/main/scala/simple/Platform.scala - │   └── shared/src/main/scala/simple/Simple.scala - └── project/ build.sbt + ├── project/build.sbt + └── library +    ├── js/src/main/scala/simple/Platform.scala +    ├── jvm/src/main/scala/simple/Platform.scala +    └── shared/src/main/scala/simple/Simple.scala + @p As you can see, we have three main places where code lives: @code{js/} is where Scala-JS specific code lives, @code{jvm/} for Scala-JVM specific code, and @code{shared/} for code that is common between both platforms. Depending on your project, you may have more or less code in the @code{shared/} folder: a mostly-the-same cross-compiled module may have most or all its code in @code{shared/} while a @sect.ref("Integrating Client-Server", "client-server web application") would have lots of client/server js/jvm-specific code. @@ -35,7 +36,7 @@ @hl.ref(wd/'examples/'crossBuilds/'simple/"build.sbt") @p - Unlike the equivalent @code{build.sbt} files you saw in earlier chapters, this does not simply enable the @hl.scala{ScalaJSPlugin} to the root project. Rather, it uses the @hl.scala{crossProject} function provided by the Scala.js plugin to set up two projects: one in the @code{app/js/} folder and one in the @code{jvm/} folder. We also have places to put settings related to either the JS side, the JVM side, or both. In this case, we add a dependency on @lnk("uTest", "https://github.com/lihaoyi/utest"), which we will use as the test framework for our library. + Unlike the equivalent @code{build.sbt} files you saw in earlier chapters, this does not simply enable the @hl.scala{ScalaJSPlugin} to the root project. Rather, it uses the @hl.scala{crossProject} function provided by the Scala.js plugin to set up two projects: one in the @code{app/js/} folder and one in the @code{jvm/} folder. We also have places to put settings related to either the JS side, the JVM side, or both. In this case, we add a dependency on @lnk("uTest", "https://github.com/lihaoyi/utest"), which we will use as the test framework for our library. Note how we use triple @hl.scala{%%%} to indicate that we're using the platform-specific version of uTest, such that the Scala.js or Scala-JVM version will be properly pulled in when compiling for each platform. @sect{Source Files} @val simple = wd/'examples/'crossBuilds/'simple diff --git a/examples/crossBuilds/simple/jvm/shared b/examples/crossBuilds/simple/jvm/shared deleted file mode 120000 index a12df7d..0000000 --- a/examples/crossBuilds/simple/jvm/shared +++ /dev/null @@ -1 +0,0 @@ -../js/shared \ No newline at end of file -- cgit v1.2.3