أريد إنشاء إضافة (plugin) تحتاج إلى جداول خاصة بها. لذا، يُعد وجود مولدات للهجرات (migrations) والنماذج (models) فكرة جيدة، لأن نسخها يدويًا من مجلد التطبيق الرئيسي قد يؤدي إلى أخطاء وهو أمر غير مريح. لذا، بدأت في إنشاء مولداتي الخاصة. بدأت بمولد الهجرات:
يمكنني الآن المضي قدمًا والقيام بنفس الشيء للنماذج والوحدات التحكمية (controllers). لكنني بدأت الآن في قراءة هذا الدليل: https://guides.rubyonrails.org/engines.html، ويبدو لي الآن أن كل هذا قد يكون تكرارًا للجهود. لماذا يختلف مولد إضافات discourse إلى هذا الحد عن مولد إضافات rails؟
مولد إضافات rails ينشئ ملف bin/rails خاص بالإضافة، مما يمكّن من استخدام مولدات الهجرات والنماذج الخاصة بها. سيكون من الرائع وجود شيء مشابه لهذا. لقد حاولت إنشاء شيء مماثل، لكنني لم أستطع جعله يعمل، لذا سلكْتُ المسار الآخر وبدأت ببساطة في إنشاء هذه المولدات الفريدة من نوعها. إذا فهمتُ بشكل أفضل الفروقات بين طريقة rails وطريقة discourse في إنشاء الإضافات، لربما تمكّنت من اتباع ذلك المسار الآخر مما قد يوفر الوقت. ربما يتمكن شخص ما من التوضيح أكثر. لماذا تُعد إضافات discourse وrails شيئًا مختلفًا، ولماذا لا تبني إحداهما على الأخرى؟
Rails plugins are different from Discourse plugins due to many reasons. Discourse plugins need to have a specific folder structure, they can extend/override the ember code of the core discourse etc. I think the rails side of a discourse plugin would be closer to a generic rails plugin but they aren’t the same things.
Moreover, one should only create new tables if they’re really needed. Discourse already has ~150 tables and its not too often that your job isn’t done using one or a couple of them.
But, moving forward, I personally would wish and like to see that happen. It would mean people are building huge and more exciting plugins and getting more creative with what could be done with Discourse.
I need them. Even basic functionality needs tables. I think its really annoying that there is no clear documented way on how to do this. For example the poll plugin uses its own tables, but I cant find the generator for how to make them. discourse/plugins/poll at main · discourse/discourse · GitHub
Another benefit from documenting is that there will be conventions on table/migration namespacing. (I saw some really hacky solutions recommended here in the forums on how to add migrations to a plugin)
Nice! So which way to go? moving closer to the rails plugin generator with own bin/rails in the plugin folder, or own versions for all the generators (migrations/models/controllers) ?
You need to read the plugin development howto topics here. For most plugins you can use existing tables (like post custom field). There are times that you need more tables, but you’d probably do well to start with something less difficult to start.
I read the beginners plugin guide and this . Is there something else? I also looked at the code of some plugins. I just know that I need tables. And there are other plugins as well that use their own tables. Why is there this obsession with not creating new tables? Is there a big cost involved with creating new tables? Especially if they are namespaced with the plugin name at the beginning I really dont see the downside.
These ones here. I highly recommend these ones hands on before making any comment about anything related to dev. Not to say you might not need custom tables ever but these are must anyway.
this thing is just a basic key value store. I cant store relations between tables there. I like SQL. And I need to use it for the plugin I want to create.
I can understand this problem applies to people that want to create plugins that “non technical people” can install and uninstall. I am not one of those people. So I would be glad if we could go back to the topic.
If the intent is to create something only you yourself will be using, IMHO it would likely be better to write a browser extension or a desktop app instead of a plugin. Any reason this must be a plugin?