From 370e06d84c1067bbda8804e8f1d18c701c8c4981 Mon Sep 17 00:00:00 2001 From: Chris McDonough Date: Fri, 18 Jul 2008 02:41:14 +0000 Subject: --- docs/narr/introduction.rst | 26 ++++++++++++++------------ 1 file changed, 14 insertions(+), 12 deletions(-) (limited to 'docs') diff --git a/docs/narr/introduction.rst b/docs/narr/introduction.rst index 43b25e7bf..66dc07121 100644 --- a/docs/narr/introduction.rst +++ b/docs/narr/introduction.rst @@ -296,7 +296,7 @@ A Traversal Example Let's pretend the user asks for ``http://example.com/foo/bar/baz/biz/buz.txt``. Let's pretend that the -request's PATH_INFO in that case is ``/foo/bar/baz/biz/buz.txt``. +request's ``PATH_INFO`` in that case is ``/foo/bar/baz/biz/buz.txt``. Let's further pretend that when this request comes in that we're traversing the follwing graph:: @@ -313,7 +313,7 @@ Here's what happens: - bfg traverses foo, and attempts to find bar, which it finds. - bfg traverses bar, and attempts to find baz, which it does not - find ('bar' raises a KeyError when asked for baz). + find ('bar' raises a ``KeyError`` when asked for baz). The fact that it does not find "baz" at this point does not signify an error condition. It signifies that: @@ -326,16 +326,16 @@ error condition. It signifies that: - the "subpath" is ``['biz', 'buz.txt']`` Because it's the "context", bfg examimes "baz" to find out what "type" -it is. Let's say it finds that the context an IBar type (because "bar" -happens to have an attribute attached to it that indicates it's an -IBar). +it is. Let's say it finds that the context an ``IBar`` type (because +"bar" happens to have an attribute attached to it that indicates it's +an ``IBar``). Using the "view name" ("baz") and the type, it asks the "view registry" (configured separately, in our case via "configure.zcml") this question: - Please find me a "view" (controller in some religions) with the - name "baz" that can be used for the type IBar. + name "baz" that can be used for the type ``IBar``. Let's say it finds no matching view type. It then returns a NotFound. The request ends. Everyone is sad. @@ -352,7 +352,7 @@ But! For this graph:: | biz -The user asks for http://example.com/foo/bar/baz/biz/buz.txt +The user asks for ``http://example.com/foo/bar/baz/biz/buz.txt`` - bfg traverses foo, and attempts to find bar, which it finds. @@ -373,16 +373,16 @@ signify an error condition. It signifies that: - the "subpath" is the empty list [] Because it's the "context", bfg examimes "biz" to find out what "type" -it is. Let's say it finds that the context an IBiz type (because "biz" -happens to have an attribute attached to it that happens indicates -it's an IBiz). +it is. Let's say it finds that the context an ``IBiz`` type (because +"biz" happens to have an attribute attached to it that happens +indicates it's an ``IBiz``). Using the "view name" ("buz.txt") and the type, it asks the "view registry" (configured separately, in our case in "configure.zcml") this question: - Please find me a "view" (controller in some religions) with the name - "buz.txt" that can be used for type IBiz. + "buz.txt" that can be used for type ``IBiz``. Let's say that question is answered "here you go, here'a a bit of code that is willing to deal with that case", and returns a view. It is @@ -391,7 +391,9 @@ as the "request". It returns a response. The only "special case" is when you end up with a "view name" that is the empty string. In this case the "default view" is looked up. The -default view has a name that equals the empty string. +default view has a name that equals the empty string. If a view is +configured in the view registry without a name, it is the default +view. A Sample Application -------------------- -- cgit v1.2.3