将文本转换为代码
我正在创建产品配置器。问题是每个产品都有许多组件,而这些组件本身是可配置的。想象一下您在购买计算机时正在配置它。 有时,当选择一个组件、或一定数量的组件、甚至两者的组合时,依赖关系有时会适用。在某些时候,这一切都会变得非常复杂,并且不同产品之间并不一致,因为从某种意义上来说,每个产品都有自己的宇宙。
哦,这些规则一直在变化,所以在应用程序中编码它们对我来说并不是一个真正的选择。
我希望能够将名为 validate 的方法的代码存储在数据库中。 每个配置都有自己的验证版本,该版本将作为文本存储在数据库中,并且可以在需要时进行更改。
可以这样做吗?我如何获取文本并让 Rails 实际执行该文本所说的内容?
例如我有这个:
irb(main):246:0> @h= Configuration.find(1).rule
=> "def getmax3(inputarray)\n @maxpos = 0\n inputarray.each do |h|\n if @maxpos < h.position\n @maxpos = h.position\n end\n end\n 1\n end"
这显然不是代码。当然,上面的方法只是一个测试,因为我正在尝试解决问题。
(哦,我知道这样做一定是可怕的做法,但我真的想不出其他方法)
非常感谢!
I'm in the process of creating a product configurator. Trouble is that each product has many components, which are themselves configurable. Imagine you're configuring a computer when buying it.
The dependencies sometimes apply when a component is selected, or when a quantity of a component, or even a combination of both. It all becomes very complicated at some point, and is not consistent across products, as each is its own universe in a sense.
Oh, and these rules change all the time, so coding them in the app is not really an option for me.
I was hoping to be able to store the code of a method called validate in the database.
Each configuration would have it's own version of validate, which would be stored as a text in the db, and could be changed if/when required.
Is is possible to do this? How can i take text and have rails actually execute whatever this text says?
For example i have this:
irb(main):246:0> @h= Configuration.find(1).rule
=> "def getmax3(inputarray)\n @maxpos = 0\n inputarray.each do |h|\n if @maxpos < h.position\n @maxpos = h.position\n end\n end\n 1\n end"
which obviosly isn't code. The method above is of course just a test as I'm trying to figure things out.
(Oh and I know it must be horrible practice to do this, but I really can't think of another way)
Thanks a lot!
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
是的,这是一种可怕的做法:)
如果您要实现简单且稳定的规则,您可以将一些变量存储在专用表中,并在您的规则中使用这些变量;由于您似乎并不真正知道这些规则会发生什么,因此请准备好使用经过测试和验证的工作流程来接受任何挑战。
这是我的建议:
如果您长期致力于操纵此类规则并且您不可能是唯一负责此类任务的人,那么定义 DSL 可以让您的生活变得更轻松;观察规则如何在一段时间内发生变化,您就会知道拥有专用 DSL 是好事还是浪费时间。
Yes it is an horrible practice :)
If you had simple and stabilized rules to implement, you could store some variables in a dedicated table and use those variables in your rules; since it looks like you don't really know what is going to happen about those rules, be ready to accept any challenge by using a tested and proven workflow.
Here's my suggestion:
Defining a DSL can make your life easier, if you are committed in the long term to manipulate such rules and you could not be the only one in charge of such task; observe how the rules are changed over a good amount of time and you will know if having a dedicated DSL is a good thing or a waste of time.
我可能会误解您的问题,但如果您可以将该代码从数据库中取出并放入可以测试和版本控制的文件中,那么您将处于一个更快乐的地方。在不了解模型的复杂性的情况下,很难说出最好的方法是什么,但我保证一定有一种方法。
我过去曾使用单表继承来对具有共享共同属性和行为的相关组件的复杂系统进行建模。您也许可以在您的应用程序中使用这种方法。 STI 基本上表示您有一个父类(在您的例子中为 Configuration)和子类,它们都驻留在同一个表中。如果某些但不是所有子类之间存在共享行为,那么您可以将该代码移至模块并包含在需要它的类中。
基本父类将从 ActiveRecord 继承:
然后每个子类都会在其中定义其逻辑:
我并不是说这是您想要的方向,但希望它会让您考虑其他建模方法系统。
I might be misunderstanding your problem, but if you could get that code out of the database and into files that can be tested and versioned, you'll be in a much happier place. Without knowing the intricacies of your models, it's hard to say what the best approach would be, but I guarantee one is out there.
I've used Single Table Inheritance in the past for modeling complex systems that have related components which share common properties and behavior. You might be able to use this approach with your application. STI basically says you have a parent class, in your case Configuration, and subclasses, that all reside in the same table. If there is shared behavior among some but not all of the subclasses, then you can move that code to modules and include in the classes that need it.
Basic parent class would just inherit from ActiveRecord:
Then each subclass would have its logic defined within it:
I'm not saying this is the direction you want to go, but hopefully it will make you think about other ways of modeling your system.