【问题标题】:In rails how to allow creation of new class and models at run time在 Rails 中如何允许在运行时创建新的类和模型
【发布时间】:2018-04-16 19:52:33
【问题描述】:

我正在为我的公司产品开发的 Rails 应用程序面临设计问题。我的应用程序允许创建两个类,它们是父类的子类。

class Coupon
  include Commonelements
end

class ServiceCenterCoupon < Coupon
end

class DealershipCoupon < Coupon
end

当您转到视图并想要创建新优惠券时,您可以选择两者中的任何一个,然后根据参数 [:coupon_type] 创建新优惠券

在控制器中:

if params[:coupon_type] == 'dealershipcoupon'
 @coupon = DealershipCoupon.new(coupon_params)
  if @coupon.save!
   redirect_to @coupon
  else
   render :new
  end
elsif params[:coupon_type] == 'servicecentercoupon'
 @coupon = ServiceCenterCoupon.new(coupon_params)
  if @coupon.save!
   redirect_to @coupon
  else
   render :new
  end
end

我也想让管理员用户能够在运行时创建新的优惠券类型。比如说,有人想创建 Repairshopcoupons 类。 我需要对视图进行哪些更改,例如添加一个新表单或者我需要向现有表单添加哪些参数才能在运行时创建新的优惠券子类? p>

我明白使用

repairshopcoupon = Class.new() 

可以工作。例如,控制器中的此代码之类的匿名函数可以工作:

Repairshopcoupon = Class.new(Coupon) do
  include ActiveModel::Validations
  validates_presence_of :title

  def self.name
    "Oil Change"
  end   
end

@newrepairshopcoupon = Repairshopcoupon.new
@newrepairshopcoupon.save

但我不确定。

我的第一个问题是:如果我希望用户从视图中创建新类,那么正确的流程是什么。控制器应该处理什么以及它将如何保存?

我的第二个问题是:很少有客户同时属于经销商和服务中心组。每个组都有权管理他们可以管理的优惠券类型。我希望属于多个组的这些用户能够查看各自的优惠券库存以及哪些用户下载了这些库存。我觉得有必要更改我的数据模型,以便所有优惠券库存和下载列表完全属于一个授权组,但我不知道什么是最好的方法。

我的第三个问题是:更改我的视图/UX 以创建和管理优惠券以便多个组的用户能够在每个库存之间切换的最佳方法是什么?在这种情况下,UX 设计的专业行业标准是什么?

非常感谢您的帮助。

【问题讨论】:

  • 您应该将自己限制在一个问题上。尤其是当它们像这样广泛时。

标签: ruby-on-rails ruby class oop anonymous


【解决方案1】:

让应用程序的用户在运行时生成代码是一个非常糟糕的主意,因为潜在的错误和漏洞的数量令人难以置信,因为您基本上允许在运行时将未经测试的代码注入应用程序。

它还会破坏应用程序中任何基于类的缓存。

它也不适用于 Heroku 等使用从上次代码提交创建的临时文件系统的云平台。

首先,您实际上可能并不需要为每种“类型”的优惠券设置不同的类别。您需要考虑每个类的逻辑是否大不相同。

您可能只需创建与发行人(交易或服务中心)的多态关联即可。

class Coupon < Coupon
  belongs_to :issuer, polymorphic: true
end

如果您想避免多态性,而不仅仅是将其设置为标准 STI 设置:

class Coupon
  include Commonelements
end

class ServiceCenterCoupon < Coupon
  self.table_name = 'coupons'
  belongs_to :service_center
end

class DealershipCoupon < Coupon
  self.table_name = 'coupons'
  belongs_to :dealership
end

【讨论】:

  • 酷!优惠券是子类,因为它们在其他方面确实有所不同。 Coupon 类是抽象的,只有子类实现了各自的 uploaders。这是我要使用的架构。如果我只创建 Coupon 类的实例,我无法为每种类型创建不同的表。每个使用此应用程序的内部运营团队人员将只管理一种优惠券的库存。我的主要问题是用户如何在运行时通过用户视图创建新的优惠券。就像他们可以在通过视图/UI/创建优惠券时定义这些优惠券的新属性一样/
  • 另外,您认为最好的用户体验设计允许同时属于这两个组的用户。当我根据用户类型限制访问时,他们是否需要切换类型?我觉得我希望他们能够在登录后切换标签并查看相应的库存。但是问题又是每个优惠券应该只属于一个组我怎样才能在控制器中获取所有数据,以便我可以在里面的不同选项卡中显示它。
  • 我会使用角色系统,其中用户有许多角色,用于确定他们是否可以执行操作。您可以使用 Rolify 和 Pundit 非常简单地构建它。
  • 大多数拥有多种用户类型的系统通常只是过于复杂的混乱。 RBAC 更加灵活和可扩展。
猜你喜欢
  • 1970-01-01
  • 2010-11-26
  • 2014-04-12
  • 1970-01-01
  • 2021-07-12
  • 2021-08-11
  • 2011-12-09
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多