From 7dc56c4867882c70414ac6e731fb7255375a1a96 Mon Sep 17 00:00:00 2001 From: Janne Valkealahti Date: Tue, 2 Jun 2015 08:13:01 +0100 Subject: [PATCH] Fix some typos --- docs/src/reference/asciidoc/appendix.adoc | 16 +++++++-------- docs/src/reference/asciidoc/introduction.adoc | 4 ++-- docs/src/reference/asciidoc/sm-examples.adoc | 12 +++++------ docs/src/reference/asciidoc/sm.adoc | 20 +++++++++---------- 4 files changed, 26 insertions(+), 26 deletions(-) diff --git a/docs/src/reference/asciidoc/appendix.adoc b/docs/src/reference/asciidoc/appendix.adoc index 7ad98d30..9209f45d 100644 --- a/docs/src/reference/asciidoc/appendix.adoc +++ b/docs/src/reference/asciidoc/appendix.adoc @@ -86,7 +86,7 @@ state changes. *Initial State*:: A special state in which the state machine starts. Initial state is -always bound to a particulal state machine or a region. A state +always bound to a particular state machine or a region. A state machine with a multiple regions may have a multiple initial states. *End State*:: @@ -222,7 +222,7 @@ Guard conditions are expressions which evaluates either to *TRUE* or are used with actions and transitions to dynamically choose if particular action or transition should be executed. Aspects of guards, event parameters and extended state variables are simply to make state -machine desing much more simple. +machine design much more simple. ==== Events Event is the most used trigger behaviour to drive a state machine. @@ -244,7 +244,7 @@ absence of state entry and exit actions. ===== External vs. Local Transition Most of the cases external and local transition are functionally -equivalent expect in cases where transition is happening between super +equivalent except in cases where transition is happening between super and sub states. Local transition doesn't cause exit and entry to source state if target state is a substate of a source state. Other way around, local transition doesn't cause exit and entry to target @@ -257,7 +257,7 @@ with a very simplistic super and sub states. ==== Actions Actions are the ones which really glues state machine state changes -with a users own code. State machine can execute action on various +with a user's own code. State machine can execute action on various changes and steps in a state machine like entering or exiting a state, or doing a state transition. @@ -286,10 +286,10 @@ machine will simply see what a super state can handle. ==== Regions Regions which are also called as orthogonal regions are usually viewed as exclusive OR operation applied to a states. Concept of a region in -terms of a state machine is usually a little difficult to understang +terms of a state machine is usually a little difficult to understand but things gets a little simpler with a simple example. -Some of use have a full size keyboard with main keys on a left side and numeric +Some of us have a full size keyboard with main keys on a left side and numeric keys on a right side. You've probably noticed that both sides really have their own state which you see if you press a numlock key which only alters behaviour of numbad itself. If you don't have a full size @@ -300,7 +300,7 @@ operating on different state machines. It would be a little inconvenient to handle two different statemachines as totally separate entities because in a sense they are -still working together in a sense. This is why orthogonal regios can -combine together a multiple simultaneous states withing a single state +still working together in a sense. This is why orthogonal regions can +combine together a multiple simultaneous states within a single state in a state machine. diff --git a/docs/src/reference/asciidoc/introduction.adoc b/docs/src/reference/asciidoc/introduction.adoc index 1b9c64d6..2b38a2ec 100644 --- a/docs/src/reference/asciidoc/introduction.adoc +++ b/docs/src/reference/asciidoc/introduction.adoc @@ -49,7 +49,7 @@ ask developer to go home when things are starting to look too complex. == Usage Scenarios -Project is a good candiate to use state machine if: +Project is a good candidate to use state machine if: * Application or part of its structure can be represented as states. * You want to split complex logic into smaller manageable tasks. @@ -61,7 +61,7 @@ You are already trying to implement a state machine if: * Use of boolean flags or enums to model situations. * Having variables which only have meaning for some part of your application lifecycle. -* Looping throught if/else structure and checking if particular flag or +* Looping through if/else structure and checking if particular flag or enum is set and then making further exceptions what to do when certain combination of your flags and enums exists or doesn't exist together. diff --git a/docs/src/reference/asciidoc/sm-examples.adoc b/docs/src/reference/asciidoc/sm-examples.adoc index 49f21ce4..930495fe 100644 --- a/docs/src/reference/asciidoc/sm-examples.adoc +++ b/docs/src/reference/asciidoc/sm-examples.adoc @@ -24,7 +24,7 @@ projects `build/libs` directory. Turnstile is a simple device which gives you an access if payment is made and is a very simple to model using a state machine. In its -simples form there are only two states, `LOCKED` and `UNLOCKED`. Two +simplest form there are only two states, `LOCKED` and `UNLOCKED`. Two events, `COIN` and `PUSH` can happen if you try to go through it or you make a payment. @@ -136,7 +136,7 @@ include::samples/demo/showcase/Application.java[tags=snippetD] include::samples/demo/showcase/Application.java[tags=snippetE] ---- -Lets go throught what this state machine do when it's executed and we +Lets go through what this state machine do when it's executed and we send various event to it. [source,text] @@ -199,13 +199,13 @@ What happens in above sample: unable to handle event _H_ due to guard condition, its parent is checked next. This guarantees that while on state _S2_, `foo` flag is always flipped around. However in state _S1_ event _H_ always - match to its dummy transtion without guard or action, not never + match to its dummy transition without guard or action, not never happens. == CD Player CD Player is a sample which resembles better use case of most of use have used in a real world. CD Player itself is a really simple entity where -user can open a deck, inser or change a disk, then drive player +user can open a deck, insert or change a disk, then drive player functionality by pressing various buttons like _eject_, _play_, _stop_, _pause_, _rewind_ and _backward_. @@ -217,7 +217,7 @@ things actually get a bit convoluted. You've probably noticed that if your deck is open and you press play, deck will close and a song will start to play if CD was inserted in a first place. In a sense when deck is open you first need to close -it and then try to start playing if cd is actually instered. Hopefully +it and then try to start playing if cd is actually inserted. Hopefully you have now realised that a simple CD Player is not anymore so simple. Sure you can wrap all this with a simple class with few boolean variables and probably few nested if/else clauses, that will do the job, but what @@ -226,7 +226,7 @@ really want to keep adding more flags and if/else clauses. image::images/statechart3.png[width=500] -Lets go throught how this sample and its state machine is designed and +Lets go through how this sample and its state machine is designed and how those two interacts with each other. Below three config sections are used withing a _EnumStateMachineConfigurerAdapter_. diff --git a/docs/src/reference/asciidoc/sm.adoc b/docs/src/reference/asciidoc/sm.adoc index 26fcbb92..b51925d5 100644 --- a/docs/src/reference/asciidoc/sm.adoc +++ b/docs/src/reference/asciidoc/sm.adoc @@ -55,11 +55,11 @@ include::samples/DocsConfigurationSampleTests.java[tags=snippetB] === Configuring Regions There are no special configuration methods to mark a collection of -states to be part of a orthogonal state. To put it simple, orthogonal +states to be part of an orthogonal state. To put it simple, orthogonal state is created when same hierarchical state machine has multiple set -of states each having a initial state. Because a individual state -machine can only have one initial state, multiple initial states mush -mean that a specific state mush have multiple independent regions. +of states each having a initial state. Because an individual state +machine can only have one initial state, multiple initial states must +mean that a specific state must have multiple independent regions. [source,java,indent=0] ---- @@ -178,7 +178,7 @@ include::samples/DocsConfigurationSampleTests.java[tags=snippetT] Join needs to be defined in both states and transitions to work properly. Mark particular state as choice state by using `join()` method. This state doesn't need to match either source states or -target state in a transition configuretion. +target state in a transition configuration. Select one target state where transition goes when all source states has been joined. If you use state hosting regions as source, end @@ -225,7 +225,7 @@ include::samples/DocsConfigurationSampleTests.java[tags=snippetL] Current limitation of factory is that all actions and guard it is associating with created state machine will share a same instances. This means that from your actions and guard you will need to -specifially handle a case that same bean will be called by a different +specifically handle a case that same bean will be called by a different state machines. This limitation is something which will be resolved in future releases. @@ -302,12 +302,12 @@ expression as an argument. _StateContext_ is a domain object representing a current status of a state machine within a transition or an action. Context gives an access to a various information like event, message headers, extended -state variables, current trasition and a top-level state machine in -case there is a need to send events to a futher processing. +state variables, current transition and a top-level state machine in +case there is a need to send events to a further processing. [[sm-triggers]] == Triggering Transitions -Driving a statemachine is done via transitions which are triggerred +Driving a statemachine is done via transitions which are triggered by triggers. Currently supported triggers are _EventTrigger_ and _TimerTrigger_. @@ -408,7 +408,7 @@ either listening its events or using actions with states and transitions. Time to time this approach would be too limited and verbose to create interaction with the application a state machine is working with. For this specific use case we have made a spring style -context intergration which easily attach state machine functionality +context integration which easily attach state machine functionality into your beans. === Annotation Support