ضبط تطبيقات ريلز

من موسوعة حسوب

يغطي هذا الدليل ميزات الضبط والتهيئة المتاحة لتطبيقات ريلز. بعد قراءة هذا الدليل، ستتعلم:

  • كيفية ضبط سلوك تطبيقات ريلز.
  • كيفية إضافة شيفرة مصدريّة إضافية لتنفيذها وقت بدء تشغيل التطبيق.

مواقع شيفرة التهيئة والضبط

يوفر ريلز أربعة مواضع رئيسيّة لوضع الشيفرة المصدريّة للتهيئة:

  • config/application.rb
  • ملفات الضبط (configuration) الخاصة بالبيئة
  • المهيآت (Initializers)
  • ما بعد المهيآت (After-initializers)

تشغيل شيفرة برمجية قبل ريلز

في أحيان نادرة، يحتاج تطبيقك لتشغيل بعض الشيفرات البرمجية قبل تحميل ريلز نفسه، ذا ضعها آنذاك قبل استدعاء require 'rails/all'‎ في config/application.rb.

ضبط مكونات ريلز

بشكل عام، تعني مهمة ضبط ريلز إعداد مكونات ريلز بالإضافة إلى ريلز نفسه. يسمح لك ملف الضبط config/application.rb وملفات الضبط الخاصة بالبيئة (مثل الملف config/environments/production.rb) بتحديد الإعدادات المتنوّعة التي تريد تمريرها إلى كافة المكونات.

على سبيل المثال، يمكنك إضافة هذا الإعداد إلى الملف config/application.rb:

config.time_zone = 'Central Time (US & Canada)'

هذه إعدادات لريلز نفسه، إذا كنت ترغب في تمرير الإعدادات إلى مكونات ريلز فرديّة، فيمكنك القيام بذلك عبر نفس كائن الضبط في config/application.rb:

config.active_record.schema_format = :ruby

سيستخدم ريلز هذا الإعداد لضبط Active Record.

إعدادات ريلز العامة

ستُستدعى توابع الإعدادات هذه على الكائن Rails::Railtie مثل صنف فرعي من Rails::Engine أو Rails::Application.

  • config.after_initialize: يأخذ الكتلة التي سيتم تنفيذها بعدما ينتهي ريلز من تهيئة التطبيق، ويتضمّن هذا تهيئة الإطار نفسه، والمحركات، وجميع مهيئات التطبيق في config/initializers، لاحظ أن هذه الكتلة ستُنفَّذ لمهام البداية، وهي مفيدة لضبط القيم المعدّة بواسطة مهيئات أخرى:
config.after_initialize do
  ActionView::Base.sanitized_allowed_tags.delete 'div'
end
  • config.asset_host: يعيّن المضيف للأصول (assets)، وهو مفيدة عندما يُستخدم CDN لاستضافة الأصول أو عندما تريد العمل حول قيود التزامن المضمنة في المتصفحات باستخدام أسماء النطاقات المستعارة المختلفة. وهي نسخة مختصرة لـ config.action_controller.asset_host.
  • config.autoload_once_paths: يقبل مصفوفة من المسارات التي سيحمل ريلز تلقائيًّا الثوابت منها التي لن تمسح لكل طلب، وهي مناسبة إذا كان config.cache_classes يساوي false، والتي هي الحالة الافتراضيّة لوضع التطوير. وخلاف ذلك، يحدث كل التحميل التلقائي مرّة واحدة فقط، ويجب أن تكون جميع عناصر هذه المصفوفة في autoload_paths. بشكل افتراضي هي مصفوفة فارغة.
  • config.autoload_paths: يقبل مصفوفة من المسارات التي يحمل ريلز بشكل تلقائي الثوابت منها، وبشكل افتراضي هي جميع المجلدات داخل app، ولم يعد من المستحسن ضبط هذا. راجع الثوابت المحملة والمعاد تحميلها تلقائيًّا.
  • config.cache_classes: يتحكم ما إذا كان يجب إعادة تحميل أصناف التطبيق والوحدات في كل طلب، وبشكل افتراضي تكون قيمتها false في وضع التطوير و true  في أوضاع الاختبار والإنتاج.
  • config.beginning_of_week: يعيّن بداية الأسبوع الافتراضيّة للتطبيق، وهو يقبل رمزًا يمثِّل يوم أسبوع صحيح (على سبيل المثال ‎:monday).
  • config.cache_store: يضبط أي تخزين مؤقت يراد استخدامه في ريلز. تتضمن الخيارات أحد الرموز التالية: ‎:memory_store، أو ‎:file_store، أو ‎:mem_cache_store، أو ‎:null_store أو كائن يطبّق واجهة برمجة التطبيقات لذاكرة التخزين المؤقت، ويكون افتراضيًا مساويًا إلى ‎:file_store.
  • config.colorize_logging: يحدد استخدام رموز ألوان ANSI أو لا عند تسجيل المعلومات، وقيمته الافتراضية هي true.
  • config.consider_all_requests_local: هو راية. إذا كان مساوي للقيمة true، فأي خطأ سيؤدي إلى تفريغ معلومات التنقيح في استجابة HTTP، وسيعّرض متحكم Rails::Info سياق وقت التشغيل للتطبيق في ‎/rails/info/properties. وقيمته true بشكل افتراضي في وضع التطوير والاختبار، و false في وضع الإنتاج. وللتحكم به بشكل دقيق، اضبط هذه الراية إلى القيمة false ونفّذ local_request?‎ في المتحكم لتحديد أي طلبات يجب توفير معلومات التنقيح على الأخطاء.
  • config.console: يسمح لك بتعيين الصنف الذي سيُستخدم كطرفية عند تنفيذ rails console، ومن الأفضل تنفيذه في الكتلة console.
console do
  # فقط console تستدعى هذه الكتلة عند تنفيذ
  # هنا pry وبذلك يمكننا بأمان طلب
  require "pry"
  config.console = Pry
end
  • config.eager_load: عندما تكون قيمته true، ستحمّل جميع تسجيلات config.eager_load_namespaces بشكل حثيث. ويتضمن هذا تطبيقك، والمحركات، وأطر ريلز وأي مجالات أسماء مسجلة (registered namespace) أخرى.
  • config.eager_load_namespaces: يسّجل مجالات الأسماء التي ستحمّل بشكل حثيث عندما يكون config.eager_load مساويًا إلى القيمة true. يجب أن تستجيب جميع مجالات الأسماء إلى التابع eager_load!‎.
  • config.eager_load_paths: يقبل مصفوفة من المسارات التي سيحمّل ريلز منها عند بدء التشغيل بشكل حثيث إذا كانت أصناف ذاكرة التخزين المؤقت مفعّلة. تُعيَّن قيمته الافتراضية إلى كل مجلد في المجلد app الخاصة بالتطبيق.
  • config.enable_dependency_loading: عندما يكون true، فسيُفعَّل التحميل التلقائي، حتى إذا كان التطبيق محمل بشكل حثيث وكان config.cache_classes مضبوطًا إلى القيمة true. قيمته الافتراضية هي false.
  • config.encoding: تعمل على إعداد الترميز على مستوى التطبيق، وهي بشكل افتراضي تساوي UTF-8.
  • config.exceptions_app: تعيّن استثناءات التطبيق المستدعية بواسطة الوسيط ShowException عند حدوث الاستثناء. قيمته الافتراضية هي ActionDispatch::PublicExceptions.new(Rails.public_path)‎.
  • config.debug_exception_response_format: تعيّن التنسيق المستخدم في الاستجابات عند حدوث الأخطاء في وضع التطوير. قيمته الافتراضية هي: ‎:api لتطبيقات ذات الواجهة البرمجية فقط و ‎:default للتطبيقات العادية.
  • config.file_watcher: هو الصنف المستخدم للكشف عن تحديثات الملف في نظام الملفات عندما يكون config.reload_classes_only_on_change مضبوطًا إلى القيمة true. ويأتي ريلز مع ActiveSupport::FileUpdateChecker - الافتراضي -، و ActiveSupport::EventedFileUpdateChecker (يعتمد هذا على الجوهرة listen) ويجب أن تتوافق الأصناف المخصصة مع واجهة برمجة التطبيقات ActiveSupport::FileUpdateChecker.
  • config.filter_parameters: يُستخدم لتصفيّة المعاملات التي لا تريد عرضها في السجلات، مثل كلمات المرور وأرقام بطاقات الائتمان. وبشكل افتراضي، يصفي ريلز كلمات المرور عن طريق إضافة Rails.application.config.filter_parameters += [:password]‎ في config/initializers/filter_parameter_logging.rb. وتعمل عملية ترشيح المعاملات من خلال مطابقة التعبير النمطي بشكل جزئي.
  • config.force_ssl: يجبر جميع الطلبات أن تُخدم عبر HTTPS عن طريق استخدام الوسيط ActionDispatch::SSL، ويعيّن config.action_mailer.default_url_options ليكون { protocol: 'https'‎ }. ويمكن ضبط ذلك عن طريق الإعداد config.ssl_options، - يمكنك مراجعة توثيق ActionDispatch::SSL لمزيد من المعلومات.
  • config.log_formatter: يعّرف منسّق مسجّل ريلز، وهذا الخيار الافتراضي لنسخة ActiveSupport::Logger::SimpleFormatter لجميع الأوضاع، وإذا عيّنت قيمة للإعداد config.logger، فيجب عليك أن تمرر قيمة المنسّق (formatter) إلى المسجّل قبل تغليفه في النسخة ActiveSupport::TaggedLogging، ولن يفعل ريلز ذلك بالنيابة عنك.
  • config.log_level: يعرّف مستوى تفصيل مسجّل ريلز. القيمة الافتراضية هي ‎:debug لجميع البيئات، ومستويات السجل المتوافرة هي: ‎:debug، و ‎:info، و ‎:warn، و ‎:error، و ‎:fatal، و ‎:unknown.
  • config.log_tags: يقبل قائمة من: التوابع التي يستجيب لها كائن الطلب request، أو كائن من النوع Proc يقبل كائن الطلب request، أو شيئًا يستجيب إلى to_s. هذا يجعل من وضع علامة على أسطر السجل أسهل مع تنقيح المعلومات مثل النطاق الفرعي و معرّف الطلب - وكلاهما مفيد للغاية في تنقيح تطبيقات متعددة المستخدمين في بيئة الإنتاج.
  • config.logger: هو السجل الذي سيُستخدم لـ Rails.logger وأي تسجيل ريلز ذا صلة مثل ActiveRecord::Base.logger. القيمة الافتراضية له هي نسخة من ActiveSupport::TaggedLogging الذي يغلف نسخة من ActiveSupport::Logger والتي ستُسجَّل مخرجاته في المجلد log/. يمكنك توفير مسجّل مخصّص، وللحصول على التوافق الكامل، يجب عليك اتباع هذه الإرشادات:
    • لإعتماد منسّق، يجب عليك تعيين منسّق بشكل يدوي من قيمة الضبط config.log_formatter إلى المُسجّل.
    • لدعم السجلات الموسومة (tagged logs)، يجب تغليف النسخة log مع ActiveSupport::TaggedLogging.
    • لدعم الوضع الصامت (silencing)، يجب أن يتضمّن المسجّل الوحدات LoggerSilence و ActiveSupport::LoggerThreadSafeLevel. الصنف ActiveSupport::Logger متضمن بالفعل في هذه الوحدات.
class MyLogger < ::Logger
  include ActiveSupport::LoggerThreadSafeLevel
  include LoggerSilence
end
 
mylogger           = MyLogger.new(STDOUT)
mylogger.formatter = config.log_formatter
config.logger      = ActiveSupport::TaggedLogging.new(mylogger)
  • config.middleware: يسمح لك بتهيئة وسيط التطبيق، ولقد غطيّنا هذا بالتفصيل في قسم ضبط الوسيط في الأسفل.
  • config.reload_classes_only_on_change: يتيح لك تفعيل أو تعطيل إعادة تحميل الأصناف فقط عندما تتغيّر الملفات المتعقبة. وهو بشكل افتراضي يتعقّب كل شيء على مسارات إعادة التحميل ويُعيّن إلى القيمة true، وإذا كان config.cache_classes هو true، فسيُتجاهل هذا الخيار.
  • secret_key_base: يُستخدَم لتحديد المفتاح الذي يسمح بالتحقق من جلسات التطبيق ضد المفتاح الآمن المعروف لمنع التلاعب. يحصل التطبيق على مفتاح تم إنشاؤه عشوائيًا في بيئات الاختبار والتطوير، ويجب على البيئات الاخرى تعيين واحد في config/credentials.yml.enc.
  • config.public_file_server.enabled: يضبط ريلز لخدمة ملفات ثابتة من المجلّد العام، وتكون قيمته true بشكل افتراضي، لكن في بيئة الإنتاج تكون false لأنه  يجب على البرنامج الخادم (على سبيل المثال Apache أو NGINX) الذي يُستخدَم لتشغيل التطبيق أن يخدّم الملفات الثابتة بدلًا من ذلك. فإذا كنت تشغّل أو تجرّب التطبيق في وضع الإنتاج باستخدام WEBrick (لا يوصى باستخدام WEBrick في الإنتاج)، عين القيمة true لهذا الخيار، وإلا، فلن تتمكّن من استخدام التخزين المؤقت للصفحة وطلب الملفات الموجودة ضمن الدليل العام.
  • config.session_store: يعيّن الصنف الذي يجب استخدامه لتخزين الجلسة، والقيم المحتملة له هي ‎:cookie_store (القيمة الافتراضية)، و ‎:mem_cache_store و ‎:disabled. وهذا الأخير يخبر ريلز بعدم التعامل مع الجلسات. بشكل افتراضي مخزن ملفات تعريف الارتباط مع اسم التطبيق كمفتاح للجلّسة، ويمكن تحديد مخازن الجلسات المخصّصة:
config.session_store :my_custom_store

يجب تعرف هذا المخزن كـ ActionDispatch::Session::MyCustomStore.

  • config.time_zone: يعيّن المنطقة الزمنيّة الافتراضيّة للتطبيق ويفعّل المنطقة الزمنيّة لـ Active Record.

ضبط الأصول (Assets)

  • config.assets.enabled: هو راية تتحكّم في تمكين خط الأنابيب (pipeline) الخاص بالأصول، وقيمته true بشكل افتراضي.
  • config.assets.css_compressor: يعرّف ضاغط شيفرة CSS المراد استعماله، ويكون sass-rails بشكل افتراضي، والقيمة البديلة الفريدة في الوقت الحالي هي ‎:yui والتي تستخدم الجوهرة yui-compressor.
  • config.assets.js_compressor: يعرّف ضاغط شيفرة JavaScript المراد استخدامه، والقيم المحتملة له هي ‎:closure، و ‎:uglifier، و ‎:yui والتي تتطلّب استخدام الجواهر closure-compiler أو uglifier أو yui-compressor على التوالي.
  • config.assets.gzip: هو راية تمكّن من إنشاء إصدار نسخة مضغوطة بملف gzip من الأصول المترّجمة جنبًا إلى جنب مع الأصول الغير مضغوطة (non-gzipped). قيمته الافتراضية هي true.
  • config.assets.paths: يحتوي على المسارات المستخدمة للبحث عن الأصول، سيؤدي إضافة المسارات إلى خيار الضبط هذا إلى استخدام هذه المسارات في البحث عن الأصول.
  • config.assets.precompile: يسمح لك بتحديد أصول إضافيّة (بخلاف application.css و application.js) والتي يجب تحويلها إلى أصول مفسرة مسبقًا (precompiled) عند تنفيذ الأمر rake assets:precompile.
  • config.assets.unknown_asset_fallback: يتيح لك تعديل سلوك خط أنابيب الأصول عندما لا يكون الأصل في خط الأنابيب، إذا كنت تستخدم sprockets-rails 3.2.0 أو إصدار أحدث منه. القيمة الافتراضية هي false.
  • config.assets.prefix: يعرّف البادئة حيث تكون الأصول موجودة فيه، وهي ‎/assets بشكل افتراضي.
  • config.assets.manifest: تعرّف المسار الكامل ليُستخدم في ملف بيان (precompiler) للأصول. وهو بشكل افتراضي ملف يسمى manifest-<random>.json في مجلّد config.assets.prefix ضمن المجلد العام.
  • config.assets.digest: يتيح لك استخدام بصمات SHA256 في أسماء الأصول، وهو true بشكل افتراضي.
  • config.assets.debug: يعطّل سَلسَلة وضغط الأصول، وهو true بشكل افتراضي في development.rb.
  • config.assets.version: عبارة على سلسلة نصيّة اختياريّة تُستخدم في توليد SHA256 hash، ويمكن تغيير هذا لإجبار جميع الملفات على أن تكون معاد تصريفها (recompiled).
  • config.assets.compile: هو متغير منطقي يمكن استخدامه لتشغيل تجميع الحي لـ Sprockets في الإنتاج.
  • config.assets.logger: يقبل مسجلًا يتطابق مع واجهة Log4r أو مع صنف روبي Logger الافتراضي، وهو بشكل افتراضي يملك نفس ضبطات في config.logger، وعندما تكون قيمة config.assets.logger تساوي false، فسيتوقّف تسجيل الأصول.
  • config.assets.quiet: يعطّل تسجيل طلبات الأصول، وهو true بشكل افتراضي في development.rb.

ضبط المولدات

يسمح لك ريلز بتغيير المولدات التي تُستخدم مع أسلوب config.generators، ويأخذ هذا الأسلوب كتلةً مثل:

config.generators do |g|
  g.orm :active_record
  g.test_framework :test_unit
end

هذه هي المجموعة الكاملة من الأساليب التي يمكن استخدامها في هذه الكتلة كالتالي:

  • assets: تسمح لك بإنشاء الأصول عند توليد السقالة (scaffold)، وهي true بشكل افتراضي.
  • force_plural: يسمح لك بوضع أسماء النموذج بصيغة الجمع، وهي false بشكل افتراضي.
  • helper: يعرّف ما إذا كان سيتم توليد المساعدين، وهو true بشكل افتراضي.
  • integration_tool: تعرّف ما هي أداة التكامل التي يمكن استخدامها لإنشاء اختبارات التكامل، وهي ‎:test_unit بشكل افتراضي.
  • system_tests: يعرّف الأداة التي يجب استخدامها لتوليد اختبارات النظام، وهي ‎:test_unit بشكل افتراضي.
  • javascripts: يشغّل الخطاف (hook) لملفات JavaScript في المولدات. ويُستخدم في ريلز عند عمل المولّد scaffold. قيمته الافتراضية هي: true.
  • javascript_engine: يضبط المحرّك المراد استخدامه (على سبيل المثال coffee) عند توليد الأصول، وهو بشكل افتراضي ‎:js.
  • orm: يعرّف أي تقنية ORM يراد استعمالها. القيمة الافتراضية هي false وسيستخدم بذلك Active Record.
  • resource_controller: يعرّف المولّد الذي سيُستخدم لتوليد المتحكم عند استخدام rails generate resource ويساوي ‎:controller بشكل افتراضي.
  • resource_route: يعرّف ما إذا كان يجب توليد تعريف مسار المورد (resource) أو لا، وهو true بشكل افتراضي.
  • scaffold_controller: يختلف عن resource_controller، إذ يحدّد أي من المولدات سيُستخدم لتوليد متحكم ذي سقالة (scaffolded controller) عند استخدام rails generate scaffold وهو ‎:scaffold_controller بشكل افتراضي.
  • stylesheets: يشغّل الخطاف (hook) لأوراق الأنماط (stylesheets) في المولدات، ويُستخدم في ريلز عند عمل المولّد scaffold، لكن يمكن استخدام هذا الخطاف في مولدات أخرى كذلك، وهو true بشكل افتراضي.
  • stylesheet_engine: يضبط محرّك أوراق الأنماط (مثل sass) الذي يجب استخدامه عند توليد الأصول، وهو ‎:css بشكل افتراضي.
  • scaffold_stylesheet: ينشئ scaffold.css عند توليد مورد ذي سقالة (scaffolded controller)، وهو true بشكل افتراضي.
  • test_framework: يعرّف أي إطار اختبار يجب استخدامه، وهو false وسيستخدم Minitest بشكل افتراضي.
  • template_engine: يعرّف محرك القوالب المراد استخدامه، مثل ERB أو Haml، وهو ‎:erb بشكل افتراضي.

ضبط البرمجيات الوسيطة

يأتي كل تطبيق ريلز مع مجموعة قياسيّة من البرامج الوسيطة (middleware) التي تُستخدم في هذا الترتيب في بيئة التطوير:

  • ActionDispatch::SSL: يفرض أن يُخدم كل طلب باستخدام HTTPS، وهو مفعّل إذا كان config.force_ssl يساوي true، ويمكن ضبط الخيارات الممرّرت إلى هذا عن طريق تعيين config.ssl_options.
  • ActionDispatch::Static: يُستخدم لخدمة الأصول الثابتة، وهو معطّل إذا كان config.public_file_server.enabled يساوي false. عيّن config.public_file_server.index_name إذا أردت تخديم ملف فهرس مجلد ثابت لا يسمى index، فعل سبيل المثال، لتخديم main.html بدلًا من index.html لطلبات المجلد. اضبط config.public_file_server.index_name إلى "main".
  • ActionDispatch::Executor: يسمح بإعادة تحميل شيفرة البرمجية الخاصة بالخيط، وهو معطّل إذا كان config.allow_concurrency يساوي false، مما يؤدي إلى تحميل Rack::Lock، ويلف هذا الأخير التطبيق في كائن المزامنة بحيث يمكن الاتصال به فقط بواسطة خيط واحد في كل مرّة.
  • ActiveSupport::Cache::Strategy::LocalCac يعمل كذاكرة تخزين أساسيّة لدعم ذاكرة التخزين المؤقت، وهذه الذاكرة ليست خيطًا آمنًا، وتعمل كذاكرة تخزين مؤقت للخيط الواحدة.
  • Rack::Runtime: يعيّن الترويسة X-Runtime التي تحتوي على الوقت (بالثواني) المنقضى لتنفيذ الطلب.
  • Rails::Rack::Logger: يخطر السجلات بأن الطلب قد بدأ. وبعد اكتمال الطلب، تُمسَح جميع السجلات.
  • ActionDispatch::ShowExceptions: ينقذ (rescues) أي استثناء يعاد من خلال التطبيق ويعرض صفحات استثناء لطيفة إذا كان الطلب محليًا أو إذا كان config.consider_all_requests_local يساوي true. وإذا كان الضبط config.action_dispatch.show_exceptions يساوي false، فسترمى الاستثناءات بصرف النظر عن ذلك.
  • ActionDispatch::RequestId: يجعل الترويسة X-Request-Id الفريدة متاحة إلى الاستجابة ويفعّل التابع ActionDispatch::Request.uuid.
  • ActionDispatch::RemoteIp يتحقق من هجمات انتحال IP ويحصل على client_ip صالح من ترويسات الطلبات، وهو قابل للضبط باستخدام الخيارين config.action_dispatch.ip_spoofing_check و config.action_dispatch.trusted_proxies.
  • Rack::Sendfile: يعالج الاستجابات التي يُخدَّم نصفها من ملف ويستبدله بالترويسة X-Sendfile الخاصة بالخادم. وهو قابل للضبط باستخدام config.action_dispatch.x_sendfile_header.
  • ActionDispatch::Callbacks يشغّل ردود النداء (callbacks) للتحضير قبل تخديم الطلب.
  • ActionDispatch::Cookies: يعيّن ملفات تعريف الإرتباط للطلب.
  • ActionDispatch::Session::CookieStore: هو المسؤول عن تخزين جلسة العمل في ملفات تعريف الارتباط، ويمكن استخدام وسيط بديل لهذا من خلال تغيير config.action_controller.session_store إلى قيمة بديلة. وبالإضافة إلى ذلك، يمكن تكون الخيارات الممرّرت باستخدام config.action_controller.session_options.
  • ActionDispatch::Flash: يُعدّ مفاتيح الوصول اللحظي (flash keys)، وهو متاح فقط في حالة تعيين config.action_controller.session_store إلى قيمة.
  • Rack::MethodOverride يسمح للأسلوب بإعادة كتابته (overridden) إذا عيّن params[:_method]‎، وتدعم هذه الوسيطة أنواع التوابع HTTP و PATCH وPUT و DELETE.
  • Rack::Head يحوّل طلبات HEAD إلى طلبات GET ويخدّمهم.

إلى جانب هذه البرمجيات الوسيطة المعتادة، يمكنك إضافة البرمجيات الوسيطة الخاصة بك باستخدام التابع config.middleware.use:

config.middleware.use Magical::Unicorns

سيضع هذا وسيطة Magical::Unicorns في نهاية المكدّس، يمكنك استخدام insert_before إذا كنت ترغب في إضافة برامج وسيطة قبل الأخرى.

config.middleware.insert_before Rack::Head, Magical::Unicorns

أو يمكنك إدراج وسيطة في موقع محدد باستخدام الفهارس، فعلى سبيل المثال، إذا كنت تريد إدراج وسيطة Magical::Unicorns في أعلى المكدّس، فيمكنك القيام بذلك كالتالي:

config.middleware.insert_before 0, Magical::Unicorns

هنالك أيضًا insert_after والتي تدرج الوسيطة بعد الأخرى:

config.middleware.insert_after Rack::Head, Magical::Unicorns

يمكن أيضًا تبديل الوسائط واستبدالها:

config.middleware.swap ActionController::Failsafe, Lifo::Failsafe

يمكنك أيضًا إزالتها من المكدس تمامًا:

config.middleware.delete Rack::MethodOverride

ضبط الواجهة البرمجية لتدويل ريلز (i18n)

يتم تفويض جميع خيارات الضبط إلى المكتبة I18n.

  • config.i18n.available_locales: تعرض القوائم البيضاء للمحليات (locale) المتوفّرة للتطبيق. وهي بشكل افتراضي لجميع مفاتيح المحليّة الموجودة في الملفات المحليّة، وهي في لاعادة ‎:en في التطبيق الجديد.
  • config.i18n.default_locale: تعيّن المحلي الافتراضي للتطبيق المستخدم في I18n، وهي بشكل افتراضي تساوي ‎:en.
  • config.i18n.enforce_available_locales: يضمن أن جميع المحليات التي مرّت عبر I18n قد أُعلن عنها في قائمة available_locales، وسيرمي الاستثناء I18n::InvalidLocale عند إعداد محلي غير متوفّر. وهي بشكل افتراضي true، ومن المستحسن عدم تعطيل هذا الخيار ما لم يكن مطلوبًا بشدّة، حيث يعمل هذا كمقياس أمان ضد تعيين أي محلي غير صالح من المدخلات المستخدم.
  • config.i18n.load_path: يعيّن المسار الذي يستخدمه ريلز للبحث عن الملفات المحليّة. وهي بشكل افتراضي تساوي config/locales/*.{yml,rb}‎.
  • config.i18n.fallbacks: يعيّن السلوك الاحتياطي للترجمات المفقودة. إليك ثلاثة أمثلة استخدام لهذا الخيار:
    • يمكنك تعيين الخيار على true لاستخدام المحلي الافتراضي:
config.i18n.fallbacks = true
    • أو يمكنك تعيين مجموعة من المحليات، كالتالي:
config.i18n.fallbacks = [:tr, :en]
    • أو يمكنك تعيين محليات اللجوء بشكل فردي، فعلى سبيل المثال، إذا أردت استخدام ‎:tr لـ ‎:az و ‎:de، و ‎:en لـ ‎:da كلجوء، فيمكنك فعل ذلك على طريق:
config.i18n.fallbacks = { az: :tr, da: [:de, :en] }
# أو
config.i18n.fallbacks.map = { az: :tr, da: [:de, :en] }

ضبط Active Record

يتضمّن config.active_record مجموعة متنوّعة من خيارات الضبط:

  • config.active_record.logger: يقبل مسجلًا يتطابق مع الواجهة Log4r أو الصنف Logger الافتراضي الذي يخص روبي، والذي يمرر بعد ذلك إلى أي اتصالات قاعدة بيانات جديدة تم إنشاؤها. يمكنك استرداد هذا السجل من خلال استدعاء logger إما في صنف نموذج Active Record أو في نسخة نموذج Active Record. ويمكنك تعيينه إلى القيمة nil لتعطيل التسجيل.
  • config.active_record.primary_key_prefix_type: يتيح لك ضبط تسمية أعمدة المفاتيح الأساسيّة، افتراضيًا، يفترض ريلز أن أعمدة المفاتيح الأساسيّة تسمى id (وليس هنالك حاجة لتعيين هذا الخيار)، ويوجد خيارات آخران:
    • ‎:table_name: سيجعل المفتاح الرئيسي للصنف Customer هو customerid.
    • :table_name_with_underscore: سيجعل المفتاح الأساسي للصنف Customer هو customer_id.
  • config.active_record.table_name_prefix: يتيح لك تعيين سلسلة عامة (global) لارفاقها بأسماء الجداول. إذا قمت تعيين هذا الضبط إلى northwest_‎، فإن الصنف Customer سيبحث عن northwest_customers كجدول له. وبشكل افتراضي يساوي سلسلة نصيّة فارغة.
  • config.active_record.table_name_suffix: يتيح لك تعيين سلسلة عامة (global) لإلحاقها بأسماء الجداول. إذا قمت تعيين هذا الضبط إلى _northwest فإن الصنف Customer سيبحث عن customers_northwest كجدول له. وبشكل افتراضي يساوي سلسلة نصيّة فارغة.
  • config.active_record.schema_migrations_table_name: يتيح لك تعيين سلسلة نصيّة لاستخدامها كاسم جدول تهجيرات المخطط (schema migrations table).
  • config.active_record.internal_metadata_table_name: يتيح لك تعيين سلسلة نصيّة لاستخدامها كاسم جدول البيانات الأوليّة الداخلية.
  • config.active_record.protected_environments: يتيح لك تعيين مصفوفة من أسماء البيئات التي ينبعي فيها حظر الإجراءات المدمرة (destructive actions).
  • config.active_record.pluralize_table_names: يحدد ما إذا كان ريلز سيبحث عن أسماء الجداول المفردة أو الجمع في قاعدة البيانات. إذا تم تعيينه على true (الافتراضي)، فسيستخدم الصنف Customer الجدول customers وإذا كانت false، فسيستخدم الصنف Customer الجدول customer.
  • config.active_record.default_timezone: يحدد ما إذا كان سيُستخدم Time.local (إذا عيّن إلى القيمة :local) أو Time.utc (إذا عيّن إلى القيمة ‎:utc) عند سحب التواريخ والأوقات من قاعدة البيانات. القيمة الافتراضية لهذا الخيار هي ‎:utc.
  • config.active_record.schema_format: يتحكم في التنسيق من أجل تفريغ مخطط قاعدة البيانات إلى ملف. والخيارات هي ‎:ruby (الافتراضي) لإصدار مستقل لقاعدة البيانات يعتمد على عمليات التهجير، أو ‎:sql لمجموعة من تعليمات SQL (التي يمكن أن تعتمد على قاعدة البيانات).
  • config.active_record.error_on_ignored_order: يحدد ما إذا كان ينبغي رفع الخطأ إذا تم تجاهل ترتيب الاستعلام أثناء استعلام مجموعة واحدة. الخيارات هي true (رفع خطأ) أو false (تحذير)، وبشكل افتراضي تساوي false.
  • config.active_record.timestamped_migrations: تتحكم ما إذا كان يتم ترقيم عمليات التهجير باستخدام أرقام مسلسلة أو مع طوابع زمنيّة (timestamps). بشكل افتراضي تساوي true لاستخدام الطوابع الزمنية، والتي يفضل استخدامها إذا كان هنالك العديد من المطورين الذي يعملون على نفس التطبيق.
  • config.active_record.lock_optimistically: يتحكم ما إذا كان Active Record سيستخدم القفل المستبشر (optimistic locking) أم لا. وهو true بشكل افتراضي.
  • config.active_record.cache_timestamp_format: يتحكم في تنسيق قيمة البصمة الزمنية (timestamp) في مفتاح ذاكرة التخزين المؤقت. وبشكل افتراضي يساوي :nsec.
  • config.active_record.record_timestamps: هو قيمة منطقيّة تتحكّم في ما إذا كان هنالك طابع زمني على عمليات الإنشاء والتحديث في نموذج. وهو بشكل افتراضي true.
  • config.active_record.partial_writes: هو قيمة منطقيّة وتتحكّم ما إذا كانت تُستخدم عمليات الكتابة الجزئية أم لا (بمعنى ما إذا كانت التحديثات تعيّن الخاصيات المتسخة [dirty]). لاحظ أنه عند استخدام عمليات الكتابة الجزئية، يجب عليك استخدام القفل المستبشر config.active_record.lock_optimistically نظرًا لأن التحديثات المتزامنة قد تكتب الخاصيات استنادًا إلى حالة قراءة تالفة. بشكل افتراضي يساوي true.
  • config.active_record.maintain_test_schema: هي قيمة منطقيّة تتحكم في ما إذا كان Active Record يجب أن يحاول تحديث مخطط قاعدة بيانات الاختبار (test database schema) مع db/schema.rb (أو db/structure.sql) عند تشغيل الاختبارات. بشكل افتراضي يساوي true.
  • config.active_record.dump_schema_after_migration: هو راية تتحكّم في ما إذا كان يجب أن يحدث تفريغ المخطّط (db/schema.rb أو db/structure.sql) عند تشغيل عمليات التهجير. ويعيّن هذه الراية إلى القيمة false في config/environments/production.rb المنشئ بواسطة ريلز. والقيمة الافتراضيّة هي true إذا لم يعيّن هذا الضبط.
  • config.active_record.dump_schemas: يتحكّم في ما هي مخططات قاعدة البيانات التي ستفرّغ عند استدعاء db:structure:dump. الخيارات هي: :schema_search_path (وهو الافتراضي) والذي يفرّغ أي مخططات مدرجة في schema_search_path، :all الذي يفرّغ دائمًا جميع المخططات بغض النظر عن schema_search_path أو سلسلة نصيّة من المخططات المفصولة بفواصل.
  • config.active_record.belongs_to_required_by_default: هي قيمة منطقيّة تتحكّم في ما إذا كان السجل يفشل في التحقق (validation) إذا لم يكن هنالك ارتباط من النوع belongs_to (ارتباط انتماء).
  • config.active_record.warn_on_records_fetched_greater_than: يتيح تعيين حدًّا للتحذير من أجل حجم نتيجة الاستعلام. إذا تجاوز عدد السجلات التي تم إرجاعها بواسطة استعلام الحد المسموح، فسيُسجّل تحذير. ويمكن استخدام هذا الضبط لتحديد الاستعلامات التي تتسبب في حدوث تضخم في الذاكرة.
  • config.active_record.index_nested_attribute_errors: يسمح للأخطاء في الارتباطات has_many المتداخلة أن تُعرض مع فهرس بالإضافة إلى الخطأ. بشكل افتراضي يساوي false.
  • config.active_record.use_schema_cache_dump: يتيح للمستخدمين الحصول على معلومات التخزين المؤقت للمخطط من db/schema_cache.yml (المنشئ بواسطة bin/rails db:schema:cache:dump) بدلًا من الاضطرار إلى إرسال استعلام إلى قاعدة البيانات للحصول على هذه المعلومات. بشكل افتراضي يساوي true.

يضيف محوّل MySQL خيار ضبط إضافي آخر:

  • ActiveRecord::ConnectionAdapters::Mysql2Adapter.emulate_booleans: يتحكّم ما إذا Active Record سيَعُدُّ جميع الأعمدة tinyint(1)‎ كقيم منطقيّة. بشكل افتراضي يساوي true.

يضيف محوّل SQLite3Adapter خيار ضبط إضافي آخر:

  • ActiveRecord::ConnectionAdapters::SQLite3Adapter.represent_boolean_as_integer: يشير ما إذا ما إذا كانت القيم المنطقية المخزنة في قواعد بيانات sqlite3 ستُمثَّل بالشكل 1 و 0 أو 't' و 'f'. ترك الضبط ActiveRecord::ConnectionAdapters::SQLite3Adapter.represent_boolean_as_integer معيَّنًا للقيمة false قد أُهمِل. لقد استخدمت قواعد بيانات SQLite التمثيل 't' و 'f' لسلسلة القيم المنطقيّة ويجب أن تحتوي على البيانات القديمة بعد تحويلها إلى 1 و0 (التسلسل المنطقي الأصلي) وقبل تعيين هذه الراية إلى true. ويمكن التحويل عن طريق إعداد مهمة Rake التي تشغّل:
ExampleModel.where("boolean_column = 't'").update_all(boolean_column: 1)
ExampleModel.where("boolean_column = 'f'").update_all(boolean_column: 0)

لجميع النماذج وجميع الأعمدة المنطقيّة، يجب بعدها تعيين هذه الراية إلى القيمة true بإضافة ما يلي إلى الملف application.rb:

```ruby
Rails.application.config.active_record.sqlite3.represent_boolean_as_integer = true
```

يضيف مفرّغ المخطط (schema dumper) خيار ضبط إضافي آخر:

  • ActiveRecord::SchemaDumper.ignore_tables: يقبل مصفوفة من الجداول التي لا يجب تضمينها في أي ملف مخطط تم إنشاؤه.

ضبط إجراء التحكم (Action Controller)

يتضمّن config.action_controller عددًا من إعدادات الضبط هي:

  • config.action_controller.asset_host: يعيّن المضيف للأصول، وهو مفيد عند استخدام CDN لاستضافة الأصول بدلًا من خادم التطبيق نفسه.
  • config.action_controller.perform_caching: يضبط ما إذا كان يجب أن ينفذ التطبيق ميزات التخزين المؤقت التي يوفرها مكون متحكم الإجراء أو لا. وقيمته false في وضع التطوير و true في وضع الإنتاج.
  • config.action_controller.default_static_extension: يضبط اللاحقة المستخدمة في صفحات التخزين المؤقت. وهي بشكل افتراضي ‎.html.
  • config.action_controller.include_all_helpers: يضبط ما إذا كان جميع مساعدي العروض متوفرين في كل مكان أو تحديد نطاقها إلى المتحكم المقابل. في حالة تعيين هذا الضبط إلى القيمة false، فستكون توابع UsersHelper متوفّرة فقط لعروض المصيَّرة كجزء من المتحكم UsersController. وإذا كان true، فإن توابع UsersHelper ستكون متوفّرة في كل مكان، وإن سلوك الضبط الافتراضي (عندما لا يعيّن هذا الخيار بشكل صريح كـ true أو false) هو أن كافة مساعدي العروض متوفّرة لكل متحكّم.
  • config.action_controller.logger: يقبل مسجلًا مطابقًا للواجهة Log4r أو صنف روبي Logger الافتراضي، والذي يُستخدم بعد ذلك لتسجيل المعلومات من متحكم الإجراء. اضبطه إلى nil لتعطيل التسجيل.
  • config.action_controller.request_forgery_protection_token: يعيّن اسم معامل الرمز (token parameter name) من أجل RequestForgery. وإن استدعاء protect_from_forgery يعيّن هذا الضبط إلى :authenticity_token بشكل افتراضي.
  • config.action_controller.allow_forgery_protection: يفعّل أو يعطّل حماية CSRF. وهو بشكل افتراضي false في وضع الاختبار و true في جميع الأوضاع الأخرى.
  • config.action_controller.forgery_protection_origin_check: يضبط ما إذا كان يجب التحقق من الترويسة Origin في طلبيات HTTP ضد أصل الموقع (site's origin) كدفاع إضافي من هجمات CSRF.
  • config.action_controller.per_form_csrf_tokens: يضبط ما إذا كانت رموز CSRF صالحة فقط للتابع/الإجراء الذي تم إنشاؤه له.
  • config.action_controller.default_protect_from_forgery: يحدد إضافة حماية التزوير على ActionController:Base، وهو false بشكل افتراضي، ولكنه مفعّل عند تحميل الإعدادات الافتراضيّة للإصدار 5.2 من ريلز.
  • config.action_controller.relative_url_root: يمكن استخدامه لإخبار ريلز أنك تنشر تطبيقك إلى مجلد فرعي. بشكل افتراضي يساوي ENV['RAILS_RELATIVE_URL_ROOT']‎.
  • config.action_controller.permit_all_parameters: يعيّن السماح لجميع المعاملات بالتعيين الشامل بشكل افتراضي. القيمة الافتراضية هي false.
  • config.action_controller.action_on_unpermitted_parameters: يفعّل التسجيل أو رفع استثناء إذا تم العثور على معاملات غير مسموح بها بشكل صريح. استعمل ‎:log أو ‎:raise لكل حالة على التوالي. القيمة الافتراضيّة هي ‎:log في أوضاع التطوير والاختبار، و false في جميع الأوضاع الأخرى.
  • config.action_controller.always_permitted_parameters: تعيّن قائمة بالمعاملات المسموح بها بشكل افتراضي. القيم الافتراضيّة هي ['controller', 'action']
  • config.action_controller.enable_fragment_cache_logging: يحدد ما إذا كان سيتم تسجيل أجزاء القراءة والكتابة لذاكرة التخزين المؤقت بشكل مفصل كالتالي:
Read fragment views/v1/2914079/v1/2914079/recordings/70182313-20160225015037000000/d0bdf2974e1ef6d31685c3b392ad0b74 (0.6ms)
Rendered messages/_message.html.erb in 1.2 ms [cache hit]
Write fragment views/v1/2914079/v1/2914079/recordings/70182313-20160225015037000000/3b4e249ac9d168c617e32e84b99218b5 (1.1ms)
Rendered recordings/threads/_thread.html.erb in 1.5 ms [cache miss]

افتراضيًا، يتم تعيينه إلى القيمة false مما ينتج عنه المخرجات التالية:

```
Rendered messages/_message.html.erb in 1.2 ms [cache hit]
Rendered recordings/threads/_thread.html.erb in 1.5 ms [cache miss]
```

ضبط Action Dispatch (إجراء الإرسال)

  • config.action_dispatch.session_store: يعيّن اسم المخزن المراد تخزين بيانات الجلسة فيه. وهو بشكل افتراضي :cookie_store وتتضمن الخيارات الصالحة الأخرى :active_record_store أو :mem_cache_store أو اسم الصنف المخصص الخاص بك.
  • config.action_dispatch.default_headers: هو جدول Hash مع ترويسات HTTP التي تم تعيينها بشكل افتراضي في كل استجابة. بشكل افتراضي، معرّفة على أنها:
config.action_dispatch.default_headers = {
  'X-Frame-Options' => 'SAMEORIGIN',
  'X-XSS-Protection' => '1; mode=block',
  'X-Content-Type-Options' => 'nosniff',
  'X-Download-Options' => 'noopen',
  'X-Permitted-Cross-Domain-Policies' => 'none',
  'Referrer-Policy' => 'strict-origin-when-cross-origin'
}
  • config.action_dispatch.default_charset: يحدد مجموعة المحارف الافتراضيّة لكافة عمليات التصيير. يساوي nil بشكل افتراضي.
  • config.action_dispatch.tld_length: يعيّن طول TLD (نطاق المستوى الأعلى [top-level domain]) للتطبيق، وهو 1 بشكل افتراضي.
  • config.action_dispatch.ignore_accept_header: يُستخدم لتحديد ما إذا كان ستتجاهل قبول ترويسات من الطلب، وهو بشكل افتراضي false.
  • config.action_dispatch.x_sendfile_header: يحدد الترويسة X-Sendfile المخصصة لخادم معين. وهو مفيد لتسريع إرسال الملفات من الخادم، على سبيل المثال، يمكن تعيينه إلى القيمة 'X-Sendfile' لخادم أباتشي.
  • config.action_dispatch.http_auth_salt: يحدد القيمة الزائدة (salt value) لمصادقة طلبيات HTTP. وهي بشكل افتراضي 'http authentication'.
  • config.action_dispatch.signed_cookie_salt: يعيّن القيمة الزائدة (salt value) لملفات تعريف الارتباط الموقعة، وهو يساوي بشكل افتراضي 'signed cookie'.
  • config.action_dispatch.encrypted_cookie_salt: يعيّن القيمة الزائدة (salt value) لملفات تعريف الارتباط المشفّرة. وهو يساوي بشكل افتراضي 'encrypted cookie'.
  • config.action_dispatch.encrypted_signed_cookie_salt: يعيّن القيمة الزائدة (salt value) لملفات تعريف الارتباط الموقعة والمشفّرة. وهو يساوي بشكل افتراضي 'signed encrypted cookie'.
  • config.action_dispatch.authenticated_encrypted_cookie_salt: يعيّن القيمة الزائدة لملفات تعريف الارتباط المصادق عليها والمشفّرة. وهو يساوي بشكل افتراضي 'authenticated encrypted cookie'.
  • config.action_dispatch.encrypted_cookie_cipher: يعيّن التشفير المراد استخدامه في ملفات تعريف الارتباط المشفّرة. وهو بشكل افتراضي "aes-256-gcm".
  • config.action_dispatch.signed_cookie_digest: يعيّن خوارزمية التشفير للقيم المختصرة المشفرة (digest) المراد استخدامها في ملفات تعريف الارتباط الموقعة. وهو "SHA1" بشكل افتراضي.
  • config.action_dispatch.cookies_rotations: يسمح بتدوير الأسرار، والتشفيرات، والقيم المشفرة المختصرة لملفات تعريف الارتباط المشفّرة والموقعة.
  • config.action_dispatch.use_authenticated_cookie_encryption: يتحكّم ما إذا كانت ملفات تعريف الارتباط المشفّرة والموقعة تستخدم التشفير AES-256-GCM أو التشفير AES-256-CBC القديم. وهو true بشكل افتراضي.
  • config.action_dispatch.perform_deep_munge: يضبط ما إذا كان يجب تنفيذ التابع deep_munge على المعاملات. انظر دليل الأمن لمزيد من المعلومات. القيمة الافتراضية لهذا الضبط هي true.
  • config.action_dispatch.rescue_responses: يضبط الاستثناءات التي عيّنت لحالة HTTP، وهي تقبل جدول hash ويمكنك تحديد أزواج من استثناء/حالة. وهو بشكل افتراضي معرّف على أنه:
config.action_dispatch.rescue_responses = {
  'ActionController::RoutingError'               => :not_found,
  'AbstractController::ActionNotFound'           => :not_found,
  'ActionController::MethodNotAllowed'           => :method_not_allowed,
  'ActionController::UnknownHttpMethod'          => :method_not_allowed,
  'ActionController::NotImplemented'             => :not_implemented,
  'ActionController::UnknownFormat'              => :not_acceptable,
  'ActionController::InvalidAuthenticityToken'   => :unprocessable_entity,
  'ActionController::InvalidCrossOriginRequest'  => :unprocessable_entity,
  'ActionDispatch::Http::Parameters::ParseError' => :bad_request,
  'ActionController::BadRequest'                 => :bad_request,
  'ActionController::ParameterMissing'           => :bad_request,
  'Rack::QueryParser::ParameterTypeError'        => :bad_request,
  'Rack::QueryParser::InvalidParameterError'     => :bad_request,
  'ActiveRecord::RecordNotFound'                 => :not_found,
  'ActiveRecord::StaleObjectError'               => :conflict,
  'ActiveRecord::RecordInvalid'                  => :unprocessable_entity,
  'ActiveRecord::RecordNotSaved'                 => :unprocessable_entity
}

سيُعيّن أي استثناء لم يُضبَط إلى الخطأ 500 الداخلي في الخادم (Internal Server Error).

  • ActionDispatch::Callbacks.before: تأخذ كتلة من التعليمات البرمجيّة لتشغيلها قبل الطلب.
  • ActionDispatch::Callbacks.after: تأخذ كتلة من التعليمات البرمجيّة لتشغيلها بعد الطلب.

ضبط Action View

يتضمن config.action_view مجموعة صغيرة من إعدادات الضبط:

  • config.action_view.cache_template_loading: يتحكّم في ما إذا كان يجب إعادة تحميل القوالب في كل طلب أو لا. القيمة الافتراضية لهذا الضبط هي نفس القيمة التي ضُبَط في config.cache_classes.
  • config.action_view.field_error_proc: يوفّر مولّد HTML لعرض الأخطاء التي تأتي من Active Model، وهو بشكل افتراضي:
Proc.new do |html_tag, instance|
  %Q(<div class="field_with_errors">#{html_tag}</div>).html_safe
end
  • config.action_view.default_form_builder: يخبر ريلز أي باني نموذج يراد استخدامه بشكل افتراضي. القيمة الافتراضية له هي ActionView::Helpers::FormBuilder. إذا أردت تحميل صنف باني النموذج بعد التهيئة (لكي يعاد تحميله على كل طلب قيّد التطوير)، يمكنك تمريره كسلسة نصيّة.
  • config.action_view.logger: يقبل مسجل يتطابق مع الواجهة Log4r أو صنف روبي Logger الافتراضي، والذي يُستخدَم بعد ذلك لتسجيل المعلومات من Action View. اضبطه إلى القيمة nil لتعطيل التسجيل.
  • config.action_view.erb_trim_mode: يسمح باستخدام الوضع trim من قبل ERB. وهو بشكل افتراضي "-"، والذي يعمل على تشذيب مسافات التذييل والسطر الجديد عند استخدام <‎%= -%‎> أو <%= =%>. راجع توثيق Erubis لمزيد من المعلومات.
  • config.action_view.embed_authenticity_token_in_remote_forms: يسمح لك بتعيين السلوك الافتراضي لـ authenticity_token في النماذج مع remote:true. وهو false بشكل افتراضي، مما يعني أن النماذج البعيدة لن تتضمن authenticity_token وهو أمر مفيد عندما تخزّن أجزاء النموذج بشكل مؤقت في الذاكرة. تحصل النماذج البعيدة على المصادقة من الوسم <meta>، لذلك لا يكون الدمج ضروريًا إلا إذا رغبت بدعم المتصفحات بدون JavaScript. وفي مثل هذه الحالة، يمكنك تمرير authenticity_token: true كخيار النموذج أو تعيين خيار الضبط هذا إلى القيمة true.
  • config.action_view.prefix_partial_path_with_controller_namespace: يحدَّد ما إذا كان يتم البحث عن أجزاء من مجلد فرعي أم لا في القوالب المصيَّرة من متحكمات مجالات الأسماء. فعلى سبيل المثال، افترض وجود متحكم يسمى Admin::ArticlesController الذي يصيِّر هذا القالب:
<%= render @article %>

الإعداد الافتراضي هو true، والذي يستخدم الجزئية الموجودة في ‎/admin/articles/_article.erb، وعند تعيين القيمة إلى false فسيُصيَّر ‎/articles/_article.erb والذي هو نفس السلوك التصيير من متحكم ليس من مجال الاسم مثل ArticlesController.

  • config.action_view.raise_on_missing_translations: يحدد ما إذا كان يجب رفع خطأ للتحويلات المفقودة.
  • config.action_view.automatically_disable_submit_tag: يحدد ما إذا كان يجب تعطيل submit_tag (وسم الإرسال) عند النقر. وهو بشكل افتراضي true.
  • config.action_view.debug_missing_translation: يحدد ما إذا كان سيغلف مفتاح التحويلات المفقودة في الوسم <span> أو لا. وهو true بشكل افتراضي.
  • config.action_view.form_with_generates_remote_forms: يحدد ما إذا كان form_with يولّد نماذج عن بعد أم لا، وهو true بشكل افتراضي.
  • config.action_view.form_with_generates_ids: يحدد ما إذا كان form_with يولد معرفات على المدخلات، وهو true بشكل افتراضي.

ضبط Action Mailer

هنالك عدد من الإعدادات المتاحة في الضبط config.action_mailer:

  • config.action_mailer.logger: يقبل مسجلًا مطابقًا للواجهة Log4r أو صنف روبي Logger الافتراضي، والذي يُستخدم بعد ذلك لتسجيل المعلومات من Action Mailer. اضبطه إلى القيمة nil لتعطيل التسجيل.
  • config.action_mailer.smtp_settings: يتيح ضبط تابع التسليم :smtp ضبطًا تفصيليًّا. وهو يقبل جدول hash من الخيارات، والتي يمكن أن تشمل أي من الخيارات التالية:
    • ‎:address - يسمح لك باستخدام خادم بريد بعيد. كل ما عليك فعله هو تغيير إعداد "localhost" الافتراضي.
    • ‎:port - في حالة عدم عمل خادم البريد الخاص على المنفذ 25، يمكنك تغييره.
    • :domain - إذا أردت تحديد نطاق HELO، فيمكنك القيام بذلك هنا.
    • ‎:user_name - إذا كان خادم البريد الخاص بك يتطلّب الاستيثاق، فعيّن اسم المستخدم في هذا الخيار.
    • ‎:password - إذا كان خادم البريد الخاص بك يتطلّب المصادقة، فعيّن كلمة المرور في هذا الإعداد.
    • ‎:authentication - إذا كان خادم البريد الخاص بك يتطلّب الاستيثاق، فعليك تحديد نوع الاستيثاق هنا. وهو رمز ويأخذ إحدى القيم التالية: plain:، أو login:، أو cram_md5:.
    • ‎‎:enable_starttls_auto - يكتشف ما إذا تم تمكين STARTTLS في خادم SMTP الخاص بك ويبدأ في استخدامه. وهو true بشكل افتراضي.
    • ‎:openssl_verify_mode - عند استخدام TLS، يمكنك ضبط كيفية قيام OpenSSL بالتحقق من الشهادة، وهذا مفيد إذا أردت التحقق من صحة شهادة self-signed أو/و wildcard. يمكن أن يكون هذا أحد ثوابت التحقق من OpenSSL وهي :none أو :peer أو الثابت OpenSSL::SSL::VERIFY_NONE أو OpenSSL::SSL::VERIFY_PEER على التوالي.
    • ‎:ssl/:tls - لتمكين اتصال SMTP ليستخدم SMTP/TLS (أي SMTPS: SMTP عبر اتصال TLS مباشر).
  • config.action_mailer.sendmail_settings: يسمح بضبط مفصّل لتابع التسليم sendmail، وهو تقبل جدول Hash من الخيارات، والذي يمكن أن يحوي أي من الخيارات التالية:
    • ‎:location - موقع sendmail التنفيذي، وهو بشكل افتراضي ‎/usr/sbin/sendmail.
    • :arguments - معاملات سطر الأوامر، بشكل افتراضي يساوي ‎-i.
  • config.action_mailer.raise_delivery_errors: يحدد ما إذا كان سيُرفع خطأ في تعذّر إكمال تسليم البريد الإلكتروني، وهو true بشكل افتراضي.
  • config.action_mailer.delivery_method: يحدد تابع التسليم وهو :smtp بشكل افتراضي. راجع قسم الضبط في دليل Action Mailer للمزيد من المعلومات.
  • config.action_mailer.perform_deliveries: يحدد إذا كان البريد سيُسلّم بالفعل وهو true بشكل افتراضي. ومن المستحسن تعيينه إلى القيمة false للاختبار.
  • config.action_mailer.default_options: يضبط الإعدادات الافتراضيّة لـ Action Mailer بشكل افتراضي، ويُستخدم لتعيين خيارات مثل from أو reply_to لكل Action Mailer، وهو افتراضي إلى:
mime_version:  "1.0",
charset:       "UTF-8",
content_type: "text/plain",
parts_order:  ["text/plain", "text/enriched", "text/html"]

أسند إليه جدول hash لتعيين خيارات إضافيّة:

config.action_mailer.default_options = {
  from: "noreply@example.com"
}
  • config.action_mailer.observers: مراقبي السجل الذين سيتم إبلاغهم عند تسليم البريد.
config.action_mailer.observers = ["MailObserver"]
  • config.action_mailer.interceptors: معترضات السجل والتي سيتم استدعاؤها قبل ارسال البريد.
config.action_mailer.interceptors = ["MailInterceptor"]
  • config.action_mailer.preview_path: يحدد موقع معاينات البريد الالكتروني.
config.action_mailer.preview_path = "#{Rails.root}/lib/mailer_previews"
  • config.action_mailer.show_previews: يفعّل أو يعطّل معاينات البريد، وهو true بشكل افتراضي في وضع التطوير.
config.action_mailer.show_previews = false
  • config.action_mailer.deliver_later_queue_name: يحدد اسم الطابور (queue) للمرسلين، وهو بشكل افتراضي mailers.
  • config.action_mailer.perform_caching: يحدد ما إذا كان يجب أن تقوم قوالب الإرسال بإجراء تخزين مؤقت للأجزاء أو لا. وهو false بشكل افتراضي في جميع البيئات.

ضبط Active Support

هنالك عدة خيارات ضبط متاحة في Active Support:

  • config.active_support.bare: يفعّل أو يعطّل تحميل active_support/all عند تشغيل ريلز. وهو nil بشكل افتراضي، مما يعني أن active_support/all ستكون مُحمَّلَة.
  • config.active_support.test_order: يعيّن الترتيب الذي من خلاله تنفّذ حالات الاختبار. القيم المحتملة هي :random و ‎:sorted. قيمته الافتراضية هي :random.
  • config.active_support.escape_html_entities_in_json: يفعّل أو يعطّل تهريب كيانات HTML في سَلسَلة JSON. وهو true بشكل افتراضي.
  • config.active_support.use_standard_json_time_format: يفعّل أو يعطّل سلسلة التواريخ إلى تنسيق ISO 8601. وهو true افتراضيًا.
  • config.active_support.time_precision: يعيّن دقة قيمة الوقت التي تم ترميزها. وهو 3 افتراضيًا.
  • config.active_support.use_sha1_digests: يحدد ما إذا كنت ستستخدم الخوارزمية SHA-1 بدلًا من MD5 لتوليد القيم المختصرة المشفرة غير الحساسة، مثل الترويسة ETag. القيمة الافتراضية هي false.
  • config.active_support.use_authenticated_message_encryption: يحدد ما إذا كان سيُستخدم تشفير الاستيثاق AES-256-GCM كتشفير افتراضي لتشفير الرسائل بدلًا من AES-256-CBC. هو false افتراضيًا لكنه يصبح true عند تحميل الإعدادات الافتراضيّة من أجل الإصدار 5.2 من ريلز.
  • ActiveSupport::Logger.silencer: يعيّن false لتعطيل القدرة على إسكات التسجيل في كتلة، وهو true افتراضيًا.
  • ActiveSupport::Cache::Store.logger: يحدد المسجل لاستخدامه داخل عمليات التخزين في ذاكرة التخزين المؤقتة.
  • ActiveSupport::Deprecation.behavior: أداة ضبط بديلة لـ config.active_support.deprecation الذي يضبط سلوك تحذيرات الإهمال في ريلز.
  • ActiveSupport::Deprecation.silence: يأخذ كتلة يتم فيها إسكات كافة تحذيرات الإهمال.
  • ActiveSupport::Deprecation.silenced: يعيّن ما إذا كان ستعرض تحذيرات الإهمال أو لا.

ضبط Active Job

يوفّر config.active_job خيارات الضبط التاليّة:

  • config.active_job.queue_adapter: يعيّن المحوّل لواجهة الطابور الخلفية (queueing backend). إن المحوّل الافتراضي هو :async. للحصول على قائمة محدّثة من المحولات المضمنة، راجع وثائق واجهة برمجة التطبيقات لـ ActiveJob::QueueAdapters.
# Gemfile تأكد من تضمين جوهرة المحول في الملف
# واتبع خطوات تثبيت المحول المحددة وتعليمات
# النشر
config.active_job.queue_adapter = :sidekiq
  • config.active_job.default_queue_name: يمكن استخدامه لتغيير اسم قائمة الطابور الافتراضيّة والذي هو "default" افتراضيًا.
config.active_job.default_queue_name = :medium_priority
  • config.active_job.queue_name_prefix: يسمح لك بتعيين بادئة اسم اختياريّة غير فارغة للطابور من أجل جميع الوظائف. القيمة الافتراضية فارغة وغير مستعملة.

يعمل الضبط التالي على ترتيب وظيفة محددة في طابور production_high_priority عند تشغيله في الإنتاج:

config.active_job.queue_name_prefix = Rails.env
class GuestsCleanupJob < ActiveJob::Base
  queue_as :high_priority
  #....
end
  • config.active_job.queue_name_delimiter: يملك القيمة الافتراضيّة '_'. إذا عُيّنَت قيمة للخيار queue_name_prefix، فإن queue_name_delimiter سيرتبط باسم الطابور الذي يملك بادئة والذي لا يملكها.

سيضع الضبط التالي الوظيفة المعروضة في الطابور video_server.low_priority:

# لكي تُستخدَم delimiter يجب ضبط السابقة من أجل المحدد
config.active_job.queue_name_prefix = 'video_server'
config.active_job.queue_name_delimiter = '.'
class EncoderJob < ActiveJob::Base
  queue_as :low_priority
  #....
end
  • config.active_job.logger: يقبل مسجلًا مطابقًا للواجهة Log4r أو صنف روبي Logger الافتراضي، والذي سيُستخدم بعد ذلك لتسجيل المعلومات من Active Job. يمكنك استرداد هذا السجل عن طريق استدعاء logger على أي صنف Active Job أو نسخة من Active Job. اضبطه إلى القيمة nil لتعطيل التسجيل.

ضبط Action Cable

  • config.action_cable.url: يقبل سلسلة نصيّة للعنوان URL الخاص بالمكان الذي تستضيف فيه خادم Action Cable. يمكنك استخدام هذا الخيار إذا كنت تشغّل خوادم Action Cable المنفصلة عن التطبيق الرئيسي.
  • config.action_cable.mount_path: يقبل سلسلة نصيّة لمكان وصل Action Cable، كجزء من عملية الخادم الرئيسيّة. وهو يساوي بشكل افتراضي ‎/cable ويمكنك تعيينه إلى القيمة nil حتى لا يوصل Action Cable كجزء من خادم ريلز العادي.

ضبط Active Storage

يوفّر config.active_storage خيارات الضبط التالية:

  • config.active_storage.analyzers: يقبل مصفوفة من الأصناف التي تشير إلى المحللات (analyzers) المتاحة من أجل كائنات البيانات الثنائية لـ Active Storage (أي Active Storage blobs). يساوي افتراضيًّا إلى [ActiveStorage::Analyzer::ImageAnalyzer, ActiveStorage::Analyzer::VideoAnalyzer]. هذا الأول يمكنه استخراج عرض وارتفاع لكائن بيانات ثنائية لفيديو (image blob)، ويمكن للأخير استخلاص العرض والارتفاع والمدة والزاوية ونسبة العرض إلى الإرتفاع لكائن بيانات ثنائية لفيديو (video blob).
  • config.active_storage.previewers: يقبل مصفوفة من الأصناف التي تشير إلى معاينات الصور المتوفرة في كائنات البيانات الثنائية لـ Active Storage. وهو بشكل افتراضي [ActiveStorage::Previewer::PDFPreviewer, ActiveStorage::Previewer::VideoPreviewer]. يمكن للأول أن يولّد صورة مصغّرة من الصفحة الأولى من كائن بيانات ثنائية لملف PDF (أي PDF blob) وأما الأخير فمن الإطار المناسب لكائن بيانات ثنائية لفيديو (video blob).
  • config.active_storage.paths: يقبل جدول hash من الخيارات التي تشير إلى مواقع أوامر previewer/analyzer. وهو يساوي بشكل افتراضي إلى {}، مما يعني أنه سيبحث عن الاوامر في المسار الافتراضي. ويمكن أن يتضمّن أيًا من هذه الخيارات:
    • :ffprobe - موقع الملف ffprobe التنفيذي.
    • :mutool - موقع الملف mutool التنفيذي.
    • :ffmpeg - موقع الملف ffmpeg التنفيذي.
config.active_storage.paths[:ffprobe] = '/usr/local/bin/ffprobe'
  • config.active_storage.variable_content_types: يقبل مصفوفة من السلاسل النصيّة التي تشير إلى أنواع المحتوى التي يمكن لـ Active Storage تحويلها من خلال ImageMagick. وهو بشكل افتراضي يساوي %w(image/png image/gif image/jpg image/jpeg image/vnd.adobe.photoshop image/vnd.microsoft.icon)‎.
  • config.active_storage.content_types_to_serve_as_binary: يقبل مصفوفة من السلاسل النصية التي تشير إلى أنواع المحتوى التي سيخدمها Active Storage دائمًا كمُرفق (attachment)، بدلًا من مضمَّن (inline). وهو بشكل افتراضي يساوي %w(text/html text/javascript image/svg+xml application/postscript application/x-shockwave-flash text/xml application/xml application/xhtml+xml)‎.
  • config.active_storage.queue: يمكن أن يُستخدم لتعيين اسم طابور Active Job المستخدمة لأداء مهام مثل تحليل محتوى كائن بيانات ثنائية أو تطهير مدوّنة.
config.active_storage.queue = :low_priority
  • config.active_storage.logger: يمكن أن يُستخدم لتعيين أداة التسجيل التي يستخدمها Active Record، وهو يقبل مسجلًا يتطابق مع الواجهة Log4r أو مع صنف روبي Logger الافتراضي.
config.active_storage.logger = ActiveSupport::Logger.new(STDOUT)

ضبط قاعدة البيانات

بما أن كل تطبيق ريلز تقريبًا سيتصل بقاعدة بيانات، فيمكنك الاتصال بقاعدة البيانات عن طريق تحديد متغيّر البيئة ENV['DATABASE_URL']‎ أو باستخدام ملف ضبط يسمى config/database.yml.

ويمكنك باستخدام الملف config/database.yml تحديد جميع المعلومات اللازمة للوصول إلى قاعدة بياناتك:

development:
  adapter: postgresql
  database: blog_development
  pool: 5

سيتصل هذا بقاعدة بيانات تدعى blog_development باستخدام المحوّل postgresql، ويمكن تخزين هذه المعلومات نفسها في عنوان URL وتوفيرها عبر متغير البيئة كالتالي:

> puts ENV['DATABASE_URL']
postgresql://localhost/blog_development?pool=5

يحتوي الملف config/database.yml على أقسام لثلاث بيئات مختلفة يمكن تشغيل ريلز فيها افتراضيًا:

  • تُستخدم بيئة التطوير في الموقع development/local في حاسوبك أثناء تفاعلك يدويًا مع التطبيق.
  • تُستخدم بيئة الاختبار عند تشغيل الاختبارات التلقائيّة.
  • تُستخدم بيئة الإنتاج عند نشر التطبيق الخاص بك حتى يستخدمه الجميع.

إذا أردت، فيمكنك تحديد عنوان URL داخل الملف config/database.yml.

development:
  url: postgresql://localhost/blog_development?pool=5

يمكن أن يحتوي الملف config/database.yml على وسوم ERB مثل <‎%= %‎> وسيقيّم أي شيء داخل هذه الوسوم على أنه شيفرة روبي، ويمكنك استخدام هذا لسحب البيانات من متغيّر بيئة أو لإجراء العمليات الحسابيّة لإنشاء معلومة الاتصال المطلوبة.

تنبيه: لا تحتاج إلى تحديث ضبط قاعدة البيانات يدويًا. إذا نظرّت إلى خيارات مولّد التطبيق، سترى أن أحد هذه الخيارات يدعى ‎--database، ويسمح لك هذا باختيار محوّل من قائمة قواعد البيانات العلائقيّة الأكثر استخدامًا، ويمكنك حتى تشغيل المولّد بشكل متكرّر: cd .. && rails new blog --database=mysql. وعند تأكيد الكتابة فوق الملف config/database.yml، سيُضبَط التطبيق من أجل MySQL بدلًا من SQLite وستجد في ما يلي أمثلة تفصيليّة لاتصالات قواعد البيانات الشائعة.

تفضيلات الاتصال

نظرًا لوجود طريقتين لضبط الاتصال (باستخدام config/database.yml أو باستخدام متغيّر البيئة)، فمن المهم فهم كيفية تفاعلهما.

إذا كان لديك الملف config/database.yml وكان فارغًا لكن كان متغير البيئة ENV['DATABASE_URL']‎ موجودًا، فسيتصل ريلز بقاعدة البيانات عبر متغيّر البيئة الخاص بك:

$ cat config/database.yml
 
$ echo $DATABASE_URL
postgresql://localhost/my_database

إذا كان لديك الملف config/database.yml ولم يكن لديك متغير البيئة ENV['DATABASE_URL']‎، فسيُستخدم هذا الملف للاتصال بقاعدة البيانات الخاصة بك:

$ cat config/database.yml
development:
  adapter: postgresql
  database: my_database
  host: localhost
 
$ echo $DATABASE_URL

إذا كان لديك كلًا من الملف config/database.yml ومتغير البيئة ENV['DATABASE_URL']‎ المضبوطين، فسيدمج ريلز الضبط معًا. ولفهم هذا بشكل أفضل، يجب أن نرى بعض الأمثلة. عندما تتكرر معلومات الاتصال، سيأخذ متغيّر البيئة الأولويّة:

$ cat config/database.yml
development:
  adapter: sqlite3
  database: NOT_my_database
  host: localhost
 
$ echo $DATABASE_URL
postgresql://localhost/my_database
 
$ bin/rails runner 'puts ActiveRecord::Base.configurations'
{"development"=>{"adapter"=>"postgresql", "host"=>"localhost", "database"=>"my_database"}}

هنا يتطابق adapter و host و database مع المعلومات المتوفّرة في ENV['DATABASE_URL']‎. إذا تم توفير معلومات غير مكرّرة، فستُؤخَذ جميع القيم الفريدة بالحسبان، وسيأخذ متغيّر البيئة الأسبقيّة في حالة حدوث أي تعارضات.

$ cat config/database.yml
development:
  adapter: sqlite3
  pool: 5
 
$ echo $DATABASE_URL
postgresql://localhost/my_database
 
$ bin/rails runner 'puts ActiveRecord::Base.configurations'
{"development"=>{"adapter"=>"postgresql", "host"=>"localhost", "database"=>"my_database", "pool"=>5}}

بما أن pool ليس في المعلومات المقدمّة في ENV['DATABASE_URL']‎، فستدمج معلوماته، وبما أن adapter مكرّر، فستُؤخَذ معلومات اتصال من ENV['DATABASE_URL']‎. تتمثّل الطريقة الوحيدة لعدم استخدام معلومات الاتصال بشكل صريح في ENV['DATABASE_URL']‎ في تحديد اتصال URL صريح باستخدم المفتاح الفرعي "url":

$ cat config/database.yml
development:
  adapter: sqlite3
  pool: 5
 
$ echo $DATABASE_URL
postgresql://localhost/my_database
 
$ bin/rails runner 'puts ActiveRecord::Base.configurations'
{"development"=>{"adapter"=>"postgresql", "host"=>"localhost", "database"=>"my_database", "pool"=>5}}

يجري هنا تجاهل معلومات الاتصال في ENV['DATABASE_URL']‎، لاحظ اختلاف adapter واسم قاعدة البيانات database. نظرًا لأنه من الممكن تضمين ERB في config/database.yml، فمن الأفضل أن تظهر بوضوح أنك تستخدم ENV['DATABASE_URL']‎ للاتصال بقاعدة البيانات، وهذا مفيد بشكل خاص في بيئة الإنتاج لأنه يجب أن لا تودع الأسرار مثل كلمة مرور قاعدة البيانات في متحكّم المصدر الخاص بك (مثل Git).

$ cat config/database.yml
production:
  url: <%= ENV['DATABASE_URL'] %>

أصبح السلوك الآن واضح، إذ أننا لا نستخدم سوى معلومات الاتصال في ENV['DATABASE_URL']‎.

ضبط قاعدة بيانات SQLite3

يأتي ريلز مع دعم مضمّن لـ SQLite3، وهو تطبيق قاعدة بيانات خفيف بدون خوادم. وبما أن بيئة الإنتاج المزدحمة قد تفرط في تحميل SQLite، فإنه يعمل بشكل جيّد في بيئة التطوير والاختبار. ويفترض ريلز استخدام قاعدة بيانات SQLite عند إنشاء مشروع جديد، لكن يمكنك دائمًا تغييره لاحقًا.

في ما يلي قسم ملف الضبط الافتراضي (config/database.yml) مع معلومات الاتصال لبيئة التطوير:

development:
  adapter: sqlite3
  database: db/development.sqlite3
  pool: 5
  timeout: 5000

ملاحظة: يستخدم ريلز قواعد بيانات SQLite3 لتخزين البيانات بشكل افتراضي لأن قاعدة البيانات لا تحتاج إلى ضبط. ويدعم ريلز MySQL (بما في ذلك MariaDB) أيضًا و PostgreSQL "خارج الصندوق" ولديه ملحقات للعديد من أنظمة قواعد البيانات. وإذا كنت تستخدم قاعدة البيانات في بيئة الإنتاج، فغالبا ما يملك ريلز محوّلًا لها.

ضبط قاعدة بيانات MySQL أو MariaDB

إذا اخترّت استخدام MySQL أو MariaDB بدلًا من SQLite3،  فسيبدو الملف config/database.yml مختلفًا قليلًا. إليك كيف سيبدو:

development:
  adapter: mysql2
  encoding: utf8
  database: blog_development
  pool: 5
  username: root
  password:
  socket: /tmp/mysql.sock

إذا كانت قاعدة بياناتك تملك مستخدم جذر مع كلمة مرور فارغ، فسيعّمل هذا الضبط لك. وخلاف ذلك، يجب عليك تغيير اسم المستخدم وكلمة المرور في القسم development إلى تلك التي حددتها أنت.

ضبط قاعدة بيانات PostgreSQL

إذا اخترت استخدام PostgreSQL، فيجب تخصيص الملف config/database.yml لاستخدام قواعد بيانات PostgreSQL:

development:
  adapter: postgresql
  encoding: unicode
  database: blog_development
  pool: 5

يتم تمكين البيانات المعدّة (Prepared Statements) بشكل افتراضي في PostgreSQL، ويمكنك تعطيل ذلك عن طريق تعيين prepared_statements إلى false:

production:
  adapter: postgresql
  prepared_statements: false

إذا كان مفعّلًا، سيُنشئ Active Record ما يصل إلى 1000 تعبير مهيَّئ (prepared_statements) لكل اتصال قاعدة البيانات بشكل افتراضي. ولتعديل هذا السلوك، يمكنك تعيين statement_limit إلى قيمة مختلفة مثل:

production:
  adapter: postgresql
  statement_limit: 200

كلما زادت البيانات المهيَّأة لوضعها قيد الاستخدام، زدات الذاكرة التي تتطلّبها قاعدة البيانات الخاص لك. وإذا أدت قاعدة بيانات PostgreSQl إلى امتلاء الذاكرة، فجرّب تقليل statement_limit أو عطلها.

ضبط قاعدة بيانات SQLite3 لمنصة JRuby

إذا اخترت استخدام SQLite3 وأنت تستخدم JRuby، فسيبدو الملف config/database.yml مختلفًا قليلًا. سيبدو القسم development بالشكل التالي:

development:
  adapter: jdbcsqlite3
  database: db/development.sqlite3

ضبط قاعدة بيانات MySQL أو MariaDB لمنصة JRuby

إذا اخترت استخدام MySQL أو MariaDB  وأنت تستخدم JRuby، فسيبدو الملف config/database.yml مختلفًا قليلًا:

development:
  adapter: jdbcmysql
  database: blog_development
  username: root
  password:

ضبط قاعدة بيانات PostgreSQL لمنصة JRuby

إذا اخترت استخدام PostgreSQL وأنت تستخدم JRuby، فسيبدو الملف config/database.yml مختلفًا قليلًا. سيبدو القسم development بالشكل التالي:

development:
  adapter: jdbcpostgresql
  encoding: unicode
  database: blog_development
  username: blog
  password:

غيّر اسم المستخدم وكلمة المرور بالشكل المناسب.

إنشاء بيئات ريلز

يأتي ريلز مع ثلاث بيئات: "التطوير" و "الاختبار" و "الإنتاج". وفي حين أن هذه البيئات كافية لمعظم حالات الاستخدام، فهنالك ظروف تحتاج فيها إلى المزيد من البيئات.

تخيّل أن لديك خادمًا يشبه بيئة الإنتاج لكنه يُستخدَم فقط للاختبار، يطلق على هذا الخادم اسم «خادم التحضير للإطلاق» (staging server). ولتعريف بيئة تسمى "staging" لهذا الخادم، أنشئ ملفًا باسم config/environments/staging.rb ويرجى استخدام محتويات أي ملف موجود في config/environments كنقطة بداية وعدّل بعدها المحتوى كما تريد.

هذه البيئة لا تختلف عن البيئة الافتراضيّة، ابدأ خادمًا جديدًا باستخدام rails server -e staging، وطرفية باستخدام rails console -e staging، وتأكد من البيئة عبر Rails.env.staging?‎ …إلخ.

النشر إلى مجلد فرعي (جذر url نسبي)

يفترض ريلز بشكل افتراضي أن التطبيق يعمل في الجذر (على سبيل المثال /) ويشرح لك هذا القسم كيفيّة تشغيل التطبيق الخاص بك داخل مجلّد.

لنفترض أننا نريد نشر تطبيقنا على "‎/app1"، يحتاج ريلز إلى معرفة هذا المجلّد لإنشاء المسارات المناسبة:

config.relative_url_root = "/app1"

وبدلًا من ذلك، يمكنك ضبط متغيّر البيئة RAILS_RELATIVE_URL_ROOT.

سيضيف ريلز الآن "‎/app1" عند إنشاء الروابط.

استخدام Passenger

يسهّل Passenger هذه العمليّة، ويمكنك العثور على الضبط المناسب في دليل Passenger.

استخدام وكيل عكسي

يتمتع نشر تطبيقك باستخدام وكيل عكسي (Reverse Proxy) بمزايا كثيرة، فهي تسمح لك بمزيد من التحكم في الخادم الخاص بك عن طريق وضع المكونات المطلوبة في تطبيقك في طبقات.

يمكن استخدام العديد من خوادم الويب الحديثة كخادم وكيل لتحقيق التوازن بين عناصر الجهات الخارجيّة مثل خوادم التخزين المؤقت أو خوادم التطبيقات.

وأحد هذه التطبيقات التي يمكنك تشغيلها خلف الخادم العكسي هو Unicorn.

في هذه الحالة، ستحتاج إلى ضبط خادم الوكيل (مثل NGINX، أو Apache ...إلخ) إلى قبول الاتصالات من تطبيق الخادم (Unicorn)، وبشكل افتراضي سيستمع Unicorn إلى اتصالات TCP على المنفذ 8080، لكن يمكنك تغيير المنفذ أو ضبطة لاستخدام المقابس بدلًا من ذلك.

يمكنك العثور على المزيد من المعلومات في ملف اقرأني الذي يخص Unicorn وفهم الفلسفة الكامنة وراء ذلك.

بمجرّد ضبط خادم التطبيق، يجب عليك توجيه طلبات الوكيل إليه عن طريق ضبط خادم الويب بشكل مناسب. على سبيل المثال، قد يتضمّن الخادم NGINX الخاص بك التالي:

upstream application_server {
  server 0.0.0.0:8080;
}
 
server {
  listen 80;
  server_name localhost;
 
  root /root/path/to/your_app/public;
 
  try_files $uri/index.html $uri.html @app;
 
  location @app {
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Host $http_host;
    proxy_redirect off;
    proxy_pass http://application_server;
  }
 
  # ضبط آخر
  # ...
}

تأكد من قراءة توثيق NGINX للحصول على أحدث المعلومات.

إعدادات بيئة ريلز

يمكن أيضًا ضبط بعض أجزاء ريلز خارجيًا من خلال توفير متغيرات البيئة، ويتعرّف على المتغيرات البيئة التالية من خلال أجزاء مختلفة من ريلز:

  • ENV["RAILS_ENV"]‎: تعرّف بيئة ريلز (التطوير، أو الإنتاج، أو الاختبار ...إلخ.) والتي سيعمل ريلز فيها.
  • ENV["RAILS_RELATIVE_URL_ROOT"]‎: يستخدم بواسطة رمز التوجيه للتعرّف على عناوين URL عند نشر تطبيقك إلى مجلّد فرعي.
  • ENV["RAILS_CACHE_ID"]‎ و ENV["RAILS_APP_VERSION"]‎: يُستخدمان لإنشاء مفاتيح ذاكرة تخزين مؤقت موسّعة في شيفرة التخزين المؤقت لريلز، ويسمح هذا لك بأن يكون لديك عدة مخازن منفصلة من نفس التطبيق.

استخدام ملفات المهيئ (Initializer)

بعد تحميل الإطار وبقية الجواهر في تطبيقك، يتحوّل ريلز لتحميل المهيئات (Initializers)، تتجه روبي لتحميل المهيئات. المهيئ هو أي ملف روبي مخزّن في المجلد config/initializers في تطبيقك، ويمكنك استخدام المهيئات (Initializers)، للاحتفاظ بإعدادات الضبط التي يجب إجراؤها بعد تحميل جميع الأطر والجواهر، مثل خيارات الإعداد لهذه الأجزاء.

ملاحظة: يمكنك استخدام المجلدات الفرعيّة لتنظيم المهيئات الخاصة بك إذا أردت ذلك، لأن ريلز سينظر إلى التسلسل الهرمي بأكملة من المجلد Initializers إلى الداخل.

تنبيه: بينما يدعم ريلز ترقيم أسماء ملفات Initializers لأغراضي ترتيب التحميل، فإن الأسلوب الأفضل هو وضع أي شيفرة برمجية مطلوبة للتحميل بترتيب معيّن داخل نفس الملف. ويقلل هذا انحسار اسم الملف (file name churn)، ويجعل التبعيات أكثر وضوحًا، ويمكن أن يساعد في طرح مفاهيم جديدة داخل تطبيقك.

أحداث التهيئة

يحتوي ريلز على خمسة أحداث تهيئة يمكن ربطها (مدرجة بالترتيب الذي تعمل به):

  • before_configuration: يُنفَّذ هذا بمجرّد أن يرث ثابت التطبيق من Rails::Application، وتقيّم استدعاءات config قبل حدوث ذلك.
  • before_initialize: يُنفَّذ هذا مباشرةً قبل حدوث عملية التهيئة الخاصة بالتطبيق باستخدام :bootstrap_hook initializer بالقرب من بداية عملية تهيئة ريلز.
  • to_prepare: يُنفَّذ بعد تشغيل المهيئ لجميع Railties (بما في ذلك التطبيق نفسه)، لكن قبل التحميل الحثيث (eager loading) وبناء كومة البرمجيات الوسيطة (middleware stack). الأهم من ذلك، سيُنفَّذ على كل طلب في التطوير، لكن مرة واحدة (أثناء التشغيل) في الإنتاج والاختبار.
  • before_eager_load: يُنفَّذ هذا مباشرةً قبل حدوث التحميل الحثيث (eager loading)، والذي هو السلوك الافتراضي لبيئة الإنتاج وليس لبيئة التطوير.
  • after_initialize: يُنفَّذ مباشرةً بعد تهيئة التطبيق، وبعد تشغيل مهئيات التطبيق في config/initializers.

لتعريف حدث لهذه الخطافات، استخدم صياغة الكتلة داخل الصنف الفرعي Rails::Application أو Rails::Railtie أو Rails::Engine:

module YourApp
  class Application < Rails::Application
    config.before_initialize do
      # تجري عملية تهيئة الشيفرة هنا
    end
  end
end

بدلًا من ذلك، يمكنك إجراء ذلك من خلال التابع config في الكائن Rails.application:

Rails.application.config.before_initialize do
  # تجري عملية تهيئة الشيفرة هنا
end

تحذير: لا يجري إعداد بعض أجزاء تطبيقك، ولا سيما التوجيه، في النقطة التي تُستدعَى فيها الكتلة after_initialize.

Rails::Railtie.initializer

يحتوي ريلز على العديد من المهيئات (initializers) التي تعمل عند بدء التشغيل والتي تم تعريفها كافة باستخدام التابع initializer من Rails::Railtie. وهذا مثال على المهيئ set_helpers_path من وحدة التحكم:

initializer "action_controller.set_helpers_path" do |app|
  ActionController::Helpers.helpers_path = app.helpers_paths
end

يأخذ التابع initializer ثلاثة معاملات؛ الأول هو اسم المهيئ والثاني هو جدول hash اختياري (غير معروض هنا) والثالث هو كتلة. يمكن تحديد المفتاح :before في جدول الخيارات hash لتحديد المهيئ الجديد الذي يجب تشغيله أولًا، والمفتاح :after لتحديد المهيئ المراد تشغيله فيما بعد.

ستشتغل المهيئات المعرّفة باستخدام التابع initializer بالترتيب الذي تم تعريفها فيه، باستثناء تلك التي تستخدم التابعين :before و ‎:after.

تحذير: يمكنك وضع المهيئ الخاص بك قبل أو بعد أي مهيئ آخر في السلسلة، طالما أنه منطقي. لنفترض أن لديك 4 مهيئات تسمى من "one" إلى "four" (معرّفة بهذا الترتيب) ولقد عرّفت "four" ليعمل قبل "four" -المعرف مسبقًا - ولكن بعد "three" وهذا ليس منطقيًا؛ لن يتمكن ريلز آنذاك من تحديد ترتيب المهيئ الخاص بك.

يعتبر معامل الكتلة للتابع initializer هو نسخة من التطبيق نفسه، ولذا يمكننا الوصول إلى ضبطه باستخدام التابع config كما في المثال.

بما أن Rails::Application يرث من Rails::Railtie (بشكل غير مباشر)، يمكنك استخدام التابع initializer في config/application.rb لتعريف المهيئات للتطبيق.

المهيئات

فيما يلي قائمة شاملة لجميع المهيئات الموجودة في ريلز بالترتيب الذي تم تعريفها فيه (وبالتالي تشغيلها ما لم يُنص على خلاف ذلك).

  • load_environment_hook: يعمل كعنصر نائب (placeholder) بحيث يمكن تعريف :load_environment_config ليعمل قبله.
  • load_active_support: يتطلّب active_support/dependencies الذي يعد الأساس لـ Active Record، وهو يتطلّب اختياريًا active_support/all إذا كان config.active_support.bare غير صحيح (un-truthful) وهو الإعداد الافتراضي.
  • initialize_logger: يهيئ المسجّل (الكائن ActiveSupport::Logger) للتطبيق ويجعل من الممكن الوصول إليه في Rails.logger، بشرط أن لا يوجود مهيئ مدرج قبل هذه النقطة التي عرّف فيها Rails.logger.
  • initialize_cache: إذا لم يعيَّن Rails.cache بعد، فهيئ ذاكرة التخزين المؤقت بالرجوع إلى القيمة الموجودة في config.cache_store وخزّن النتائج على أنها Rails.cache. إذا كان الكائن يستجيب للتابع middleware، إذ يُدرج الوسيط الخاص به قبل Rack::Runtime في كومة الوسيط (middleware stack).
  • set_clear_dependencies_hook: هذا المهيئ - الذي يعمل فقط في حالة كان cache_classes يساوي false - يستخدم ActionDispatch::Callbacks.after لإزالة الثوابت المشار إليها أثناء الطلب من مساحة الكائن بحيث يعاد تحميلها أثناء الطلب التالي.
  • initialize_dependency_mechanism: إذا كان config.cache_classes يساوي true، اضبط ActiveSupport::Dependencies.mechanism ليطلب التبعيات عبر require بدلًا من تحميلها.
  • bootstrap_hook: يُنفِّذ جميع كتل before_initialize المهيئة.
  • i18n.callbacks: في بيئة التطوير، عيّن رد النداء to_prepare الذي سيستدعي I18n.reload!‎ إذا تغيّرت أي من المحليات منذ آخر طلب. وفي وضع الإنتاج، سيشتغل هذا الاستدعاء فقط عند الطلب الأول.
  • active_support.deprecation_behavior: يهيئ تقارير الإهمال للبيئات، وهو بشكل افتراضي :log للتطوير و ‎:notify للإنتاج و :stderr للإختبار. وإذا لم تعيّن قيمة للضبط config.active_support.deprecation، فسيطالب هذا المهيئ المستخدم بضبط هذا السطر في الملف config/environments الخاص بالبيئة الحالية. يمكن ضبطه إلى مصفوفة من القيم.
  • active_support.initialize_time_zone: يعيّن المنطقة الزمنيّة الافتراضيّة للتطبيق استنادًا إلى الضبط config.time_zone والذي يساوي افتراضيًا "UTC".
  • active_support.initialize_beginning_of_week: يعيّن بداية الأسبوع للتطبيق استنادًا إلى الضبط config.beginning_of_week والذي يساوي افتراضيًا :monday.
  • active_support.set_configs: يهيئ Active Record باستخدام الإعدادت الموجودة في config.active_support عن طريق إرسال أسماء التوابع على أنها ضابطة (setters) لـ ActiveSupport وتمرير القيم من خلالها.
  • action_dispatch.configure: يضبط ActionDispatch::Http::URL.tld_length لتعيين قيمة config.action_dispatch.tld_length.
  • action_view.set_configs: إعداد Action View عن طريق استخدام الإعدادات الموجودة في config.action_view عن طريق إرسال أسماء التوابع على أنها ضابطة (setters) إلى ActionView::Base وتمرير القيم من خلالها.
  • action_controller.assets_config: تهيئة config.actions_controller.assets_dir إلى مجلّد التطبيق العام إذا لم يُضبَط بشكل صريح.
  • action_controller.set_helpers_path: يعيّن helpers_path الخاص بوحدة التحكم إلى helpers_path الخاص بالتطبيق.
  • action_controller.parameters_config: يضبط خيارات معاملات قويّة لـ ActionController::Parameters.
  • action_controller.set_configs: يعّد متحكم الحدث عن طريق استخدام الإعدادات الموجودة في config.action_controller عن طريق إرسال أسماء التوابع على أنها ضابطة (setters) إلى ActionController::Base وتمرير القيم من خلالها.
  • action_controller.compile_config_methods: يهيئ التوابع لإعدادات الضبط المحددة بحيث تكون أسرع في الوصول.
  • active_record.initialize_timezone: يعيّن ActiveRecord::Base.time_zone_aware_attributes إلى true بالإضافة إلى ضبط ActiveRecord::Base.default_timezone إلى UTC. عند قراءة الخاصيات من قاعدة البيانات، ستحوّل إلى المنطقة الزمنيّة المحددة بواسطة Time.zone.
  • active_record.logger: يعيّن ActiveRecord::Base.logger - إذا لم يُعيّن بالفعل - إلى Rails.logger.
  • active_record.migration_error: يضبط الوسيطات (middleware) للتأكد من وجود عمليات تهجير معلّقة.
  • active_record.check_schema_cache_dump: يحمّل ملف تفريغ التخزين المؤقت للمخطّط إذا هيئ بالفعل وكان متاحًا.
  • active_record.warn_on_records_fetched_greater_than: يُمكّن التحذيرات عند تُرجع الاستعلامات عدد كبير من السجلات.
  • active_record.set_configs: يضبط Active Record عن طريق استخدام الإعدادات الموجودة في config.active_record وذلك عن طريق ارسال أسماء التوابع على أنها ضابطة (setters) إلى ActiveRecord::Base وتمرير القيم من خلالها.
  • active_record.initialize_database: يحمّل إعدادات قاعدة البيانات (افتراضيًا) من config/database.yml ويُنشئ اتصال للبيئة الحاليّة.
  • active_record.log_runtime: يضمّن ActiveRecord::Railties::ControllerRuntime الذي هو المسؤول عن الإبلاغ عن الوقت الذي يستغرقه استدعاءات Active Record وحتى عودة الطلب إلى المسجل (logger).
  • active_record.set_reloader_hooks: يعيد تعيين جميع الاتصالات القابلة لإعادة التحميل إلى قاعدة البيانات في حالة تعيين config.cache_classes إلى القيمة false.
  • active_record.add_watchable_files: يضيف ملفات schema.rb و structure.sql إلى الملفات المراقبة.
  • active_job.logger: يعيّن ActiveJob::Base.logger - إذا لم تضبط بالفعل - إلى Rails.logger.
  • active_job.set_configs: يهيئ Active Job عن طريق استخدام الإعدادات الموجودة في config.active_job عن طريق ارسال أسماء التوابع على أنها ضابطة (setters) إلى ActiveJob::Base وتمرير القيم من خلالها.
  • action_mailer.logger: يعيّن ActionMailer::Base.logger - إذا لم تضبط بالفعل - إلى Rails.logger.
  • action_mailer.set_configs: يعد Action Mailer عن طريق استخدام الإعدادات الموجودة في config.action_mailer عن طريق ارسال أسماء التوابع على أنها ضابطة (setters) إلى ActionMailer::Base وتمرير القيم من خلالها.
  • action_mailer.compile_config_methods: يهيئ التوابع لإعدادات الضبط المحددة بحيث يكون الوصول إليها أسرع.
  • set_load_path: يعمل هذا المهيئ قبل bootstrap_hook ويضيف المسارات المحددة بواسطة config.load_paths وجميع مسارات التحميل التلقائي إلى ‎$LOAD_PATH.
  • set_autoload_paths: يعمل هذا المهيئ قبل bootstrap_hook ويضيف جميع مجلدات app الفرعية والمسارات المحددة بواسطة config.autoload_paths و config.eager_load_paths و config.autoload_once_paths إلى ActiveSupport::Dependencies.autoload_paths.
  • add_routing_paths: تحميل (بشكل افتراضي) جميع ملفات config/routes.rb (في التطبيق و railties بما في ذلك المحركات) وإعداد المسارات للتطبيق.
  • add_locales: يضيف الملفات في config/locales (من التطبيق و railties والمحركات) إلى I18n.load_path مما يتيح الترجمات في هذه الملفات.
  • add_view_paths: يضيف المجلد app/views من التطبيق و railties والمحركات إلى مسار البحث لملفات العرض للتطبيق.
  • load_environment_config: تحميل الملف config/environments للبيئة الحاليّة.
  • Prepend_helpers_path: يضيف المجلّد app/helpers من التطبيق و railties والمحركات إلى مسار البحث للمساعدين للتطبيق.
  • load_config_initializers: تحميل جميع ملفات روبي من config/initializers في التطبيق و railties والمحركات. يمكن استخدام الملفات الموجودة في هذا المجلّد لاستيعاب إعدادات الضبط التي يجب إجراؤها بعد تحميل جميع إطارات العمل.
  • engines_blank_point: يوفر نقطة في التهيئة (point-in-initialization) للربط إذا كنت ترغب في القيام بأي شيء قبل تحميل المحركات. بعد هذه النقطة، ستشتغل جميع مهيئات railtie والمحرك.
  • add_generator_templates: إيجاد القوالب للمولدات في lib/templates للتطبيق، railties والمحركات ويضيف هذه إلى الضبط config.generators.templates الذي سيجّعل القوالب متاحة لجميع المولدات للإشارة إليها.
  • ensure_autoload_once_paths_as_subset: التأكد أن الضبط config.autoload_once_paths لا يحتوي إلا على مسارات من config.autoload_paths. وإذا كان يحتوي على مسارات إضافيّة، فسيرفع استثناء.
  • add_to_prepare_blocks: تضاف الكتلة لجميع استدعاءات config.to_prepare في التطبيق أو railtie أو المحرك إلى ردود النداء to_prepare لـ Action Dispatch والتي ستشتغل لكل طلب في التطوير أو قبل أول طلب في الإنتاج.
  • add_builtin_route: إذا كان التطبيق قيد التشغيل في بيئة التطوير، فسيؤدي ذلك إلى إلحاق مسار لـ rails/info/properties إلى مسارات التطبيق، ويوفّر هذا المسار معلومات تفصيليّة مثل إصدار ريلز وروبي لـ public/index.html في تطبيق ريلز الافتراضي.
  • build_middleware_stack: بناء كومة وسيط (middleware stack) للتطبيق، ويرّجع كائن يملك التابع call الذي يأخذ كائن بيئة Rack للطلب.
  • eager_load!‎: إذا كان config.eager_load يساوي true، فنفِّذ خطافات config.before_eager_load ومن ثم استدعي eager_load!‎ الذي سيحمّل جميع config.eager_load_namespaces.
  • finisher_hook: يوفّر خطافًا بعد اكتمال تهيئة عملية التطبيق، بالإضافة إلى تشغيل جميع كتل config.after_initialize للتطبيق و railties والمحركات.
  • set_routes_reloader_hook: يضبط Action Dispatch لإعادة تحميل ملف المسارات باستخدام ActiveSupport::Callbacks.to_run.
  • disable_dependency_loading: يعطّل تحميل التبعيّة التلقائي إذا لم يعيّن config.eager_load إلى القيمة true.

تجميع قواعد البيانات

تدار اتصالات قواعد بيانات Active Record عن طريق ActiveRecord::ConnectionAdapters::ConnectionPool الذي يضمن تزامن مجمع الاتصالات كميّة الوصول الخيوط إلى عدد محدود من اتصالات قاعدة البيانات. الحد الافتراضي لهذا هو 5 ويمكن ضبطه في database.yml.

development:
  adapter: sqlite3
  database: db/development.sqlite3
  pool: 5
  timeout: 5000

نظرًا لأنه يتعامل مع تجمع الاتصالات داخل Active Record افتراضيًا، يجب أن تعمل جميع خوادم التطبيقات (Thin، Puma، Unicorn …إلخ) بنفس الطريقة. إن قاعدة بيانات مجمع الاتصالات فارغ افتراضيًا. كلما زاد الطلب على الاتصالات، سيؤدي إلى ضبطها حتى تصل إلى حد مجمع الاتصالات.

أي طلب سيتحقق من الاتصال المطلوب إلى قاعدة البيانات في المرة الأولى. وفي نهاية الطلب، سيتحقق من إرجاع الاتصال، وهذا يعني أن منفذ الاتصال الإضافي سيتوفّر مرة أخرى للطلب التالي في قائمة الانتظار.

إذا حاولت استخدام اتصالات أكثر من تلك المتاحة، فسيحظرك Active Record وسينتظر اتصالًا من المجمع. وإذا لم يتمكن من الحصول على اتصال، فسيرمي خطأ عند انتهاء المهلة الزمنية مثل الخطأ التالي.

ActiveRecord::ConnectionTimeoutError - could not obtain a database connection within 5.000 seconds (waited 5.000 seconds)

إذا حصلت على الخطأ أعلاه، فقد ترغب في زيادة حجم مجمع الاتصال عن طريق زيادة الخيار pool في database.yml.

ملاحظة: إذا كنت تعمل في بيئة متعددة الخيوط، فقد تكون هنالك فرصة لأن العديد من الخيوط قد تصل إلى عدة اتصالات في نفس الوقت. وبناءًا على تحميل الطلب الحالي، قد يكون لديك العديد من الخيوط التي تتنافس على عدد محدود من الاتصالات.

الضبط المخصص

يمكنك ضبط الشيفرة البرمجية الخاصة بك من خلال كائن ضبط ريلز مع ضبط مخصص تحت إما مجال الاسم config.x أو config مباشرةً؛ والفرق الرئيسي بينهما هو أنه يجب أن تستخدم config.x إذا كنت تعرّف ضبطًا متداخلًا (مثل config.x.nested.nested.hi) و config لضبط ذي مستوى واحد (مثل config.hello).

config.x.payment_processing.schedule = :daily
config.x.payment_processing.retries  = 3
config.super_debugger = true

نقاط الضبط التالية متاحة بعد ذلك من خلال كائن الضبط:

Rails.configuration.x.payment_processing.schedule # => :daily
Rails.configuration.x.payment_processing.retries  # => 3
Rails.configuration.x.payment_processing.not_set  # => nil
Rails.configuration.super_debugger                # => true

يمكنك أيضًا استخدام Rails::Application.config_for لتحميل ملفات الضبط بأكملها:

# config/payment.yml:
production:
  environment: production
  merchant_id: production_merchant_id
  public_key:  production_public_key
  private_key: production_private_key
development:
  environment: sandbox
  merchant_id: development_merchant_id
  public_key:  development_public_key
  private_key: development_private_key
 
# config/application.rb
module MyApp
  class Application < Rails::Application
    config.payment = config_for(:payment)
  end
end
Rails.configuration.payment['merchant_id'] # => production_merchant_id or development_merchant_id

فهرسة محركات البحث

في بعض الأحيان، قد ترغب في منع ظهور بعض صفحات تطبيقك على مواقع البحث مثل Google أو Bing أو Yahoo أو Duck Duck Go. تعمل البرامج الآلية التي تفهرس هذه المواقع أولًا على تحليل الملف http://your-site.com/robots.txt لمعرفة الصفحات التي يُسمَح لها بفهرستها.

ينشئ ريلز هذا الملف داخل المجلد ‎/public. وافتراضيًا، يسمح لمحركات البحث بفهرسة جميع صفحات تطبيقك، وإذا كنت ترغب في حظر فهرسة جميع صفحات تطبيقك، فاستخدم ما يلي:

User-agent: *
Disallow: /

لحظر فهرسة صفحات محدّدة فقط، فمن الضروري استخدام صياغة أكثر تعقيدًا. تعلّم كيفية القيام بذلك من التوثيق الرسمي.

مراقب نظام الملفات الحدثي

عند تحميل الجوهرة listen، فإن ريلز يستخدم مراقب نظام الملفات الحدثي (evented file system monitor) للكشف على التغييرات عندما يكون config.cache_classes مساويًا إلى القيمة false:

group :development do
  gem 'listen', '>= 3.0.5', '< 3.2'
end

خلاف ذلك، في كل طلب، يمر ريلز على شجرة التطبيق للتأكد ما إذا قد تغيّر أي شيء.

لا توجد حاجة إلى جوهرة إضافيّة في لينكس وماك، ولكن بعضها مطلوب لأنظمة *BSD وويندوز.

لاحظ أن بعض الإعدادات غير مدعومة.

مصادر