From 53901dbad3cc176c86d8ab570a2d18759fb01160 Mon Sep 17 00:00:00 2001 From: Chris McDonough Date: Thu, 23 Dec 2010 18:53:08 -0500 Subject: fix references --- docs/tutorials/wiki/definingviews.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'docs/tutorials/wiki') diff --git a/docs/tutorials/wiki/definingviews.rst b/docs/tutorials/wiki/definingviews.rst index 53f5ff994..c051d6db7 100644 --- a/docs/tutorials/wiki/definingviews.rst +++ b/docs/tutorials/wiki/definingviews.rst @@ -118,7 +118,7 @@ The ``add_page`` view function ------------------------------ The ``add_page`` function will be configured to respond when the context is a -Wiki and the :term:`view_name` is ``add_page``. We'll provide it with a +Wiki and the :term:`view name` is ``add_page``. We'll provide it with a ``@view_config`` decorator which names the string ``add_page`` as its :term:`view name` (via name=), the class ``tutorial.models.Wiki`` as its context, and the renderer named ``templates/edit.pt``. This means that when @@ -165,7 +165,7 @@ The ``edit_page`` view function ------------------------------- The ``edit_page`` function will be configured to respond when the context is -a Page and the :term:`view_name` is ``edit_page``. We'll provide it with a +a Page and the :term:`view name` is ``edit_page``. We'll provide it with a ``@view_config`` decorator which names the string ``edit_page`` as its :term:`view name` (via name=), the class ``tutorial.models.Page`` as its context, and the renderer named ``templates/edit.pt``. This means that when -- cgit v1.2.3 From d1138fdd4fe55358dcb583c5ddee3f45043d1fb5 Mon Sep 17 00:00:00 2001 From: Chris McDonough Date: Thu, 23 Dec 2010 19:32:05 -0500 Subject: fix awkward wording --- docs/tutorials/wiki/definingviews.rst | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) (limited to 'docs/tutorials/wiki') diff --git a/docs/tutorials/wiki/definingviews.rst b/docs/tutorials/wiki/definingviews.rst index c051d6db7..2c016b373 100644 --- a/docs/tutorials/wiki/definingviews.rst +++ b/docs/tutorials/wiki/definingviews.rst @@ -7,9 +7,10 @@ Conventionally, :term:`view callable` objects are defined within a automagically special about the filename ``views.py``. Files implementing views often have ``view`` in their filenames (or may live in a Python subpackage of your application package named ``views``), but this is only by -convention. However, a project may have many views throughout its codebase -in arbitrarily-named files. In this application, we'll be continuing to use -the ``views.py`` module, because there's no reason to break convention. +convention. A project may have many views throughout its codebase in +arbitrarily-named files. In this application, however, we'll be continuing +to use the ``views.py`` module, because there's no reason to break +convention. A :term:`view callable` in a :app:`Pyramid` application is typically a simple Python function that accepts a single parameter: :term:`request`. A view -- cgit v1.2.3 From b743bb4da42198f223ec756936dc0c581b08b534 Mon Sep 17 00:00:00 2001 From: Chris McDonough Date: Thu, 23 Dec 2010 20:01:42 -0500 Subject: tutorial accuracy and wording improvements --- docs/tutorials/wiki/authorization.rst | 174 +++++++++++---------- docs/tutorials/wiki/basiclayout.rst | 12 +- docs/tutorials/wiki/definingmodels.rst | 44 +++--- docs/tutorials/wiki/definingviews.rst | 150 +++++++++--------- .../wiki/src/authorization/tutorial/login.py | 4 +- 5 files changed, 194 insertions(+), 190 deletions(-) (limited to 'docs/tutorials/wiki') diff --git a/docs/tutorials/wiki/authorization.rst b/docs/tutorials/wiki/authorization.rst index 34cde288f..57c4a3ce5 100644 --- a/docs/tutorials/wiki/authorization.rst +++ b/docs/tutorials/wiki/authorization.rst @@ -23,15 +23,13 @@ For any :app:`Pyramid` application to perform authorization, we need to add a registry` to add an :term:`authentication policy` and a :term:`authorization policy`. -Changing ``__init__.py`` -~~~~~~~~~~~~~~~~~~~~~~~~ +Adding Authentication and Authorization Policies +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -We'll change our ``__init__.py`` file to enable an +We'll change our package's ``__init__.py`` file to enable an ``AuthTktAuthenticationPolicy`` and an ``ACLAuthorizationPolicy`` to enable -declarative security checking. We'll also add a new view stanza, which -specifies a :term:`forbidden view`. This configures our login view to show -up when :app:`Pyramid` detects that a view invocation can not be authorized. -When you're done, your ``__init__.py`` will look like so: +declarative security checking. When you're done, your ``__init__.py`` will +look like so: .. literalinclude:: src/authorization/tutorial/__init__.py :linenos: @@ -84,6 +82,22 @@ and logout views. Add a file named ``login.py`` to your application :linenos: :language: python +Note that the ``login`` view callable in the ``login.py`` file has *two* view +configuration decorators. In the first view configuration decorator, we +configured the ``login`` view callable so it will be invoked when someone +visits ``/login`` (when the context is a Wiki and the view name is +``login``). The second decorator (with context of +``pyramid.exceptions.Forbidden``) specifies a :term:`forbidden view`. This +configures our login view to show up when :app:`Pyramid` detects that a view +invocation can not be authorized. Because we've configured a forbidden view, +the ``login`` view callable will be invoked whenever one of our users tries +to execute a view callable that they are disallowed from invoking based on +the :term:`authorization policy` in use. In our application, for example, +this means that if a user has not logged in, and he tries to add or edit a +Wiki page, he will be shown the login form. Before being allowed to continue +on to the add or edit form, he will have to provide credentials that give him +permission to add or edit via this login form. + Changing Existing Views ~~~~~~~~~~~~~~~~~~~~~~~ @@ -138,17 +152,15 @@ class="main_content">`` div: Logout -Giving Our Root Model Object an ACL ------------------------------------ +Giving Our Root Resource an ACL +------------------------------- -We need to give our root model object an :term:`ACL`. This ACL will -be sufficient to provide enough information to the :app:`Pyramid` -security machinery to challenge a user who doesn't have appropriate -credentials when he attempts to invoke the ``add_page`` or -``edit_page`` views. +We need to give our root resource object an :term:`ACL`. This ACL will be +sufficient to provide enough information to the :app:`Pyramid` security +machinery to challenge a user who doesn't have appropriate credentials when +he attempts to invoke the ``add_page`` or ``edit_page`` views. -We need to perform some imports at module scope in our ``models.py`` -file: +We need to perform some imports at module scope in our ``models.py`` file: .. code-block:: python :linenos: @@ -156,8 +168,8 @@ file: from pyramid.security import Allow from pyramid.security import Everyone -Our root model is a ``Wiki`` object. We'll add the following line at -class scope to our ``Wiki`` class: +Our root resource object is a ``Wiki`` instance. We'll add the following +line at class scope to our ``Wiki`` class: .. code-block:: python :linenos: @@ -165,12 +177,11 @@ class scope to our ``Wiki`` class: __acl__ = [ (Allow, Everyone, 'view'), (Allow, 'group:editors', 'edit') ] -It's only happenstance that we're assigning this ACL at class scope. -An ACL can be attached to an object *instance* too; this is how "row -level security" can be achieved in :app:`Pyramid` applications. We -actually only need *one* ACL for the entire system, however, because -our security requirements are simple, so this feature is not -demonstrated. +It's only happenstance that we're assigning this ACL at class scope. An ACL +can be attached to an object *instance* too; this is how "row level security" +can be achieved in :app:`Pyramid` applications. We actually only need *one* +ACL for the entire system, however, because our security requirements are +simple, so this feature is not demonstrated. Our resulting ``models.py`` file will now look like so: @@ -181,76 +192,71 @@ Our resulting ``models.py`` file will now look like so: Adding ``permission`` Declarations to our ``view_config`` Decorators -------------------------------------------------------------------- -To protect each of our views with a particular permission, we need to -pass a ``permission`` argument to each of our -:class:`pyramid.view.view_config` decorators. To do so, within -``views.py``: +To protect each of our views with a particular permission, we need to pass a +``permission`` argument to each of our :class:`pyramid.view.view_config` +decorators. To do so, within ``views.py``: -- We add ``permission='view'`` to the decorator attached to the - ``view_wiki`` view function. This makes the assertion that only - users who possess the effective ``view`` permission at the time of - the request may invoke this view. We've granted - :data:`pyramid.security.Everyone` the view permission at the root - model via its ACL, so everyone will be able to invoke the - ``view_wiki`` view. +- We add ``permission='view'`` to the decorator attached to the ``view_wiki`` + view function. This makes the assertion that only users who possess the + ``view`` permission against the context resource at the time of the request + may invoke this view. We've granted :data:`pyramid.security.Everyone` the + view permission at the root model via its ACL, so everyone will be able to + invoke the ``view_wiki`` view. -- We add ``permission='view'`` to the decorator attached to the - ``view_page`` view function. This makes the assertion that only - users who possess the effective ``view`` permission at the time of +- We add ``permission='view'`` to the decorator attached to the ``view_page`` + view function. This makes the assertion that only users who possess the + effective ``view`` permission against the context resource at the time of the request may invoke this view. We've granted - :data:`pyramid.security.Everyone` the view permission at the root - model via its ACL, so everyone will be able to invoke the - ``view_page`` view. - -- We add ``permission='edit'`` to the decorator attached to the - ``add_page`` view function. This makes the assertion that only - users who possess the effective ``edit`` permission at the time of - the request may invoke this view. We've granted the - ``group:editors`` principal the ``edit`` permission at the root - model via its ACL, so only the a user whom is a member of the group - named ``group:editors`` will able to invoke the ``add_page`` view. - We've likewise given the ``editor`` user membership to this group - via thes ``security.py`` file by mapping him to the - ``group:editors`` group in the ``GROUPS`` data structure (``GROUPS = - {'editor':['group:editors']}``); the ``groupfinder`` function - consults the ``GROUPS`` data structure. This means that the - ``editor`` user can add pages. - -- We add ``permission='edit'`` to the decorator attached to the - ``edit_page`` view function. This makes the assertion that only - users who possess the effective ``edit`` permission at the time of - the request may invoke this view. We've granted the - ``group:editors`` principal the ``edit`` permission at the root - model via its ACL, so only the a user whom is a member of the group - named ``group:editors`` will able to invoke the ``edit_page`` view. - We've likewise given the ``editor`` user membership to this group - via thes ``security.py`` file by mapping him to the - ``group:editors`` group in the ``GROUPS`` data structure (``GROUPS = - {'editor':['group:editors']}``); the ``groupfinder`` function - consults the ``GROUPS`` data structure. This means that the - ``editor`` user can edit pages. + :data:`pyramid.security.Everyone` the view permission at the root model via + its ACL, so everyone will be able to invoke the ``view_page`` view. + +- We add ``permission='edit'`` to the decorator attached to the ``add_page`` + view function. This makes the assertion that only users who possess the + effective ``edit`` permission against the context resource at the time of + the request may invoke this view. We've granted the ``group:editors`` + principal the ``edit`` permission at the root model via its ACL, so only + the a user whom is a member of the group named ``group:editors`` will able + to invoke the ``add_page`` view. We've likewise given the ``editor`` user + membership to this group via thes ``security.py`` file by mapping him to + the ``group:editors`` group in the ``GROUPS`` data structure (``GROUPS = + {'editor':['group:editors']}``); the ``groupfinder`` function consults the + ``GROUPS`` data structure. This means that the ``editor`` user can add + pages. + +- We add ``permission='edit'`` to the decorator attached to the ``edit_page`` + view function. This makes the assertion that only users who possess the + effective ``edit`` permission against the context resource at the time of + the request may invoke this view. We've granted the ``group:editors`` + principal the ``edit`` permission at the root model via its ACL, so only + the a user whom is a member of the group named ``group:editors`` will able + to invoke the ``edit_page`` view. We've likewise given the ``editor`` user + membership to this group via thes ``security.py`` file by mapping him to + the ``group:editors`` group in the ``GROUPS`` data structure (``GROUPS = + {'editor':['group:editors']}``); the ``groupfinder`` function consults the + ``GROUPS`` data structure. This means that the ``editor`` user can edit + pages. Viewing the Application in a Browser ------------------------------------ -We can finally examine our application in a browser. The views we'll -try are as follows: +We can finally examine our application in a browser. The views we'll try are +as follows: -- Visiting ``http://localhost:6543/`` in a browser invokes the - ``view_wiki`` view. This always redirects to the ``view_page`` view - of the FrontPage page object. It is executable by any user. +- Visiting ``http://localhost:6543/`` in a browser invokes the ``view_wiki`` + view. This always redirects to the ``view_page`` view of the ``FrontPage`` + page resource. It is executable by any user. -- Visiting ``http://localhost:6543/FrontPage/`` in a browser invokes - the ``view_page`` view of the front page page object. This is - because it's the :term:`default view` (a view without a ``name``) - for ``Page`` objects. It is executable by any user. +- Visiting ``http://localhost:6543/FrontPage/`` in a browser invokes the + ``view_page`` view of the ``FrontPage`` Page resource. This is because + it's the :term:`default view` (a view without a ``name``) for ``Page`` + resources. It is executable by any user. -- Visiting ``http://localhost:6543/FrontPage/edit_page`` in a browser - invokes the edit view for the front page object. It is executable - by only the ``editor`` user. If a different user (or the anonymous - user) invokes it, a login form will be displayed. Supplying the - credentials with the username ``editor``, password ``editor`` will - show the edit page form being displayed. +- Visiting ``http://localhost:6543/FrontPage/edit_page`` in a browser invokes + the edit view for the ``FrontPage`` Page resource. It is executable by + only the ``editor`` user. If a different user (or the anonymous user) + invokes it, a login form will be displayed. Supplying the credentials with + the username ``editor``, password ``editor`` will show the edit page form + being displayed. - Visiting ``http://localhost:6543/add_page/SomePageName`` in a browser invokes the add view for a page. It is executable by only diff --git a/docs/tutorials/wiki/basiclayout.rst b/docs/tutorials/wiki/basiclayout.rst index 8e6e89e57..f6e1f800a 100644 --- a/docs/tutorials/wiki/basiclayout.rst +++ b/docs/tutorials/wiki/basiclayout.rst @@ -2,10 +2,9 @@ Basic Layout ============ -The starter files generated by the ``pyramid_zodb`` template are basic, -but they provide a good orientation for the high-level patterns common -to most :term:`traversal` -based :app:`Pyramid` (and :term:`ZODB` -based) projects. +The starter files generated by the ``pyramid_zodb`` template are basic, but +they provide a good orientation for the high-level patterns common to most +:term:`traversal` -based :app:`Pyramid` (and :term:`ZODB` based) projects. The source code for this tutorial stage can be browsed via `http://github.com/Pylons/pyramid/tree/master/docs/tutorials/wiki/src/basiclayout/ @@ -78,11 +77,10 @@ Resources and Models with ``models.py`` hierarchically in a :term:`resource tree`. This tree is consulted by :term:`traversal` to map URLs to code. In this application, the resource tree represents the site structure, but it *also* represents the -:term:`domain model` of the application, because eeach resource is a node +:term:`domain model` of the application, because each resource is a node stored persistently in a :term:`ZODB` database. The ``models.py`` file is where the ``pyramid_zodb`` Paster template put the classes that implement our -resource objects, each of which happens also to be a domain model -object. +resource objects, each of which happens also to be a domain model object. Here is the source for ``models.py``: diff --git a/docs/tutorials/wiki/definingmodels.rst b/docs/tutorials/wiki/definingmodels.rst index 078a8e014..f201f6dc7 100644 --- a/docs/tutorials/wiki/definingmodels.rst +++ b/docs/tutorials/wiki/definingmodels.rst @@ -38,12 +38,11 @@ we're not going to use it. .. note:: - There is nothing automagically special about the filename - ``models.py``. A project may have many models throughout its - codebase in arbitrarily-named files. Files implementing models - often have ``model`` in their filenames (or they may live in a - Python subpackage of your application package named ``models``) , - but this is only by convention. + There is nothing automagically special about the filename ``models.py``. A + project may have many models throughout its codebase in arbitrarily-named + files. Files implementing models often have ``model`` in their filenames, + or they may live in a Python subpackage of your application package named + ``models``, but this is only by convention. Then, we'll add a ``Wiki`` class. Because this is a ZODB application, this class should inherit from :class:`persistent.mapping.PersistentMapping`. We @@ -131,6 +130,22 @@ When we're done changing ``tests.py``, it will look something like so: :linenos: :language: python +Declaring Dependencies in Our ``setup.py`` File +----------------------------------------------- + +Our application now depends on packages which are not dependencies of the +original "tutorial" application as it was generated by the ``paster create`` +command. We'll add these dependencies to our ``tutorial`` package's +``setup.py`` file by assigning these dependencies to both the +``install_requires`` and the ``tests_require`` parameters to the ``setup`` +function. In particular, we require the ``docutils`` package. + +Our resulting ``setup.py`` should look like so: + +.. literalinclude:: src/models/setup.py + :linenos: + :language: python + Running the Tests ----------------- @@ -160,20 +175,3 @@ The expected output is something like this: OK -Declaring Dependencies in Our ``setup.py`` File ------------------------------------------------ - -Our application depends on packages which are not dependencies of the -original "tutorial" application as it was generated by the ``paster -create`` command. We'll add these dependencies to our ``tutorial`` -package's ``setup.py`` file by assigning these dependencies to both -the ``install_requires`` and the ``tests_require`` parameters to the -``setup`` function. In particular, we require the ``docutils`` -package. - -Our resulting ``setup.py`` should look like so: - -.. literalinclude:: src/models/setup.py - :linenos: - :language: python - diff --git a/docs/tutorials/wiki/definingviews.rst b/docs/tutorials/wiki/definingviews.rst index 2c016b373..5b0e5dca1 100644 --- a/docs/tutorials/wiki/definingviews.rst +++ b/docs/tutorials/wiki/definingviews.rst @@ -18,19 +18,22 @@ callable is assumed to return a :term:`response` object. However, a :app:`Pyramid` view can also be defined as callable which accepts *two* arguments: a :term:`context` and a :term:`request`. In :term:`url -dispatch` based applications, the context object is rarely used in the view +dispatch` based applications, the context resource is rarely used in the view body itself, so within code that uses URL-dispatch-only, it's common to -define views as callables that accept only a request to avoid the visual -"noise". This application, however, uses :term:`traversal` to map URLs to -resources, so we're often interested in the context; it's not "noise" to use. +define views as callables that accept only a ``request`` to avoid the visual +"noise" of a ``context`` argument. This application, however, uses +:term:`traversal` to map URLs to a context :term:`resource`, and since our +:term:`resource tree` also represents our application's "domain model", we're +often interested in the context, because it represents the persistent storage +of our application. For this reason, having ``context`` in the callable +argument list is not "noise" to us; instead it's actually rather important +within the view code we'll define in this application. The single-arg (``request`` -only) or two-arg (``context`` and ``request``) calling conventions will work in any :app:`Pyramid` application for any view; -they can be used interchangeably as necessary. In :term:`traversal` based -applications, such as the application we're building in this tutorial, the -context is used frequently within the body of a view method, so we'll be -using the two-argument ``(context, request)`` syntax in this application for -views that we add. +they can be used interchangeably as necessary. We'll be using the +two-argument ``(context, request)`` view callable argument list syntax in +this application. We're going to define several :term:`view callable` functions then wire them into :app:`Pyramid` using some :term:`view configuration`. @@ -43,7 +46,7 @@ Adding View Functions ===================== We're going to add four :term:`view callable` functions to our ``views.py`` -module. One view (named ``view_wiki``) will display the wiki itself (it will +module. One view named ``view_wiki`` will display the wiki itself (it will answer on the root URL), another named ``view_page`` will display an individual page, another named ``add_page`` will allow a page to be added, and a final view named ``edit_page`` will allow a page to be edited. @@ -52,36 +55,35 @@ The ``view_wiki`` view function ------------------------------- The ``view_wiki`` function will be configured to respond as the default view -callable for a ``Wiki`` resource object. We'll provide it with a -``@view_config`` decorator which names the class ``tutorial.models.Wiki`` as -its context. This means that when a Wiki object is the context, and no -:term:`view name` exists in the request, this view will be used. The view -configuration associated with ``view_wiki`` does not use a ``renderer`` -because the view callable always returns a :term:`response` object rather -than a dictionary. No renderer is necessary when a view returns a response -object. - -The view callable always redirects to the ``Page`` object named "FrontPage". -It returns an instance of the :class:`pyramid.httpexceptions.HTTPFound` class -(instances of which implement the WebOb :term:`response` interface), and the -:func:`pyramid.url.resource_url` API. :func:`pyramid.url.resource_url` -constructs a URL to the ``FrontPage`` page resource -(e.g. ``http://localhost:6543/FrontPage``), and uses it as the "location" of -the HTTPFound response, forming an HTTP redirect. +callable for a Wiki resource. We'll provide it with a ``@view_config`` +decorator which names the class ``tutorial.models.Wiki`` as its context. +This means that when a Wiki resource is the context, and no :term:`view name` +exists in the request, this view will be used. The view configuration +associated with ``view_wiki`` does not use a ``renderer`` because the view +callable always returns a :term:`response` object rather than a dictionary. +No renderer is necessary when a view returns a response object. + +The ``view_wiki`` view callable always redirects to the URL of a Page +resource named "FrontPage". To do so, it returns an instance of the +:class:`pyramid.httpexceptions.HTTPFound` class (instances of which implement +the WebOb :term:`response` interface). The :func:`pyramid.url.resource_url` +API. :func:`pyramid.url.resource_url` constructs a URL to the ``FrontPage`` +page resource (e.g. ``http://localhost:6543/FrontPage``), and uses it as the +"location" of the HTTPFound response, forming an HTTP redirect. The ``view_page`` view function ------------------------------- The ``view_page`` function will be configured to respond as the default view -of a ``Page`` resource. We'll provide it with a ``@view_config`` decorator -which names the class ``tutorial.models.Wiki`` as its context. This means -that when a Page object is the context, and no :term:`view name` exists in -the request, this view will be used. We inform :app:`Pyramid` this view will -use the ``templates/view.pt`` template file as a ``renderer``. +of a Page resource. We'll provide it with a ``@view_config`` decorator which +names the class ``tutorial.models.Wiki`` as its context. This means that +when a Page resource is the context, and no :term:`view name` exists in the +request, this view will be used. We inform :app:`Pyramid` this view will use +the ``templates/view.pt`` template file as a ``renderer``. The ``view_page`` function generates the :term:`ReStructuredText` body of a page (stored as the ``data`` attribute of the context passed to the view; the -context will be a Page object) as HTML. Then it substitutes an HTML anchor +context will be a Page resource) as HTML. Then it substitutes an HTML anchor for each *WikiWord* reference in the rendered HTML using a compiled regular expression. @@ -96,7 +98,7 @@ substitution value and returns it. As a result, the ``content`` variable is now a fully formed bit of HTML containing various view and add links for WikiWords based on the content of -our current page object. +our current page resource. We then generate an edit URL (because it's easier to do here than in the template), and we wrap up a number of arguments in a dictionary and return @@ -118,13 +120,13 @@ callable. In the ``view_wiki`` view callable, we unconditionally return a The ``add_page`` view function ------------------------------ -The ``add_page`` function will be configured to respond when the context is a -Wiki and the :term:`view name` is ``add_page``. We'll provide it with a -``@view_config`` decorator which names the string ``add_page`` as its -:term:`view name` (via name=), the class ``tutorial.models.Wiki`` as its +The ``add_page`` function will be configured to respond when the context +resource is a Wiki and the :term:`view name` is ``add_page``. We'll provide +it with a ``@view_config`` decorator which names the string ``add_page`` as +its :term:`view name` (via name=), the class ``tutorial.models.Wiki`` as its context, and the renderer named ``templates/edit.pt``. This means that when -a Wiki object is the context, and a :term:`view name` exists as the result of -traverasal named ``add_page``, this view will be used. We inform +a Wiki resource is the context, and a :term:`view name` named ``add_page`` +exists as the result of traversal, this view will be used. We inform :app:`Pyramid` this view will use the ``templates/edit.pt`` template file as a ``renderer``. We share the same template between add and edit views, thus ``edit.pt`` instead of ``add.pt``. @@ -132,9 +134,9 @@ a ``renderer``. We share the same template between add and edit views, thus The ``add_page`` function will be invoked when a user clicks on a WikiWord which isn't yet represented as a page in the system. The ``check`` function within the ``view_page`` view generates URLs to this view. It also acts as a -handler for the form that is generated when we want to add a page object. -The ``context`` of the ``add_page`` view is always a Wiki object (*not* a -Page object). +handler for the form that is generated when we want to add a page resource. +The ``context`` of the ``add_page`` view is always a Wiki resource (*not* a +Page resource). The request :term:`subpath` in :app:`Pyramid` is the sequence of names that are found *after* the :term:`view name` in the URL segments given in the @@ -151,14 +153,14 @@ expression ``'form.submitted' in request.params`` is ``False``), the view renders a template. To do so, it generates a "save url" which the template use as the form post URL during rendering. We're lazy here, so we're trying to use the same template (``templates/edit.pt``) for the add view as well as -the page edit view. To do so, we create a dummy Page object in order to -satisfy the edit form's desire to have *some* page object exposed as +the page edit view. To do so, we create a dummy Page resource object in +order to satisfy the edit form's desire to have *some* page object exposed as ``page``, and we'll render the template to a response. If the view rendering *is* a result of a form submission (if the expression ``'form.submitted' in request.params`` is ``True``), we scrape the page body from the form data, create a Page object using the name in the subpath and -the page body, and save it into "our context" (the wiki) using the +the page body, and save it into "our context" (the Wiki) using the ``__setitem__`` method of the context. We then redirect back to the ``view_page`` view (the default view for a page) for the newly created page. @@ -166,23 +168,23 @@ The ``edit_page`` view function ------------------------------- The ``edit_page`` function will be configured to respond when the context is -a Page and the :term:`view name` is ``edit_page``. We'll provide it with a -``@view_config`` decorator which names the string ``edit_page`` as its -:term:`view name` (via name=), the class ``tutorial.models.Page`` as its +a Page resource and the :term:`view name` is ``edit_page``. We'll provide it +with a ``@view_config`` decorator which names the string ``edit_page`` as its +:term:`view name` (via ``name=``), the class ``tutorial.models.Page`` as its context, and the renderer named ``templates/edit.pt``. This means that when -a Page object is the context, and a :term:`view name` exists as the result of -traverasal named ``edit_page``, this view will be used. We inform +a Page resource is the context, and a :term:`view name` exists as the result +of traverasal named ``edit_page``, this view will be used. We inform :app:`Pyramid` this view will use the ``templates/edit.pt`` template file as a ``renderer``. The ``edit_page`` function will be invoked when a user clicks the "Edit this Page" button on the view form. It renders an edit form but it also acts as -the handler for the form it renders. The ``context`` of the ``edit_page`` -view will *always* be a Page object (never a Wiki object). +the form post view callable for the form it renders. The ``context`` of the +``edit_page`` view will *always* be a Page resource (never a Wiki resource). If the view execution is *not* a result of a form submission (if the expression ``'form.submitted' in request.params`` is ``False``), the view -simply renders the edit form, passing the request, the page object, and a +simply renders the edit form, passing the request, the page resource, and a save_url which will be used as the action of the generated form. If the view execution *is* a result of a form submission (if the expression @@ -208,8 +210,8 @@ Most view callables we've added expected to be rendered via a :term:`template`. The default templating systems in :app:`Pyramid` are :term:`Chameleon` and :term:`Mako`. Chameleon is a variant of :term:`ZPT`, which is an XML-based templating language. Mako is a non-XML-based -templating language. Because we have to pick one, we'll use Chameleon for -this tutorial. +templating language. Because we had to pick one, we chose Chameleon for this +tutorial. The templates we create will live in the ``templates`` directory of our tutorial package. Chameleon templates must have a ``.pt`` extension to be @@ -218,8 +220,8 @@ recognized as such. The ``view.pt`` Template ------------------------ -The ``view.pt`` template is used for viewing a single wiki page. It is used -by the ``view_page`` view function. It should have a div that is "structure +The ``view.pt`` template is used for viewing a single Page. It is used by +the ``view_page`` view function. It should have a div that is "structure replaced" with the ``content`` value provided by the view. It should also have a link on the rendered page that points at the "edit" URL (the URL which invokes the ``edit_page`` view for the page being viewed). @@ -244,12 +246,12 @@ the below: The ``edit.pt`` Template ------------------------ -The ``edit.pt`` template is used for adding and editing a wiki page. It is -used by the ``add_page`` and ``edit_page`` view functions. It should display -a page containing a form that POSTs back to the "save_url" argument supplied -by the view. The form should have a "body" textarea field (the page data), -and a submit button that has the name "form.submitted". The textarea in the -form should be filled with any existing page data when it is rendered. +The ``edit.pt`` template is used for adding and editing a Page. It is used +by the ``add_page`` and ``edit_page`` view functions. It should display a +page containing a form that POSTs back to the "save_url" argument supplied by +the view. The form should have a "body" textarea field (the page data), and +a submit button that has the name "form.submitted". The textarea in the form +should be filled with any existing page data when it is rendered. Once we're done with the ``edit.pt`` template, it will look a lot like the below: @@ -258,10 +260,10 @@ below: :linenos: :language: xml -Static Resources ----------------- +Static Assets +------------- -Our templates name a single static resource named ``style.css``. We need to +Our templates name a single static asset named ``style.css``. We need to create this and place it in a file named ``style.css`` within our package's ``static`` directory. This file is a little too long to replicate within the body of this guide, however it is available `online @@ -270,7 +272,7 @@ body of this guide, however it is available `online This CSS file will be accessed via e.g. ``http://localhost:6543/static/style.css`` by virtue of the call to ``add_static_view`` directive we've made in the ``__init__`` file. Any -number and type of static resources can be placed in this directory (or +number and type of static assets can be placed in this directory (or subdirectories) and are just referred to by URL within templates. Testing the Views @@ -324,20 +326,20 @@ Viewing the Application in a Browser Once we've completed our edits, we can finally examine our application in a browser. The views we'll try are as follows: -- Visiting ``http://localhost:6543/`` in a browser invokes the - ``view_wiki`` view. This always redirects to the ``view_page`` view - of the FrontPage page object. +- Visiting ``http://localhost:6543/`` in a browser invokes the ``view_wiki`` + view. This always redirects to the ``view_page`` view of the ``FrontPage`` + Page resource. - Visiting ``http://localhost:6543/FrontPage/`` in a browser invokes - the ``view_page`` view of the front page page object. This is + the ``view_page`` view of the front page resource. This is because it's the *default view* (a view without a ``name``) for Page - objects. + resources. - Visiting ``http://localhost:6543/FrontPage/edit_page`` in a browser - invokes the edit view for the front page object. + invokes the edit view for the ``FrontPage`` Page resource. - Visiting ``http://localhost:6543/add_page/SomePageName`` in a - browser invokes the add view for a page. + browser invokes the add view for a Page. - To generate an error, visit ``http://localhost:6543/add_page`` which will generate an ``IndexError`` for the expression diff --git a/docs/tutorials/wiki/src/authorization/tutorial/login.py b/docs/tutorials/wiki/src/authorization/tutorial/login.py index 59e71a1d9..463db71a6 100644 --- a/docs/tutorials/wiki/src/authorization/tutorial/login.py +++ b/docs/tutorials/wiki/src/authorization/tutorial/login.py @@ -7,10 +7,10 @@ from pyramid.url import resource_url from tutorial.security import USERS -@view_config(context='pyramid.exceptions.Forbidden', - renderer='templates/login.pt') @view_config(context='tutorial.models.Wiki', name='login', renderer='templates/login.pt') +@view_config(context='pyramid.exceptions.Forbidden', + renderer='templates/login.pt') def login(request): login_url = resource_url(request.context, request, 'login') referrer = request.url -- cgit v1.2.3 From c57b0660fef15be7e8c5e235ae899372a19b2c91 Mon Sep 17 00:00:00 2001 From: Chris McDonough Date: Thu, 23 Dec 2010 20:06:28 -0500 Subject: specify ordering unimportance --- docs/tutorials/wiki/authorization.rst | 30 +++++++++++++++++------------- 1 file changed, 17 insertions(+), 13 deletions(-) (limited to 'docs/tutorials/wiki') diff --git a/docs/tutorials/wiki/authorization.rst b/docs/tutorials/wiki/authorization.rst index 57c4a3ce5..1b66ace96 100644 --- a/docs/tutorials/wiki/authorization.rst +++ b/docs/tutorials/wiki/authorization.rst @@ -83,20 +83,24 @@ and logout views. Add a file named ``login.py`` to your application :language: python Note that the ``login`` view callable in the ``login.py`` file has *two* view -configuration decorators. In the first view configuration decorator, we -configured the ``login`` view callable so it will be invoked when someone -visits ``/login`` (when the context is a Wiki and the view name is -``login``). The second decorator (with context of +configuration decorators. The order of these decorators is unimportant. +Each just adds a different :term:`view configuration` for the ``login`` view +callable. + +The first view configuration decorator configures the ``login`` view callable +so it will be invoked when someone visits ``/login`` (when the context is a +Wiki and the view name is ``login``). The second decorator (with context of ``pyramid.exceptions.Forbidden``) specifies a :term:`forbidden view`. This -configures our login view to show up when :app:`Pyramid` detects that a view -invocation can not be authorized. Because we've configured a forbidden view, -the ``login`` view callable will be invoked whenever one of our users tries -to execute a view callable that they are disallowed from invoking based on -the :term:`authorization policy` in use. In our application, for example, -this means that if a user has not logged in, and he tries to add or edit a -Wiki page, he will be shown the login form. Before being allowed to continue -on to the add or edit form, he will have to provide credentials that give him -permission to add or edit via this login form. +configures our login view to be presented to the user when :app:`Pyramid` +detects that a view invocation can not be authorized. Because we've +configured a forbidden view, the ``login`` view callable will be invoked +whenever one of our users tries to execute a view callable that they are not +allowed to invoke as determined by the :term:`authorization policy` in use. +In our application, for example, this means that if a user has not logged in, +and he tries to add or edit a Wiki page, he will be shown the login form. +Before being allowed to continue on to the add or edit form, he will have to +provide credentials that give him permission to add or edit via this login +form. Changing Existing Views ~~~~~~~~~~~~~~~~~~~~~~~ -- cgit v1.2.3 From 30c242755e6ec6f21b9f817de606bdad6aed276f Mon Sep 17 00:00:00 2001 From: Blaise Laflamme Date: Wed, 5 Jan 2011 23:42:45 -0500 Subject: Updated tutorial sources to use the new theme, use request.static_url('{{package}}:static/foo.css') instead of ${request.application_url}/static/foo.css for static files --- .../src/authorization/tutorial/static/footerbg.png | Bin 0 -> 333 bytes .../src/authorization/tutorial/static/headerbg.png | Bin 0 -> 203 bytes .../wiki/src/authorization/tutorial/static/ie6.css | 8 ++ .../src/authorization/tutorial/static/logo.png | Bin 6641 -> 0 bytes .../src/authorization/tutorial/static/middlebg.png | Bin 0 -> 2797 bytes .../src/authorization/tutorial/static/pylons.css | 47 ++++----- .../src/authorization/tutorial/static/pyramid.png | Bin 0 -> 33055 bytes .../src/authorization/tutorial/static/style.css | 109 --------------------- .../authorization/tutorial/static/transparent.gif | Bin 0 -> 49 bytes .../src/authorization/tutorial/templates/edit.pt | 77 +++++++++------ .../src/authorization/tutorial/templates/login.pt | 73 ++++++++------ .../authorization/tutorial/templates/mytemplate.pt | 107 ++++++++++---------- .../src/authorization/tutorial/templates/view.pt | 80 +++++++++------ .../src/basiclayout/tutorial/static/footerbg.png | Bin 0 -> 333 bytes .../src/basiclayout/tutorial/static/headerbg.png | Bin 0 -> 203 bytes .../wiki/src/basiclayout/tutorial/static/ie6.css | 8 ++ .../wiki/src/basiclayout/tutorial/static/logo.png | Bin 6641 -> 0 bytes .../src/basiclayout/tutorial/static/middlebg.png | Bin 0 -> 2797 bytes .../src/basiclayout/tutorial/static/pylons.css | 47 ++++----- .../src/basiclayout/tutorial/static/pyramid.png | Bin 0 -> 33055 bytes .../basiclayout/tutorial/static/transparent.gif | Bin 0 -> 49 bytes .../basiclayout/tutorial/templates/mytemplate.pt | 31 +++--- .../wiki/src/models/tutorial/static/footerbg.png | Bin 0 -> 333 bytes .../wiki/src/models/tutorial/static/headerbg.png | Bin 0 -> 203 bytes .../wiki/src/models/tutorial/static/ie6.css | 8 ++ .../wiki/src/models/tutorial/static/logo.png | Bin 6641 -> 0 bytes .../wiki/src/models/tutorial/static/middlebg.png | Bin 0 -> 2797 bytes .../wiki/src/models/tutorial/static/pylons.css | 47 ++++----- .../wiki/src/models/tutorial/static/pyramid.png | Bin 0 -> 33055 bytes .../src/models/tutorial/static/transparent.gif | Bin 0 -> 49 bytes .../src/models/tutorial/templates/mytemplate.pt | 107 ++++++++++---------- .../wiki/src/views/tutorial/static/footerbg.png | Bin 0 -> 333 bytes .../wiki/src/views/tutorial/static/headerbg.png | Bin 0 -> 203 bytes .../wiki/src/views/tutorial/static/ie6.css | 8 ++ .../wiki/src/views/tutorial/static/logo.png | Bin 6641 -> 0 bytes .../wiki/src/views/tutorial/static/middlebg.png | Bin 0 -> 2797 bytes .../wiki/src/views/tutorial/static/pylons.css | 47 ++++----- .../wiki/src/views/tutorial/static/pyramid.png | Bin 0 -> 33055 bytes .../wiki/src/views/tutorial/static/style.css | 109 --------------------- .../wiki/src/views/tutorial/static/transparent.gif | Bin 0 -> 49 bytes .../wiki/src/views/tutorial/templates/edit.pt | 75 ++++++++------ .../src/views/tutorial/templates/mytemplate.pt | 107 ++++++++++---------- .../wiki/src/views/tutorial/templates/view.pt | 78 ++++++++++----- 43 files changed, 536 insertions(+), 637 deletions(-) create mode 100644 docs/tutorials/wiki/src/authorization/tutorial/static/footerbg.png create mode 100644 docs/tutorials/wiki/src/authorization/tutorial/static/headerbg.png create mode 100644 docs/tutorials/wiki/src/authorization/tutorial/static/ie6.css delete mode 100644 docs/tutorials/wiki/src/authorization/tutorial/static/logo.png create mode 100644 docs/tutorials/wiki/src/authorization/tutorial/static/middlebg.png create mode 100644 docs/tutorials/wiki/src/authorization/tutorial/static/pyramid.png delete mode 100644 docs/tutorials/wiki/src/authorization/tutorial/static/style.css create mode 100644 docs/tutorials/wiki/src/authorization/tutorial/static/transparent.gif create mode 100644 docs/tutorials/wiki/src/basiclayout/tutorial/static/footerbg.png create mode 100644 docs/tutorials/wiki/src/basiclayout/tutorial/static/headerbg.png create mode 100644 docs/tutorials/wiki/src/basiclayout/tutorial/static/ie6.css delete mode 100644 docs/tutorials/wiki/src/basiclayout/tutorial/static/logo.png create mode 100644 docs/tutorials/wiki/src/basiclayout/tutorial/static/middlebg.png create mode 100644 docs/tutorials/wiki/src/basiclayout/tutorial/static/pyramid.png create mode 100644 docs/tutorials/wiki/src/basiclayout/tutorial/static/transparent.gif create mode 100644 docs/tutorials/wiki/src/models/tutorial/static/footerbg.png create mode 100644 docs/tutorials/wiki/src/models/tutorial/static/headerbg.png create mode 100644 docs/tutorials/wiki/src/models/tutorial/static/ie6.css delete mode 100644 docs/tutorials/wiki/src/models/tutorial/static/logo.png create mode 100644 docs/tutorials/wiki/src/models/tutorial/static/middlebg.png create mode 100644 docs/tutorials/wiki/src/models/tutorial/static/pyramid.png create mode 100644 docs/tutorials/wiki/src/models/tutorial/static/transparent.gif create mode 100644 docs/tutorials/wiki/src/views/tutorial/static/footerbg.png create mode 100644 docs/tutorials/wiki/src/views/tutorial/static/headerbg.png create mode 100644 docs/tutorials/wiki/src/views/tutorial/static/ie6.css delete mode 100644 docs/tutorials/wiki/src/views/tutorial/static/logo.png create mode 100644 docs/tutorials/wiki/src/views/tutorial/static/middlebg.png create mode 100644 docs/tutorials/wiki/src/views/tutorial/static/pyramid.png delete mode 100644 docs/tutorials/wiki/src/views/tutorial/static/style.css create mode 100644 docs/tutorials/wiki/src/views/tutorial/static/transparent.gif (limited to 'docs/tutorials/wiki') diff --git a/docs/tutorials/wiki/src/authorization/tutorial/static/footerbg.png b/docs/tutorials/wiki/src/authorization/tutorial/static/footerbg.png new file mode 100644 index 000000000..1fbc873da Binary files /dev/null and b/docs/tutorials/wiki/src/authorization/tutorial/static/footerbg.png differ diff --git a/docs/tutorials/wiki/src/authorization/tutorial/static/headerbg.png b/docs/tutorials/wiki/src/authorization/tutorial/static/headerbg.png new file mode 100644 index 000000000..0596f2020 Binary files /dev/null and b/docs/tutorials/wiki/src/authorization/tutorial/static/headerbg.png differ diff --git a/docs/tutorials/wiki/src/authorization/tutorial/static/ie6.css b/docs/tutorials/wiki/src/authorization/tutorial/static/ie6.css new file mode 100644 index 000000000..b7c8493d8 --- /dev/null +++ b/docs/tutorials/wiki/src/authorization/tutorial/static/ie6.css @@ -0,0 +1,8 @@ +* html img, +* html .png{position:relative;behavior:expression((this.runtimeStyle.behavior="none")&&(this.pngSet?this.pngSet=true:(this.nodeName == "IMG" && this.src.toLowerCase().indexOf('.png')>-1?(this.runtimeStyle.backgroundImage = "none", +this.runtimeStyle.filter = "progid:DXImageTransform.Microsoft.AlphaImageLoader(src='" + this.src + "',sizingMethod='image')", +this.src = "static/transparent.gif"):(this.origBg = this.origBg? this.origBg :this.currentStyle.backgroundImage.toString().replace('url("','').replace('")',''), +this.runtimeStyle.filter = "progid:DXImageTransform.Microsoft.AlphaImageLoader(src='" + this.origBg + "',sizingMethod='crop')", +this.runtimeStyle.backgroundImage = "none")),this.pngSet=true) +);} +#wrap{display:table;height:100%} diff --git a/docs/tutorials/wiki/src/authorization/tutorial/static/logo.png b/docs/tutorials/wiki/src/authorization/tutorial/static/logo.png deleted file mode 100644 index 88f5d9865..000000000 Binary files a/docs/tutorials/wiki/src/authorization/tutorial/static/logo.png and /dev/null differ diff --git a/docs/tutorials/wiki/src/authorization/tutorial/static/middlebg.png b/docs/tutorials/wiki/src/authorization/tutorial/static/middlebg.png new file mode 100644 index 000000000..2369cfb7d Binary files /dev/null and b/docs/tutorials/wiki/src/authorization/tutorial/static/middlebg.png differ diff --git a/docs/tutorials/wiki/src/authorization/tutorial/static/pylons.css b/docs/tutorials/wiki/src/authorization/tutorial/static/pylons.css index c153be07f..4ebc5a081 100644 --- a/docs/tutorials/wiki/src/authorization/tutorial/static/pylons.css +++ b/docs/tutorials/wiki/src/authorization/tutorial/static/pylons.css @@ -4,34 +4,23 @@ body{line-height:1;} ol,ul{list-style:none;} blockquote,q{quotes:none;} blockquote:before,blockquote:after,q:before,q:after{content:'';content:none;} -/* remember to define focus styles! */ :focus{outline:0;} -/* remember to highlight inserts somehow! */ ins{text-decoration:none;} del{text-decoration:line-through;} -/* tables still need 'cellspacing="0"' in the markup */ table{border-collapse:collapse;border-spacing:0;} -/* restyling */ sub{vertical-align:sub;font-size:smaller;line-height:normal;} sup{vertical-align:super;font-size:smaller;line-height:normal;} -/* lists */ ul,menu,dir{display:block;list-style-type:disc;margin:1em 0;padding-left:40px;} ol{display:block;list-style-type:decimal-leading-zero;margin:1em 0;padding-left:40px;} li{display:list-item;} -/* nested lists have no top/bottom margins */ ul ul,ul ol,ul dir,ul menu,ul dl,ol ul,ol ol,ol dir,ol menu,ol dl,dir ul,dir ol,dir dir,dir menu,dir dl,menu ul,menu ol,menu dir,menu menu,menu dl,dl ul,dl ol,dl dir,dl menu,dl dl{margin-top:0;margin-bottom:0;} -/* 2 deep unordered lists use a circle */ ol ul,ul ul,menu ul,dir ul,ol menu,ul menu,menu menu,dir menu,ol dir,ul dir,menu dir,dir dir{list-style-type:circle;} -/* 3 deep (or more) unordered lists use a square */ ol ol ul,ol ul ul,ol menu ul,ol dir ul,ol ol menu,ol ul menu,ol menu menu,ol dir menu,ol ol dir,ol ul dir,ol menu dir,ol dir dir,ul ol ul,ul ul ul,ul menu ul,ul dir ul,ul ol menu,ul ul menu,ul menu menu,ul dir menu,ul ol dir,ul ul dir,ul menu dir,ul dir dir,menu ol ul,menu ul ul,menu menu ul,menu dir ul,menu ol menu,menu ul menu,menu menu menu,menu dir menu,menu ol dir,menu ul dir,menu menu dir,menu dir dir,dir ol ul,dir ul ul,dir menu ul,dir dir ul,dir ol menu,dir ul menu,dir menu menu,dir dir menu,dir ol dir,dir ul dir,dir menu dir,dir dir dir{list-style-type:square;} .hidden{display:none;} p{line-height:1.5em;} -h1{font-size:1.75em;/* 28px */ -line-height:1.7em;font-family:helvetica,verdana;} -h2{font-size:1.5em;/* 24px */ -line-height:1.7em;font-family:helvetica,verdana;} -h3{font-size:1.25em;/* 20px */ -line-height:1.7em;font-family:helvetica,verdana;} +h1{font-size:1.75em;line-height:1.7em;font-family:helvetica,verdana;} +h2{font-size:1.5em;line-height:1.7em;font-family:helvetica,verdana;} +h3{font-size:1.25em;line-height:1.7em;font-family:helvetica,verdana;} h4{font-size:1em;line-height:1.7em;font-family:helvetica,verdana;} html,body{width:100%;height:100%;} body{margin:0;padding:0;background-color:#ffffff;position:relative;font:16px/24px "Nobile","Lucida Grande",Lucida,Verdana,sans-serif;} @@ -42,23 +31,25 @@ body h2, body h3, body h4, body h5, -body h6{font-family:"Nobile","Lucida Grande",Lucida,Verdana,sans-serif;font-weight:normal;color:#144fb2;font-style:normal;} -#wrap {min-height: 100%;} -#header,#footer{width:100%;color:#ffffff;height:40px;position:absolute;text-align:center;line-height:40px;overflow:hidden;font-size:12px;} -#header{background-color:#e88f00;top:0;font-size:14px;} -#footer{background-color:#000000;bottom:0;position: relative;margin-top:-40px;clear:both;} -.header,.footer{width:700px;margin-right:auto;margin-left:auto;} +body h6{font-family:"Neuton","Lucida Grande",Lucida,Verdana,sans-serif;font-weight:normal;color:#373839;font-style:normal;} +#wrap{min-height:100%;} +#header,#footer{width:100%;color:#ffffff;height:40px;position:absolute;text-align:center;line-height:40px;overflow:hidden;font-size:12px;vertical-align:middle;} +#header{background:#000000;top:0;font-size:14px;} +#footer{bottom:0;background:#000000 url(footerbg.png) repeat-x 0 top;position:relative;margin-top:-40px;clear:both;} +.header,.footer{width:750px;margin-right:auto;margin-left:auto;} .wrapper{width:100%} #top,#bottom{width:100%;} -#top{color:#888;background-color:#eee;height:300px;border-bottom:2px solid #ddd;} -#bottom{color:#222;background-color:#ffffff;overflow:hidden;padding-bottom:80px;} -.top,.bottom{width:700px;margin-right:auto;margin-left:auto;} -.top{padding-top:100px;} +#top{color:#000000;height:230px; +background:#ffffff url(headerbg.png) repeat-x 0 top;position:relative;} +#bottom{color:#222;background-color:#ffffff;} +.top,.middle,.bottom{width:750px;margin-right:auto;margin-left:auto;} +.top{padding-top:40px;} +#middle{width:100%;height:100px;background:url(middlebg.png) repeat-x;border-top:2px solid #ffffff;border-bottom:2px solid #b2b2b2;} .app-welcome{margin-top:25px;} .app-name{color:#000000;font-weight:bold;} .bottom{padding-top:50px;} -#left{width:325px;float:left;padding-right:25px;} -#right{width:325px;float:right;padding-left:25px;} +#left{width:350px;float:left;padding-right:25px;} +#right{width:350px;float:right;padding-left:25px;} .align-left{text-align:left;} .align-right{text-align:right;} .align-center{text-align:center;} @@ -67,7 +58,7 @@ ul.links li{list-style-type:none;font-size:14px;} form{border-style:none;} fieldset{border-style:none;} input{color:#222;border:1px solid #ccc;font-family:sans-serif;font-size:12px;line-height:16px;} -input[type=text]{} +input[type=text],input[type=password]{width:205px;} input[type=submit]{background-color:#ddd;font-weight:bold;} /*Opera Fix*/ -body:before {content:"";height:100%;float:left;width:0;margin-top:-32767px;} +body:before{content:"";height:100%;float:left;width:0;margin-top:-32767px;} diff --git a/docs/tutorials/wiki/src/authorization/tutorial/static/pyramid.png b/docs/tutorials/wiki/src/authorization/tutorial/static/pyramid.png new file mode 100644 index 000000000..347e05549 Binary files /dev/null and b/docs/tutorials/wiki/src/authorization/tutorial/static/pyramid.png differ diff --git a/docs/tutorials/wiki/src/authorization/tutorial/static/style.css b/docs/tutorials/wiki/src/authorization/tutorial/static/style.css deleted file mode 100644 index cad87e0d4..000000000 --- a/docs/tutorials/wiki/src/authorization/tutorial/static/style.css +++ /dev/null @@ -1,109 +0,0 @@ -html, body { - color: black; - background-color: #ddd; - font: x-small "Lucida Grande", "Lucida Sans Unicode", geneva, sans-serif; - margin: 0; - padding: 0; -} - -td, th {padding:3px;border:none;} -tr th {text-align:left;background-color:#f0f0f0;color:#333;} -tr.odd td {background-color:#edf3fe;} -tr.even td {background-color:#fff;} - -#header { - height: 80px; - width: 777px; - background: blue URL('../images/header_inner.png') no-repeat; - border-left: 1px solid #aaa; - border-right: 1px solid #aaa; - margin: 0 auto 0 auto; -} - -a.link, a, a.active { - color: #369; -} - - -#main_content { - color: black; - font-size: 127%; - background-color: white; - width: 757px; - margin: 0 auto 0 auto; - border-left: 1px solid #aaa; - border-right: 1px solid #aaa; - padding: 10px; -} - -#sidebar { - border: 1px solid #aaa; - background-color: #eee; - margin: 0.5em; - padding: 1em; - float: right; - width: 200px; - font-size: 88%; -} - -#sidebar h2 { - margin-top: 0; -} - -#sidebar ul { - margin-left: 1.5em; - padding-left: 0; -} - -h1,h2,h3,h4,h5,h6,#getting_started_steps { - font-family: "Century Schoolbook L", Georgia, serif; - font-weight: bold; -} - -h2 { - font-size: 150%; -} - -#footer { - border: 1px solid #aaa; - border-top: 0px none; - color: #999; - background-color: white; - padding: 10px; - font-size: 80%; - text-align: center; - width: 757px; - margin: 0 auto 1em auto; -} - -.code { - font-family: monospace; -} - -span.code { - font-weight: bold; - background: #eee; -} - -#status_block { - margin: 0 auto 0.5em auto; - padding: 15px 10px 15px 55px; - background: #cec URL('../images/ok.png') left center no-repeat; - border: 1px solid #9c9; - width: 450px; - font-size: 120%; - font-weight: bolder; -} - -.notice { - margin: 0.5em auto 0.5em auto; - padding: 15px 10px 15px 55px; - width: 450px; - background: #eef URL('../images/info.png') left center no-repeat; - border: 1px solid #cce; -} - -.fielderror { - color: red; - font-weight: bold; -} diff --git a/docs/tutorials/wiki/src/authorization/tutorial/static/transparent.gif b/docs/tutorials/wiki/src/authorization/tutorial/static/transparent.gif new file mode 100644 index 000000000..0341802e5 Binary files /dev/null and b/docs/tutorials/wiki/src/authorization/tutorial/static/transparent.gif differ diff --git a/docs/tutorials/wiki/src/authorization/tutorial/templates/edit.pt b/docs/tutorials/wiki/src/authorization/tutorial/templates/edit.pt index 5f8b22207..1c764f924 100644 --- a/docs/tutorials/wiki/src/authorization/tutorial/templates/edit.pt +++ b/docs/tutorials/wiki/src/authorization/tutorial/templates/edit.pt @@ -1,34 +1,51 @@ - - - + + - - Pyramid tutorial wiki (based on TurboGears 20-Minute Wiki) - Editing: ${page.__name__} - + ${page.__name__} - Pyramid tutorial wiki (based on TurboGears 20-Minute Wiki) + + + + + + + + - - -
-
Viewing - Page Name Goes Here
- You can return to the FrontPage. - Logout -
- -
-
-