--- a/doc/book/en/devweb/request.rst	Mon Jan 17 10:25:18 2011 +0100
+++ b/doc/book/en/devweb/request.rst	Mon Jan 17 12:41:40 2011 +0100
@@ -1,5 +1,5 @@
-The `Request` class (`cubicweb.web`)
-------------------------------------
+The `Request` class (`cubicweb.web.request`)
+--------------------------------------------
 
 Overview
 ````````
@@ -7,7 +7,8 @@
 A request instance is created when an HTTP request is sent to the web
 server.  It contains informations such as form parameters,
 authenticated user, etc. It is a very prevalent object and is used
-throughout all of the framework and applications.
+throughout all of the framework and applications, as you'll access to
+almost every resources through it.
 
 **A request represents a user query, either through HTTP or not (we
 also talk about RQL queries on the server side for example).**
@@ -24,8 +25,8 @@
 
 * `User and identification`:
 
-  * `user`, instance of `cubicweb.common.utils.User` corresponding to
-    the authenticated user
+  * `user`, instance of `cubicweb.entities.authobjs.CWUser` corresponding to the
+    authenticated user
 
 * `Session data handling`
 

--- a/doc/book/en/devweb/views/views.rst	Mon Jan 17 10:25:18 2011 +0100
+++ b/doc/book/en/devweb/views/views.rst	Mon Jan 17 12:41:40 2011 +0100
@@ -88,7 +88,7 @@
 
 Other basic view classes
 ````````````````````````
-Here are some of the subclasses of `View` defined in `cubicweb.common.view`
+Here are some of the subclasses of `View` defined in `cubicweb.view`
 that are more concrete as they relate to data rendering within the application:
 
 * `EntityView`, view applying to lines or cell containing an entity (e.g. an eid)

--- a/doc/book/en/tutorials/advanced/index.rst	Mon Jan 17 10:25:18 2011 +0100
+++ b/doc/book/en/tutorials/advanced/index.rst	Mon Jan 17 12:41:40 2011 +0100
@@ -70,21 +70,31 @@
 
   .. sourcecode:: python
 
-    __depends_cubes__ = {'file': '>= 1.2.0',
-			 'folder': '>= 1.1.0',
-			 'person': '>= 1.2.0',
-			 'comment': '>= 1.2.0',
-			 'tag': '>= 1.2.0',
-			 'zone': None,
-			 }
-    __depends__ = {'cubicweb': '>= 3.5.10',
-		   }
-    for key,value in __depends_cubes__.items():
-	__depends__['cubicweb-'+key] = value
-    __use__ = tuple(__depends_cubes__)
+    __depends__ = {'cubicweb': '>= 3.8.0',
+                   'cubicweb-file': '>= 1.2.0',
+		   'cubicweb-folder': '>= 1.1.0',
+		   'cubicweb-person': '>= 1.2.0',
+		   'cubicweb-comment': '>= 1.2.0',
+		   'cubicweb-tag': '>= 1.2.0',
+		   'cubicweb-zone': None}
 
 Notice that you can express minimal version of the cube that should be used,
-`None` meaning whatever version available.
+`None` meaning whatever version available. All packages starting with 'cubicweb-'
+will be recognized as being cube, not bare python packages. You can still specify
+this explicitly using instead the `__depends_cubes__` dictionary which should
+contains cube's name without the prefix. So the example below would be written
+as:
+
+  .. sourcecode:: python
+
+    __depends__ = {'cubicweb': '>= 3.8.0'}
+    __depends_cubes__ = {'file': '>= 1.2.0',
+		         'folder': '>= 1.1.0',
+		   	 'person': '>= 1.2.0',
+		   	 'comment': '>= 1.2.0',
+		   	 'tag': '>= 1.2.0',
+		   	 'zone': None}
+
 
 Step 3: glue everything together in my cube's schema
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -550,7 +560,7 @@
 If you do some changes in your schema, you'll have to force regeneration of that
 database. You do that by removing the tmpdb files before running the test: ::
 
-    $ rm tmpdb*
+    $ rm data/tmpdb*
 
 
 .. Note::

--- a/doc/book/en/tutorials/base/create-cube.rst	Mon Jan 17 10:25:18 2011 +0100
+++ b/doc/book/en/tutorials/base/create-cube.rst	Mon Jan 17 12:41:40 2011 +0100
@@ -288,17 +288,12 @@
 
  * render_entity_title
 
- * render_entity_metadata
-
  * render_entity_attributes
 
  * render_entity_relations
 
- * render_side_boxes
-
-Excepted side boxes, we can see all of them already in action in the
-blog entry view. This is all described in more details in
-:ref:`primary_view`.
+We can see all of them already in action in the blog entry view. This is all
+described in more details in :ref:`primary_view`.
 
 We can for example add in front of the publication date a prefix
 specifying that the date we see is the publication date.