fixing

Author: Ducasse

Chapters/13-Sessions/sessions.pillar

@@ -154,25 +154,22 @@ MiniInn>>renderContentOn: html
 
 Figures *@fig:Session1*, *@fig:Session2* and *@fig:Session3* illustrate the behavior we just implemented. The user may log in using the top level link. Once logged in, extra information is available to the user.
 
-%+Session1|width=50%+ 
 +With Session.>file://figures/Session1.png|width=60|label=fig:Session1+
+
 + With Session: Enter your name.>file://figures/Session2.png|width=60|label=fig:Session2+
+
 +With Session: Starting Date and Ending Date.>file://figures/Session3.png|width=60|label=fig:Session3+
-%+Session2|width=50%+
-%+Session3|width=50%+
 
 
 !!! LifeCycle of a Session
 
 It is important to understand the lifecycle of a session to know which hooks to customize. 
-*@ref:lifetime* depicts the lifetime of a session:
+*@fig:lifetime* depicts the lifetime of a session:
 # When the user accesses a Seaside application for the first time a new session instance is created and the root component is instantiated. Seaside sends the message ==WAComponent>>initialRequest:==  to the active component tree, just before triggering the rendering of the components. Specializing the method ==initialRequest:== enables developers to inspect the head fields of the first request to an application, and to parse and restore state if necessary.
 # All subsequent requests are processed the same way. First, Seaside gives the components the ability to process the callbacks that have been defined during the last rendering pass. These callbacks are usually triggered by clicking a link or submitting a form. Then Seaside calls ==WAComponent>>updateUrl:==  of all visible components. This gives the developer the ability to modify the default URL automatically generated by Seaside. Then Seaside redirects the user to the new URL. This redirect is important, because it avoids processing the callbacks unnecessarily when the user hits the ''Back'' button. Finally Seaside renders the component tree.
 # If the session is not used for an extended period of time, Seaside automatically expires it and calls the method  ==WASession>>unregistered==. If the user bookmarked the application, or comes back to the expired session for another reason, a new session is spawned and the lifecycle of the session starts from the beginning.
 
-%+lifetime|width=70%+
-
-+Life cycle of a session.>file://figures/lifetimeofsession.png|width=60|label=fig:lifetimeofsession+
++Life cycle of a session.>file://figures/lifetimeofsession.png|width=60|label=fig:lifetime+
 
 
 !!! Catching the Session Expiry Notification

Chapters/16-Deploy/deploy.pillar

@@ -48,7 +48,7 @@ Alternatively you can use the configuration interface: In the configuration of a
 # Set ''login'' and ''password'' in the ''Configuration'' section below.
 # Click on ''Save''.
 
-+Configure an application for deployment.>file://figures/configuration.png|width=80|label=fig:configuration+
++Configure an application for deployment.>file://figures/config.png|width=80|label=fig:configuration+
 
 
 If you want to programmatically change the password of the Seaside configure application, adapt and execute the following code:
@@ -625,7 +625,7 @@ $ curl 'http://localhost:8080/manager?code=SystemVersion current'
 Pharo1.0rc1 of 19 October 2009 update 10492
 ]]]
 
-If you install a request handler like the one presented here in your application make sure to properly protect it from unauthorized access, see *ref:/book/advanced/deployment/deployment-preparing*.
+If you install a request handler like the one presented here in your application make sure to properly protect it from unauthorized access, see Section *ref:deployment-preparing*.
 
 !!! Summary