Rails/generators

مولدات ريلز هي أداة أساسية إذا كنت تخطط لتحسين سير عملك. مع هذا الدليل سوف تتعلم كيفية إنشاء المولدات وتخصيص المولدات الموجودة.

بعد قراءة هذا الدليل، ستتعلم:

• كيفية معرفة أي المولدات المتوفرة في التطبيق الخاص بك.
• كيفية إنشاء مولد باستخدام القوالب.
• كيفية بحث ريلز عن المولدات قبل استدعائها.
• كيفية إنشاء ريلز داخليًا شيفرة من القوالب.
• كيفية تخصيص المنصة الخاصة بك (scaffold) عن طريق إنشاء مولدات جديدة.
• كيفية تخصيص المنصة الخاصة بك (scaffold) عن طريق تغيير قوالب المولدات.
• كيفية استخدام التراجعات (fallbacks) لتجنب استبدال مجموعة ضخمة من المولدات.
• كيفية إنشاء قالب التطبيق.

الاتصال الأول

عندما تنشئ تطبيقًا باستخدام الأمر rails، فأنت في الحقيقة تستخدم مولد ريلز. بعد ذلك، يمكنك الحصول على قائمة بجميع المولدات المتاحة عن طريق استدعاء rails generate فقط:

$ rails new myapp
$ cd myapp
$ bin/rails generate

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

$ bin/rails generate helper --help

إنشاء المولد الأول الخاص بك

منذ الإصدار 3.0 من ريلز، تنشأ المولدات أعلى Thor. يوفر Thor خيارات قوية للتحليل، وواجهة برمجة تطبيقات رائعة لمعالجة الملفات. على سبيل المثال، لإنشاء مولد ينشئ ملف مُهيئ يسمى initializer.rb داخل config/initializers.

الخطوة الأولى هي إنشاء ملف في lib/generators/initializer_generator.rb بالمحتوى التالي:

class InitializerGenerator < Rails::Generators::Base
  def create_initializer_file
    create_file "config/initializers/initializer.rb", "# Add initialization content here"
  end
end

ملاحظة: create_file هو تابع مقدم من Thor::Actions. يمكن العثور على توثيق للتابع create_file وتوابع Thor الأخرى في توثيق Thor.

مولدنا الجديد بسيط للغاية: فهو يرث من Rails::Generators::Base وله تعريف واحد للتابع. عندما يُستدعَى المولد، يُنفذ كل تابع عام في المولد بالترتيب التسلسلي الذي عُرِّف به. وأخيرًا، نستدعي التابع create_file الذي سينشئ ملفًا في الوجهة المحددة بالمحتوى المحدد. إذا كنت معتادًا على  قوالب الواجهة البرمجية (API) لتطبيق ريلز، فستشعر بشيء من الألفة عند استخدام واجهة برمجة التطبيقات للمولدات الجديدة.

لاستدعاء المولد الجديد، نحتاج فقط إلى القيام بما يلي:

$ bin/rails generate initializer

قبل أن نبدأ، لنرى وصف علامة المولد الجديد:

$ bin/rails generate initializer --help

ريلز عادةً ما تكون قادرة على توليد أوصاف جيدة إذا كان المولّد هو مجال اسم، مثل

ActiveRecord::Generators::ModelGenerator، ولكن ليس في هذه الحالة بالذات. يمكننا حل هذه المشكلة بطريقتين. الحل الأول هو استدعاء desc داخل مولدنا:

class InitializerGenerator < Rails::Generators::Base
  desc "This generator creates an initializer file at config/initializers"
  def create_initializer_file
    create_file "config/initializers/initializer.rb", "# Add initialization content here"
  end
end

الآن يمكننا رؤية الوصف الجديد من خلال استدعاء ‎--help على المولد الجديد. الطريقة الثانية لإضافة وصف هي عن طريق إنشاء ملف يسمى USAGE في نفس المجلد الموجود فيه مولدنا. سنقوم بذلك في الخطوة التالية.

إنشاء مولدات مع المولدات

المولدات نفسها لديها مولد:

$ bin/rails generate generator initializer
      create  lib/generators/initializer
      create  lib/generators/initializer/initializer_generator.rb
      create  lib/generators/initializer/USAGE
      create  lib/generators/initializer/templates
      invoke  test_unit
      create    test/lib/generators/initializer_generator_test.rb

هذا هو المولد الذي أُنشأ للتو:

class InitializerGenerator < Rails::Generators::NamedBase
  source_root File.expand_path('templates', __dir__)
end

أولًا، لاحظ أننا نرث من Rails::Generators::NamedBase بدلًا من Rails::Generators::Base. هذا يعني أن مولدنا يتوقع وسيطًا واحدًا على الأقل، والذي سيكون اسم المُهيئ، وسيكون متاحًا في الشيفرة الخاص بنا في المتغير name.

يمكننا أن نرى ذلك من خلال استدعاء وصف هذا المولد الجديد (لا تنس حذف ملف المولد القديم):

$ bin/rails generate initializer --help
Usage:
  rails generate initializer NAME [options]

يمكننا أيضًا رؤية أن المولد الجديد لديه تابع صنف يُسمى source_root. يشير هذا التابع إلى مكان وضع قوالب المولد الخاصة بنا، إن وجدت، وبشكل افتراضي يشير إلى المجلد lib/generators/initializer/templates الذي أُُنشِئ.

لفهم معنى قالب المولد، نُنشئ الملف lib/generators/initializer/templates/initializer.rb بالمحتوى التالي:

# Add initialization content here

والآن دعنا نغير المولد لنسخ هذا القالب عند الاستدعاء:

class InitializerGenerator < Rails::Generators::NamedBase
  source_root File.expand_path('templates', __dir__)
 
  def copy_initializer_file
    copy_file "initializer.rb", "config/initializers/#{file_name}.rb"
  end
end

دعنا ننفذه على المولد الخاص بنا:

$ bin/rails generate initializer core_extensions

يمكننا أن نرى أنه أُنشئ مُهيئ باسم core_extensions في config/initializers/core_extensions.rb بمحتويات القالب الخاص بنا. وهذا يعني أن copy_file نسخ الملف في المصدر الأصل الخاص بنا إلى مسار الوجهة الذي قدمناه. يُنشَأ التابع file_name تلقائيًا عندما نرث من Rails::Generators::NamedBase.

سنشير إلى التوابع المتوفرة للمولدات في القسم الأخير من هذا الدليل.

البحث عن مولدات

عند تشغيل rails generate initializer core_extensions تتطلب ريلز هذه الملفات بدورها حتى تعثر على أحدها:

rails/generators/initializer/initializer_generator.rb
generators/initializer/initializer_generator.rb
rails/generators/initializer_generator.rb
generators/initializer_generator.rb

إذا لم يعثر على أي شيء، فستُعرَض رسالة خطأ.

ملاحظة: تضع الأمثلة أعلاه الملفات تحت تطبيق lib لأن المجلد المذكور ينتمي إلى ‎$LOAD_PATH.

تخصيص سير العمل الخاص بك

المولدات الخاصة بريلز مرنة بما يكفي لتسمح لك بتخصيص السقالات (scaffolding). يمكن ضبطها في config/application.rb، هذه بعض الافتراضات:

config.generators do |g|
  g.orm             :active_record
  g.template_engine :erb
  g.test_framework  :test_unit, fixture: true
end

قبل تخصيص سير العمل الخاص بنا، لنرى أولًا الشكل الذي تبدو عليه سقالاتنا (scaffold):

$ bin/rails generate scaffold User name:string
      invoke  active_record
      create    db/migrate/20130924151154_create_users.rb
      create    app/models/user.rb
      invoke    test_unit
      create      test/models/user_test.rb
      create      test/fixtures/users.yml
      invoke  resource_route
       route    resources :users
      invoke  scaffold_controller
      create    app/controllers/users_controller.rb
      invoke    erb
      create      app/views/users
      create      app/views/users/index.html.erb
      create      app/views/users/edit.html.erb
      create      app/views/users/show.html.erb
      create      app/views/users/new.html.erb
      create      app/views/users/_form.html.erb
      invoke    test_unit
      create      test/controllers/users_controller_test.rb
      invoke    helper
      create      app/helpers/users_helper.rb
      invoke    jbuilder
      create      app/views/users/index.json.jbuilder
      create      app/views/users/show.json.jbuilder
      invoke  test_unit
      create    test/application_system_test_case.rb
      create    test/system/users_test.rb
      invoke  assets
      invoke    coffee
      create      app/assets/javascripts/users.coffee
      invoke    scss
      create      app/assets/stylesheets/users.scss
      invoke  scss
      create    app/assets/stylesheets/scaffolds.scss

بالنظر إلى هذا الناتج، من السهل فهم كيفية عمل المولدات في الإصدار 3.0 وما بعد من ريلز. مولد السقالة scaffold لا يولد أي شيء في الواقع، إنه يستدعي الآخرين فقط للقيام بالعمل. هذا يسمح لنا بإضافة أو استبدال أو إزالة أي من تلك الإستدعاءات. على سبيل المثال، يستدعي المولد scaffold المولد scaffold_controller، الذي يستدعي المولدات erb و test_unit و helper. نظرًا لأن كل مولد لديه مسؤولية واحدة، فإنه من السهل إعادة استخدامه، مع تجنب تكرار الشيفرة.

إذا كنا نريد تجنب التوليد الافتراضي للملف app/assets/stylesheets/scaffolds.scss عند توليد مورد جديد عبر المولد scaffold، يمكننا تعطيل scaffold_stylesheet:

config.generators do |g|
  g.scaffold_stylesheet false
end

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

config.generators do |g|
  g.orm             :active_record
  g.template_engine :erb
  g.test_framework  :test_unit, fixture: false
  g.stylesheets     false
  g.javascripts     false
end

إذا قمنا بإنشاء مورد آخر عبر المولد scaffold، يمكننا ملاحظة أنه لن ينشئ أوراق الأنماط وشيفرة جافاسكريبت وملفات تحضيرات الاختبار بعد الآن. إذا كنت ترغب في تخصيصها بشكل أكبر، على سبيل المثال لاستخدام DataMapper و RSpec بدلًا من السجل الفعال و TestUnit، فإن الأمر يتعلق فقط بإضافة الجواهر الخاصة بهم إلى التطبيق الخاص بك وضبط المولدات الخاصة بك.

لإثبات ذلك، سننشئ مولدًا مساعدًا جديدًا يضيف ببساطة بعض متغيرات النسخة. أولًا، نُنشئ مولدًا داخل مجال الاسم rails، حيث أن هذا هو المكان الذي تبحث فيه ريلز عن المولدات المستخدمة كخطافات:

$ bin/rails generate generator rails/my_helper
      create  lib/generators/rails/my_helper
      create  lib/generators/rails/my_helper/my_helper_generator.rb
      create  lib/generators/rails/my_helper/USAGE
      create  lib/generators/rails/my_helper/templates
      invoke  test_unit
      create    test/lib/generators/rails/my_helper_generator_test.rb

بعد ذلك، يمكننا حذف كلٍّ من المجلد templates وتابع الصنف class_root الذي يستدعى من المولد الجديد، لأننا لن نحتاج إليهما. أضف التابع أدناه، لذلك يبدو مولدنا كما يلي:

# lib/generators/rails/my_helper/my_helper_generator.rb
class Rails::MyHelperGenerator < Rails::Generators::NamedBase
  def create_helper_file
    create_file "app/helpers/#{file_name}_helper.rb", <<-FILE
module #{class_name}Helper
  attr_reader :#{plural_name}, :#{plural_name.singularize}
end
    FILE
  end
end

يمكننا تجربة مولدنا الجديد عن طريق إنشاء مساعد للمنتجات:

$ bin/rails generate my_helper products
      create  app/helpers/products_helper.rb

وسوف تولد الملف المساعد التالي في app/helpers:

module ProductsHelper

 attr_reader :products, :product

End

وهو ما كنا نتوقعه. يمكننا الآن أن نخبر المولد scaffold أن يستخدم المولد المساعد الجديد الخاص بنا عن طريق تعديل الملف config/application.rb مرة أخرى بالشكل التالي:

config.generators do |g|
  g.orm             :active_record
  g.template_engine :erb
  g.test_framework  :test_unit, fixture: false
  g.stylesheets     false
  g.javascripts     false
  g.helper          :my_helper
end

ونرى ذلك في العمل عند استدعاء المولد:

$ bin/rails generate scaffold Article body:text
      [...]
      invoke    my_helper
      create      app/helpers/articles_helper.rb

من المخرجات التي حصلنا عليها، يمكننا ملاحظة أن مساعدنا الجديد استُدعِي بدلًا من مولد ريلز الافتراضي. ومع ذلك، هناك شيء واحد مفقود، وهو الاختبارات لمولدنا الجديد؛ ولتصحيح ذلك، سنعيد استخدام مولدات الاختبار القديمة.

منذ الإصدار 3.0 من ريلز، هذا من السهل القيام به بسبب مفهوم الخطافات. لا يحتاج المساعد الجديد الخاص بنا إلى التركيز في إطار اختبار واحد محدد، بل يمكن ببساطة توفير خطاف وإطار اختبار يحتاج فقط إلى تنفيذ هذا الخطاف من أجل التوافق.

للقيام بذلك، يمكننا تغيير المولد بهذه الطريقة:

# lib/generators/rails/my_helper/my_helper_generator.rb
class Rails::MyHelperGenerator < Rails::Generators::NamedBase
  def create_helper_file
    create_file "app/helpers/#{file_name}_helper.rb", <<-FILE
module #{class_name}Helper
  attr_reader :#{plural_name}, :#{plural_name.singularize}
end
    FILE
  end
 
  hook_for :test_framework
end

الآن، عندما يُستدعَى المولد المساعد وتُكون TestUnit كإطار اختبار، سيحاول استدعاء Rails::TestUnitGenerator و TestUnit::MyHelperGenerator كلاهما. نظرًا لأنه لم يُعرَّف أي منها، يمكننا أن نطلب من المولد الخاص بنا استدعاء TestUnit::Generators::HelperGenerator بدلًا من ذلك، إذ هو مُعرَّف لأنه مولد ريلز. للقيام بذلك، نحن بحاجة فقط إلى إضافة:

# :my_helper بدلًا من :helper ابحث عن
hook_for :test_framework, as: :helper

والآن يمكنك إعادة تشغيل المولد scaffold لمورد آخر للتأكد من توليده للاختبارات أيضًا!

تخصيص سير العمل الخاص بك عن طريق تغيير قوالب المولدات

في الخطوة أعلاه، أردنا ببساطة إضافة سطر إلى المساعد الذي اُنشأ، دون إضافة أي وظائف إضافية. هناك طريقة أبسط للقيام بذلك، ومن خلال استبدال قوالب المولدات الموجودة بالفعل، في تلك الحالة Rails::Generators::HelperGenerator.

في الإصدار 3.0 وما بعده من ريلز، لا تبحث المولدات فقط في المصدر الأصل عن القوالب، بل تبحث أيضًا عن القوالب في مسارات أخرى. واحد منهم هو lib/templates. بما أننا نريد تخصيص Rails::Generators::HelperGenerator، يمكننا القيام بذلك ببساطة عن طريق إنشاء نسخة القالب داخل lib/templates/rails/helper بالاسم helper.rb. لذلك دعنا ننشئ هذا الملف مع المحتوى التالي:

module <%= class_name %>Helper
  attr_reader :<%= plural_name %>, :<%= plural_name.singularize %>
end

والرجوع إلى آخر تغيير في config/application.rb:

config.generators do |g|
  g.orm             :active_record
  g.template_engine :erb
  g.test_framework  :test_unit, fixture: false
  g.stylesheets     false
  g.javascripts     false
end

إذا قمت بإنشاء مورد آخر، يمكنك أن ترى أننا نحصل على نفس النتيجة بالضبط! وهذا مفيد إذا كنت تريد تخصيص قوالب المولد scaffold و/أو تخطيطك من خلال إنشاء edit.html.erb و index.html.erb وما إلى ذلك داخل lib/templates/erb/scaffold.

تستخدم قوالب المولد scaffold في ريلز وسوم ERB بشكل متكرر؛ هذه الوسوم تحتاج إلى أن تُهرَّب بحيث يكون الناتج الذي أنشأه وسم ERB صالح.

على سبيل المثال، سيكون الوسم ERB المهرَّب التالي مطلوبًا في القالب (لاحظ الإشارة % الزائدة) ...

<%%= stylesheet_include_tag :application %>

... لتوليد الناتج التالي:

<%= stylesheet_include_tag :application %>

إضافة تراجعات للمولدات

ميزة واحدة أخيرة حول المولدات التي هي مفيدة جدًا لمولدات المكوّنات الإضافيّة. على سبيل المثال، تخيل أنك تريد إضافة ميزة أعلى TestUnit مثل shoulda. بما أن TestUnit ينفذ بالفعل جميع المولدات المطلوبة من قبل ريلز و shoulda يريد فقط استبدال جزء منه، فلا توجد حاجة إلى إعادة تشغيل بعض المولدات مرة أخرى، يمكن ببساطة أن تخبر ريلز باستخدام مولد TestUnit إذا لم يعثر على أي منها تحت مجال الاسم Shoulda.

يمكننا بسهولة محاكاة هذا السلوك عن طريق تغيير config/application.rb الخاص بنا مرة أخرى:

config.generators do |g|
  g.orm             :active_record
  g.template_engine :erb
  g.test_framework  :shoulda, fixture: false
  g.stylesheets     false
  g.javascripts     false
 
  # إضافة تراجع
  g.fallbacks[:shoulda] = :test_unit
end

الآن، إذا أنشئت Comment عبر المولد scaffold، سترى أنه تُستدعَى المولدات shoulda، ثم يرجع إلى المولدات TestUnit في النهاية:

$ bin/rails generate scaffold Comment body:text
      invoke  active_record
      create    db/migrate/20130924143118_create_comments.rb
      create    app/models/comment.rb
      invoke    shoulda
      create      test/models/comment_test.rb
      create      test/fixtures/comments.yml
      invoke  resource_route
       route    resources :comments
      invoke  scaffold_controller
      create    app/controllers/comments_controller.rb
      invoke    erb
      create      app/views/comments
      create      app/views/comments/index.html.erb
      create      app/views/comments/edit.html.erb
      create      app/views/comments/show.html.erb
      create      app/views/comments/new.html.erb
      create      app/views/comments/_form.html.erb
      invoke    shoulda
      create      test/controllers/comments_controller_test.rb
      invoke    my_helper
      create      app/helpers/comments_helper.rb
      invoke    jbuilder
      create      app/views/comments/index.json.jbuilder
      create      app/views/comments/show.json.jbuilder
      invoke  test_unit
      create    test/application_system_test_case.rb
      create    test/system/comments_test.rb
      invoke  assets
      invoke    coffee
      create      app/assets/javascripts/comments.coffee
      invoke    scss

تسمح التراجعات للمولدات الخاصة بك بتحمل مسؤولية واحدة، مما يزيد من إعادة استخدام الشيفرات ويقلل من مقدار التكرار.

قوالب التطبيق

الآن بعد أن رأيت كيف يمكن استخدام المولدات داخل أحد التطبيقات، هل تعلم أيضًا أنه يمكن استخدامها أيضًا لإنشاء التطبيقات؟ يشار إلى هذا النوع من المولد باسم "قالب" (template). هذه نظرة عامة موجزة عن الواجهة Templates البرمجية. للحصول على التوثيق التفصيلي، انظر دليل قوالب تطبيقات ريلز.

gem "rspec-rails", group: "test"
gem "cucumber-rails", group: "test"
 
if yes?("Would you like to install Devise?")
  gem "devise"
  generate "devise:install"
  model_name = ask("What would you like the user model to be called? [user]")
  model_name = "user" if model_name.blank?
  generate "devise", model_name
end

في النموذج أعلاه، نحدد أن التطبيق يعتمد على الجوهرة rspec-rails والجوهرة cucumber-rails لذلك يُضافان إلى المجموعة test في الملف Gemfile.

ثم نطرح سؤالًا على المستخدم حول ما إذا كان يرغب في تثبيت Devise أم لا. إذا رد المستخدم "y" أو "yes" على هذا السؤال، سيضيف القالب Devise إلى الملف Gemfile خارج أي مجموعة، ثم يُشغل المولد devise: install.

ثم يأخذ هذا القالب مدخلات المستخدمين ويُشغل المولد devise، مع إجابة المستخدم من السؤال الأخير الذي مُرر إلى هذا المولد.

تخيل أن هذا القالب كان في ملف يسمى template.rb. يمكننا استخدامه لتعديل نتائج الأمر rails new باستخدام الخيار ‎-m وتمريره في اسم الملف:

$ rails new thud -m template.rb

سيولد هذا الأمر التطبيق Thud، ثم يطبق القالب إلى الناتج المولد.

لا يجب تخزين القوالب على النظام المحلي، كما يدعم الخيار ‎-m أيضًا النماذج عبر الإنترنت:

$ rails new thud -m https://gist.github.com/radar/722911/raw/

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

إضافة وسائط سطر الأوامر

يمكن تعديل مولدات ريلز بسهولة لقبول وسائط سطر الأوامر المخصصة. هذه الوظيفة تأتي من Thor:

class_option :scope, type: :string, default: 'read_products'

الآن يمكن استدعاء المولد الخاص بنا على النحو التالي:

rails generate initializer --scope write_products

يمكن الوصول إلى وسائط سطر الأوامر من خلال التابع options داخل صنف المولد مثل:

@scope = options['scope']

توابع المولد

فيما يلي التوابع المتوفرة لكل من المولدات والقوالب الخاصة بريلز.

ملاحظة: لا يُغطي هذا الدليل التوابع التي يقدمها Thor ويمكن العثور عليها في توثيق Thor.

gem

يحدد تبعية الجوهرة للتطبيق.

gem "rspec", group: "test", version: "2.1.0"
gem "devise", "1.1.5"

الخيارات المتاحة هي:

• group:‎ - المجموعة في الملف Gemfile حيث يجب أن تذهب هذه الجوهرة.
• version:‎ - سلسلة إصدار الجوهرة التي تريد استخدامها. يمكن أيضًا تحديده كوسيطٍ ثانٍ للتابع.
• git:‎ - عنوان URL لمستودع git لهذه الجوهرة.

تُوضع أي خيارات إضافية مُررت إلى هذا التابع في نهاية السطر:

gem "devise", git: "https://github.com/plataformatec/devise.git", branch: "master"

ستضع الشيفرة السابقة السطر التالي في الملف Gemfile:

gem "devise", git: "https://github.com/plataformatec/devise.git", branch: "master"

gem_group

يغلف مدخلات الجوهرة داخل المجموعة:

gem_group :development, :test do
  gem "rspec-rails"
end

add_source

يضيف مصدرًا محددًا إلى الملف Gemfile:

add_source "http://gems.github.com"

هذا التابع يأخذ أيضا كتلة:

add_source "http://gems.github.com" do
  gem "rspec-rails"
end

inject_into_file

يحقن كتلة من التعليمات البرمجية في موضع محدد في ملفك.

inject_into_file 'name_of_file.rb', after: "#The code goes below this line. Don't forget the Line break at the end\n" do <<-'RUBY'
  puts "Hello World"
RUBY
end

gsub_file

يستبدل نصًّا داخل الملف.

gsub_file 'name_of_file.rb', 'method.to_be_replaced', 'method.the_replacing_code'

يمكن استخدام التعبيرات النمطية لجعل هذا التابع أكثر دقة. يمكنك أيضًا استخدام append_file و prepend_file بالطريقة نفسها لوضع الشفرة في بداية ونهاية الملف على التوالي.

application

يضيف سطرًا إلى config/application.rb مباشرةً بعد تعريف صنف التطبيق.

application "config.asset_host = 'http://example.com'"

يمكن أن يأخذ هذا التابع أيضًا كتلة:

application do
  "config.asset_host = 'http://example.com'"
end

الخيارات المتاحة هي:

• env:‎ - حدد بيئة لخيار التوصيف هذا. إذا كنت ترغب في استخدام هذا الخيار مع صياغة الكتلة، تكون الصياغة الموصى بها كما يلي:

application(nil, env: "development") do
  "config.asset_host = 'http://localhost:3000'"
end

git

يشغل الأمر git المحدد:

git :init
git add: "."
git commit: "-m First commit!"
git add: "onefile.rb", rm: "badfile.cxx"

تكون قيم الجدول Hash هنا هي الوسائط أو الخيارات التي مُررت إلى الأمر git المحدد. وفقًا للمثال النهائي الموضح هنا، يمكن تحديد عدة أوامر git في وقت واحد، ولكن لا يُضمن ترتيب تشغيلها بنفس الترتيب المحدد.

vendor

يضع ملفًا في vendor الذي يحتوي على الشيفرة المحددة.

vendor "sekrit.rb", '#top secret stuff'

هذا التابع يأخذ أيضا كتلة:

vendor "seeds.rb" do
  "puts 'in your app, seeding your database'"
end

lib

يضع ملفًا في lib يحتوي على الشيفرة المحددة.

lib "special.rb", "p Rails.root"

هذا التابع يأخذ أيضا كتلة:

lib "super_special.rb" do
  "puts 'Super special!'"
end

rakefile

ينشئ ملف Rake في دليل lib/tasks الخاص بالتطبيق.

rakefile "test.rake", 'task(:hello) { puts "Hello, there" }'

هذا التابع يأخذ أيضا كتلة:

rakefile "test.rake" do
  %Q{
    task rock: :environment do
      puts "Rockin'"
    end
  }
end

initializer

ينشئ مُهيئ في المجلد config/initializers للتطبيق:

initializer "begin.rb", "puts 'this is the beginning'"

يأخذ هذا التابع أيضًا كتلة، ويتوقع أن يعيد سلسلة نصية:

initializer "begin.rb" do
  "puts 'this is the beginning'"
end

generate

يشغِّل المولد المحدد حيث يكون الوسيط الأولى هو اسم المولد وتمرر الوسائط المتبقية مباشرة إلى المولد.

generate "scaffold", "forums title:string description:text"

rake

يشغل مهمة Rake محددة.

rake "db:migrate"

الخيارات المتاحة هي:

• env:‎  - يحدد البيئة التي ستشغل مهمة rake.
• sudo:‎ - يحدد تشغيل هذه المهمة باستخدام sudo أم لا. القيمة الافتراضية هي: false.

route

يضيف نصًا إلى الملف config/routes.rb:

route "resources :people"

readme

يطبع محتويات الملف في source_path للقالب، عادة ما يكون README.

readme "README"

مصادر

• صفحة Creating and Customizing Rails Generators & Templates في توثيق Ruby On Rails الرسمي.