From d4c5b43c9d24809cc61db631b87991cfa9578822 Mon Sep 17 00:00:00 2001 From: Konrad `ktoso` Malawski Date: Mon, 22 May 2017 14:19:20 +0200 Subject: [PATCH] =doc small adjustments for merging typed docs to master --- akka-docs/src/main/paradox/scala/typed.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/akka-docs/src/main/paradox/scala/typed.md b/akka-docs/src/main/paradox/scala/typed.md index f15b32af1b..e01b045b1b 100644 --- a/akka-docs/src/main/paradox/scala/typed.md +++ b/akka-docs/src/main/paradox/scala/typed.md @@ -13,12 +13,12 @@ As discussed in @ref:[Actor Systems](general/actor-systems.md) (and following ch sending messages between independent units of computation, but how does that look like? In all of the following these imports are assumed: -@@snip [IntroSpec.scala]($code$/scala/docs/akka/typed/IntroSpec.scala) { #imports } +@@snip [IntroSpec.scala]($akka$/akka-typed-tests/src/test/scala/docs/akka/typed/IntroSpec.scala) { #imports } With these in place we can define our first Actor, and of course it will say hello! -@@snip [IntroSpec.scala]($code$/scala/docs/akka/typed/IntroSpec.scala) { #hello-world-actor } +@@snip [IntroSpec.scala]($akka$/akka-typed-tests/src/test/scala/docs/akka/typed/IntroSpec.scala) { #hello-world-actor } This small piece of code defines two message types, one for commanding the Actor to greet someone and one that the Actor will use to confirm that it has @@ -33,7 +33,7 @@ immutable because the behavior instance doesn't have or close over any mutable state. Processing the next message may result in a new behavior that can potentially be different from this one. State is updated by returning a new behavior that holds the new immutable state. In this case we don't need to -update any state, so we return :class:`Same`. +update any state, so we return `Same`. The type of the messages handled by this behavior is declared to be of class `Greet`, which implies that the supplied function’s `msg` argument is @@ -54,7 +54,7 @@ wrapped scope—the `HelloWorld` object. Now we want to try out this Actor, so we must start an ActorSystem to host it: -@@snip [IntroSpec.scala]($code$/scala/docs/akka/typed/IntroSpec.scala) { #hello-world } +@@snip [IntroSpec.scala]($akka$/akka-typed-tests/src/test/scala/docs/akka/typed/IntroSpec.scala) { #hello-world } After importing the Actor’s protocol definition we start an Actor system from the defined behavior. @@ -150,7 +150,7 @@ a message that contains their screen name and then they can post messages. The chat room Actor will disseminate all posted messages to all currently connected client Actors. The protocol definition could look like the following: -@@snip [IntroSpec.scala]($code$/scala/docs/akka/typed/IntroSpec.scala) { #chatroom-protocol } +@@snip [IntroSpec.scala]($akka$/akka-typed-tests/src/test/scala/docs/akka/typed/IntroSpec.scala) { #chatroom-protocol } Initially the client Actors only get access to an `ActorRef[GetSession]` which allows them to make the first step. Once a client’s session has been @@ -167,7 +167,7 @@ full protocol that can involve multiple Actors and that can evolve over multiple steps. The implementation of the chat room protocol would be as simple as the following: -@@snip [IntroSpec.scala]($code$/scala/docs/akka/typed/IntroSpec.scala) { #chatroom-behavior } +@@snip [IntroSpec.scala]($akka$/akka-typed-tests/src/test/scala/docs/akka/typed/IntroSpec.scala) { #chatroom-behavior } The core of this behavior is stateful, the chat room itself does not change into something else when sessions are established, but we introduce a variable @@ -208,7 +208,7 @@ problematic, so passing an `ActorRef[PostSessionMessage]` where In order to see this chat room in action we need to write a client Actor that can use it: -@@snip [IntroSpec.scala]($code$/scala/docs/akka/typed/IntroSpec.scala) { #chatroom-gabbler } +@@snip [IntroSpec.scala]($akka$/akka-typed-tests/src/test/scala/docs/akka/typed/IntroSpec.scala) { #chatroom-gabbler } From this behavior we can create an Actor that will accept a chat room session, post a message, wait to see it published, and then terminate. The last step @@ -218,7 +218,7 @@ running behavior into the terminated state. This is why here we do not return Since `SessionEvent` is a sealed trait the Scala compiler will warn us if we forget to handle one of the subtypes; in this case it reminded us that alternatively to `SessionGranted` we may also receive a -:class:`SessionDenied` event. +`SessionDenied` event. Now to try things out we must start both a chat room and a gabbler and of course we do this inside an Actor system. Since there can be only one guardian @@ -227,7 +227,7 @@ want—it complicates its logic) or the gabbler from the chat room (which is nonsensical) or we start both of them from a third Actor—our only sensible choice: -@@snip [IntroSpec.scala]($code$/scala/docs/akka/typed/IntroSpec.scala) { #chatroom-main } +@@snip [IntroSpec.scala]($akka$/akka-typed-tests/src/test/scala/docs/akka/typed/IntroSpec.scala) { #chatroom-main } In good tradition we call the `main` Actor what it is, it directly corresponds to the `main` method in a traditional Java application. This