了解金字塔中的资源和上下文

发布于 2024-11-15 09:26:55 字数 682 浏览 2 评论 0原文

请耐心等待，因为我刚刚开始使用 Pyramid。我无法理解 Pyramid 中关于 URL 调度 的上下文和资源。我不太确定文档中的描述意味着什么，上下文和资源有点循环（对我来说）。

金字塔中的资源是什么？这只是 url 试图代表的内容吗？例如，如果 url 为 /organization/add_users，则资源是组织还是用户？
上下文也是上例中的组织吗？

另外，

上下文对象到底是什么？
上下文对象应该包含什么？教程中的示例只有 ACL，init 方法中没有任何内容。
```
类 RootFactory(对象):
__acl__ = [(...一些权限...)]

def __init__(自身):
    经过
```
当抛出异常时（例如 Forbidden），上下文到底在什么时候发生变化？
当出现禁止错误之类的情况时，我可以看到更改上下文的目的，但是当执行验证之类的操作时，为什么我应该抛出一个使用不同的 view_callable 注册的异常，该异常会呈现到不同的模板，当我可以简单地渲染到同一个 view_callable 中的不同模板，而不是抛出异常？（我在文档中看到了 add_view 的验证错误示例）

Please bear with me, since I am just getting started with Pyramid. I am having trouble understanding context and resource in Pyramid, with regards to URL Dispatch. I'm not quite sure what it means from the description in the documentation, context and resource is somewhat circular (to me).

What is a resource in pyramid? Is it just what the url is trying to represent?
For example, if the url is /organization/add_users, is the resource organization or users?
Is the context also organization in the example above?

Also,

What exactly is a context object?
What is the context object supposed to contain? The example in the tutorial only has the ACL and has nothing in the init method.
```
class RootFactory(object):
__acl__ = [(...some permissions...)]

def __init__(self):
    pass
```
When an exception is thrown (Forbidden for instance) at what point exactly does the context change?
I can see the purpose of the changing context when there is something like a Forbidden error, but when doing something like validation, why should I throw an exception that is registered with a different view_callable, which renders to a different template, when I can simply render to a different template within the same view_callable instead of throwing the exception? (I saw a validation error example for add_view in the docs)

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

机场等船 2024-11-22 09:26:55

首先，您在使用 URL Dispatch 时想要关心这些东西的主要原因是为了使用金字塔的身份验证系统。如果您不关心这一点，那么您可以完全忽略上下文和资源树并继续进行调度。

资源树

金字塔有一个独特的资源树概念，它实际上是映射到路径的对象树。该树从根部向下遍历到所提供路径的末端。在遍历期间，如果路径耗尽或树到达离开节点，则树中的该对象现在是上下文。

在 URL Dispatch 中，不会发生遍历（默认情况下），因此上下文将始终是资源树的根。

一般来说，您可以将上下文用于应用程序中您想要的任何内容。 ACLAuthorizationPolicy 显式使用它来确定权限。这是一个完整的主题，我建议查看我的演示，它解释了如何通过 URL 调度使用 Pyramid 的身份验证系统 [1 ]。

异常

Pyramid 中的异常处理通过两种不同的方式完成：

您可以在视图中使用 try: except: 返回不同的响应。
您可以利用异常视图来更普遍地处理应用程序中的异常。

请注意，渲染 404 页面需要第二种方式，如果您使用 Pyramid 的身份验证，也需要使用禁止页面。这是因为 Pyramid 内部会抛出 NotFound 和 Forbidden 异常，如果您想自定义它们，则必须捕获并渲染它们。

当抛出异常并且注册了一个与该类型匹配的异常视图时，Pyramid 将调用异常视图并将异常作为新上下文传递，因此上下文发生更改。

我不确定验证是异常视图的一个很好的例子。更常见的是，视图用于错误情况，或用于短路应用程序非视图部分的执行。例如，当您的视图无法连接到数据库时，或者当您想要返回 4xx 或 5xx 响应时，您可能想要处理并返回不同的页面。默认情况下，如果不处理异常，WSGI 服务器只会将其转换为通用 500 页面。异常视图允许您自定义该行为。

所有这一切的重要要点是它都是可选的。如果您感到困惑，请不要担心，因为您可以在没有这些东西的情况下使用 Pyramid，并且当您变得更加熟悉时，您可以开始将它们合并到您的应用程序中。

First of all, the main reason that you would want to even care about this stuff when using URL Dispatch is for the purposes of using pyramid's auth system. If you don't care about that, then you can completely ignore contexts and resource trees and go on with dispatch.

Resource Trees

Pyramid has a unique concept of a resource tree, which is literally a tree of objects that is mapped to a path. This tree is traversed from the root down to the end of a supplied path. During traversal if the path is exhausted or the tree hits a leave node, that object in the tree is now the context.

In URL Dispatch, traversal does not occur (by default), thus the context will always be the root of your resource tree.

In general, you can use the context for anything you want in your application. It is used explicitly by the ACLAuthorizationPolicy to determine permissions. This is a whole topic, and I'd suggest checking out my demo that explains how to use Pyramid's auth system with URL Dispatch [1].

Exceptions

Exception handling in Pyramid is done in two different ways:

You can use try: except: in your view to return a different response.
You can utilize exception views to more generally handle exceptions within your app.

Note that the second way is required for rendering 404 pages and if you're using Pyramid's auth, forbidden pages too. This is because Pyramid internally throws the NotFound and Forbidden exceptions that you must catch and render if you want to customize them.

When an exception is thrown and there is an exception view registered to match that type, Pyramid will invoke the exception view and pass in the exception as the new context, so that's when the context changes.

I'm not sure validation is a good example of an exception view. More typically the views are used for error cases, or to short-circuit execution in non-view parts of your application. For example you may want to handle and return different pages when your view fails to connect to your database, or when you want to return a 4xx or 5xx response. By default if the exception is not handled, the WSGI server just turns it into a generic 500 page. Exception views let you customize that behavior.

The important takeaway from all of this is that it's all optional. If you're confused, don't worry because you can utilize Pyramid without these things, and as you grow more comfortable you can begin to incorporate them into your application.

回复收藏 0 原文