构建管理员/用户/公共控制器的 Rails 方式

发布于 2024-09-08 08:12:58 字数 727 浏览 2 评论 0原文

一个虚构的 Rails 应用程序具有以下资源：

Photographers
Images
Comments

摄影师 有许多 图像，其中有许多 评论

每个摄影师都有一个登录名并能够查看，上传、编辑和删除他们的图像、评论以及他们自己的个人资料。

提供管理界面，可以编辑图像、摄影师和评论。

此外，无需登录即可从公共界面获取摄影师、他们的图像和评论，访问者可以在其中添加评论。

我的问题是：构建控制器的 Rails 方式是什么？我正在考虑为每个“角色”（公共、帐户、管理员）使用命名空间，如下所示：

# For administrator
Admin::PhotographersController
Admin::ImagesController
Admin::CommentsController

# For a logged in photographer
AccountController (?)
Account::ImagesController
Account::CommentsController

# For public
PhotographersController
ImagesController
CommentsController

但是 - 这些控制器的某些方法是重叠的。这是最好的方法吗，即使它不是那么干？

谢谢！

原文

A fictitious Rails app has the following resources:

Photographers
Images
Comments

A Photographer has many Images, that have many Comments

Each photographer has a login and is able to view, upload, edit and delete their images, comments as well as their own profile.

An administration interface is available and can edit both images, photographers and comments.

Furthermore, the photographer, their images and their comments are available from a public interface without login where visitors can add comments.

My question is: What is the Rails-way of structuring the controllers? I was thinking of going with namespaces for each 'role' (public, account, admin) like this:

# For administrator
Admin::PhotographersController
Admin::ImagesController
Admin::CommentsController

# For a logged in photographer
AccountController (?)
Account::ImagesController
Account::CommentsController

# For public
PhotographersController
ImagesController
CommentsController

However - some of the methods of these controllers are overlapping. Is this the best way, even though it's not that DRY?

Thanks!

分享到QQ

分享到微博

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

发布评论

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

贱人配狗天长地久 2024-09-15 08:12:59

如果它们重叠，您可以将基本控制器扩展到帐户/管理命名空间。例如，您使用 ImagesController 来执行每个人都可以看到的操作。这会像平常一样扩展 ApplicationController。然后你做你的管理版本的ImageController，它扩展了ImagesController。然后，您可以在管理版本中添加/覆盖所需的不同行为的方法，或者可能只是像添加几个过滤器一样简单，例如 require_admin，它检查 current_user 是否是管理员用户，如果不是。

回复收藏 0 原文

贵在坚持 2024-09-15 08:12:59

正如你所说，这并不是真正的 DRY。至少，您可以构建路由和控制器来满足所有要求，例如：

resources :photos, :only => [:index, :show] # offer only index and show actions to public 

scope "/admin" do
  resources :photos # full access for logged in users
end

如果您还需要索引和显示操作，您可以在其中添加一些检查以加载不同的视图（假设您有公共和管理布局）。

另一种方法可能是拥有独特的布局，没有 /admin/ 部分，并向登录用户提供编辑功能。因此，如果已登录并且是某些照片的所有者，则允许编辑并显示上下文链接。这是口味问题：P

as you said, this is not really DRY. at least, you could structure routes and controllers to act for all the requirements, for example:

resources :photos, :only => [:index, :show] # offer only index and show actions to public 

scope "/admin" do
  resources :photos # full access for logged in users
end

if you also need index and show actions, you can add some checks inside them to load a different view (say you have a public and admin layouts).

another way could be to have a unique layout, no /admin/ sections and offer editing features to logged in users. so if logged and owner of some photo, allow editing and show context links. it's a matter of tastes :P

回复收藏 0 原文

~没有更多了~