解耦 django 应用程序 2 - 如何从 URL 中的 slug 获取对象信息

发布于 2024-08-16 13:55:23 字数 646 浏览 4 评论 0原文

我正在尝试将两个应用程序分离:

  1. 位置 - 包含有关某些位置(城镇、国家、地方等)的详细信息的应用程序;
  2. 目录 - 包含感兴趣的地方(商店、火车站、酒吧等)详细信息的应用程序 - 所有分类。

locations.Locationdirectory.Item 都包含纬度/经度坐标,我可以找到特定纬度/经度坐标一定距离内的项目。

我想使用以下 URL 结构:

/locations//directory//

但我不想让我的目录应用程序依赖于我的位置应用程序。

如何翻译此网址以在我的目录应用程序中使用类似的视图?

items_near(lat, lng, distance, category):

解决方法是在某处创建一个新视图来翻译它 - 但我应该把它放在哪里?如果它进入目录应用程序,那么我会将其与我的位置应用程序结合起来,反之亦然。

将此解决方法代码放入我的项目 URL 文件中是否是一个好主意?从而远离这两个应用程序?这样做有什么问题吗?

I am trying to de-couple two apps:

  1. Locations - app containing details about some location (town, country, place etc)
  2. Directory - app containing details of places of interest (shop, railway station, pub, etc) - all categorised.

Both locations.Location and directory.Item contain lat/lng coords and I can find items within a certain distance of a specific lat/lng coord.

I'd like to use the following URL structure:

/locations/<location_slug>/directory/<category_slug>/

But I don't want to make my directory app reliant on my location app.

How can I translate this url to use a view like this in my directory app?

items_near(lat, lng, distance, category):

A work around would be to create a new view somewhere that translates this - but where should I put that? if it goes in the Directory app, then I've coupled that with my Location app, and vice versa.

Would a good idea be to place this workaround code inside my project URLs file? Thus keeping clear of both apps? Any issues with doing it like this?

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

扫码二维码加入Web技术交流群

发布评论

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

评论(3

海夕 2024-08-23 13:55:24

为了让你的 urlpattern 工作,调用的视图函数必须知道位置和目录。简短的回答是你可以把这个视图函数放在任何你想要的地方 - 它只是一个 python 函数。但是,在您的“目录”或“位置”应用程序之外,可能有一些有意义的逻辑位置。

首先,我不会将该视图代码放入顶级 urls.py 中,因为该文件用于 URLconf 相关代码。

关于放置视图的位置的几个选项:

  1. 在位于任何特定应用程序之外的文件中创建新的视图函数。 /views.py 是一种可能性。此视图从 Directory 应用程序调用 item_near(..) 视图没有任何问题。

    # 在 myproject/urls.py 中
    
    url 模式 = (
       ...
       (r'/locations/(?P[\w\-]+)/目录/(?P[\w\-]+)/', 
        'myproject.views.items_near_from_slug')
    )
    
    # 在 myproject/views.py 中
    
    从directory.views导入items_near
    
    def items_near_from_slug(请求、location_slug、category_slug):
      位置 = get_object_or_404(位置, slug=location_slug)
    
      distance = 2 # 不确定它来自哪里
    
      # 然后只需从您的目录应用程序调用视图
      返回 items_near(请求、location.lat、location.lng、距离、category_slug)
    
  2. 创建一个新应用并将代码放入 /views.py 中。 Django 应用程序不需要有 models.py、urls.py 等。如果您希望 Django 正确加载应用程序,只需确保包含 __init__.py (如果,例如,您希望 Django 自动查找模板标签或应用程序特定模板)。

就我个人而言,只有当项目相对简单,并且 /views.py 不会面临因所有视图而变得混乱的危险时,我才会选择选项 1。否则我会选择选项 2,特别是如果您预计有其他代码需要了解位置和目录。使用选项 2,您也可以在自己的应用程序特定的 urls.py 中收集相关的 urlpatterns。

For your urlpattern to work, the view function invoked has to be aware of both Locations and Directories. The short answer is you can put this view function anywhere you want - it's just a python function. But there might be a few logical places for it, outside of your Directory or Location app, that make sense.

First off, I would not put that view code in in your top-level urls.py, as that file is intended for URLconf related code.

A few options of where to put your view:

  1. Create a new view function in a file that lives outside of any particular app. <project_root>/views.py is one possibility. There is nothing wrong with this view calling the item_near(..) view from the Directory app.

    # in myproject/urls.py
    
    urlpatterns = (
       ...
       (r'/locations/(?P<location_slug>[\w\-]+)/directory/(?P<category_slug>[\w\-]+)/', 
        'myproject.views.items_near_from_slug')
    )
    
    # in myproject/views.py
    
    from directory.views import items_near
    
    def items_near_from_slug(request, location_slug, category_slug):
      location = get_object_or_404(Location, slug=location_slug)
    
      distance = 2 # not sure where this comes from
    
      # And then just invoke the view from your Directory app
      return items_near(request, location.lat, location.lng, distance, category_slug)
    
  2. Create a new app and put the code there, in <my_new_app>/views.py. There is no requirement that a Django app need to have a models.py, urls.py, etc. Just make sure to include the __init__.py if you want Django to load the app properly (if, for instance, you want Django to automatically find templatetags or app specific templates).

Personally, I would go with option 1 only if the project is relatively simple, and <project_root>/views.py is not in danger of becoming cluttered with views for everything. I would go with option 2 otherwise, especially if you anticipate having other code that needs to be aware of both Locations and Directories. With option 2, you can collect the relevant urlpatterns in their own app-specific urls.py as well.

混吃等死 2024-08-23 13:55:24

从 django 文档 此处 如果您正在使用 django >=1.1 那么您可以将任何捕获的信息传递到包含的应用程序中。因此分成几个文件:

# in locations.urls.py

urlpatterns = ('',
  (r'location/(?P<location_slug>.*?)/', include('directory.urls')),
  #other stuff
  )


# in directory.urls.py

urlpatterns = ('',
  (r'directory/(?P<directory_slug>.*?)/', 'directory.views.someview'),
  #other stuff
  )

# in directory.views.py

def someview(request, location_slug = None, directory_slug = None):
 #do stuff

希望有帮助。如果你在 django < 1.1 我不知道。

From the django docs here if you're using django >=1.1 then you can pass any captured info into the included application. So splitting across a few files:

# in locations.urls.py

urlpatterns = ('',
  (r'location/(?P<location_slug>.*?)/', include('directory.urls')),
  #other stuff
  )


# in directory.urls.py

urlpatterns = ('',
  (r'directory/(?P<directory_slug>.*?)/', 'directory.views.someview'),
  #other stuff
  )

# in directory.views.py

def someview(request, location_slug = None, directory_slug = None):
 #do stuff

Hope that helps. If you're in django < 1.1 I have no idea.

若言繁花未落 2024-08-23 13:55:24

无论您的应用程序具有多少“可重用性”,都不可避免地需要特定于站点的代码。

我认为创建一个使用可重用和解耦应用程序的视图的“特定于站点”的应用程序是合乎逻辑的。

Irrespective of how much ever "re-usable" you make your app, inevitably there is a need for site-specific code.

I think it is logical to create a "site-specific" application that uses the views of the reusable and decoupled apps.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文