إنشاء وتخصيص مولدات وقوالب ريلز

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

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

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

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

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

$ rails new myapp

$ cd myapp

$ bin/rails generate

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

$ bin/rails generate helper --help

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

منذ Rails 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 لتطبيق Rails، فستشعر وكأنك في المنزل باستخدام واجهة برمجة التطبيقات للمولدات الجديدة.

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

$ bin/rails generate initializer

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

$ bin/rails generate initializer --help

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

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 بالمحتوى التالي:

<nowiki>#</nowiki> 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 هذه الملفات بدورها حتى تعثر على أحدها:

rails/generators/initializer/initializer_generator.rb

generators/initializer/initializer_generator.rb

rails/generators/initializer_generator.rb

generators/initializer_generator.rb

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

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

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

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

config.generators do |g|

 g.orm             :active_record

 g.template_engine :erb

 g.test_framework  :test_unit, fixture: true

End

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

$ 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

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

إذا كنا نريد تجنب التوليد الافتراضي لملف app/assets/stylesheets/scaffolds.scss عند سقالة مورد جديد يمكننا تعطيل 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

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

لإثبات ذلك، سننشئ مولد مساعد جديد هذا ببساطة يضيف بعض نُسخ متغيرات القُراء.  أولاً، نُنشئ مولد داخل مساحة اسم rails، حيث أن هذا هو المكان الذي تبحث فيه 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 من المولد الجديد، لأننا لن نحتاج إليهم. أضف التابع أدناه، لذلك يبدو مولدنا كما يلي:

<nowiki>#</nowiki> 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

وهو ما كنا نتوقعه. يمكننا الآن أن نقول للسقالة ان تستخدم مولد المساعد الجديد الخاص بنا عن طريق تحرير 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

يمكننا ملاحظة الإخراج الذي استدعى مساعدنا الجديد بدلاً من الافتراضي Rails. ومع ذلك، هناك شيء واحد مفقود، وهو اختبارات لمولدنا الجديد ولعمل ذلك، سنعيد استخدام مولدات الاختبار القديمة.

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

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

<nowiki>#</nowiki> 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 بدلاً من ذلك، والذي يُعرف لأنه منشئ Rails. للقيام بذلك، نحن بحاجة فقط إلى إضافة:

<nowiki>#</nowiki> Search for :helper instead of :my_helper

hook_for :test_framework, as: :helper

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

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

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

في Rails 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

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

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

على سبيل المثال، ستكون علامة ERB الآجلة التالية مطلوبة في القالب (لاحظ النسبة الزائدة٪) …

<%%= stylesheet_include_tag :application %>

... لتوليد الإخراج التالي:

<%= stylesheet_include_tag :application %>

إضافة المولدات الاحتياطية

ميزة واحدة أخيرة حول المولدات التي هي مفيدة جدا لمولدات المكوّنات الإضافيّة. على سبيل المثال، تخيل أنك تريد إضافة ميزة أعلى TestUnit مثل shoulda. بما أن TestUnit ينفذ بالفعل جميع المولدات المطلوبة من قبل Rails و shoulda يريد فقط استبدال جزء منه، فلا توجد حاجة إلى إعادة تشغيل بعض المولدات مرة أخرى، يمكن ببساطة أن تخبر Rails لاستخدام مولد 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

 # Add a fallback!

 g.fallbacks[:shoulda] = :test_unit

End

الآن، إذا أنشئت سقالة تعليق، سترى أنه يُستدعى مولدات 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

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

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

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

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 <nowiki>https://gist.github.com/radar/722911/raw/</nowiki>

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

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

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

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

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

rails generate initializer --scope write_products

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

@scope = options['scope']

توابع المولد

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

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

الجوهرة

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

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

gem "devise", "1.1.5"

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

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

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

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

سيضع الكود السابق السطر التالي في Gemfile:

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

Gem_group

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

gem_group :development, :test do

 gem "rspec-rails"

End

Add_source

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

add_source "<nowiki>http://gems.github.com</nowiki>"

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

add_source "<nowiki>http://gems.github.com</nowiki>" 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 ===
يستبدل النص داخل الملف.
<syntaxhighlight lang="rails">
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 = '<nowiki>http://example.com'</nowiki>"

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

application do

 "config.asset_host = '<nowiki>http://example.com'</nowiki>"

end

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

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

application(nil, env: "development") do

 "config.asset_host = '<nowiki>http://localhost:3000'</nowiki>"

End

Git

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

git :init

git add: "."

git commit: "-m First commit!"

git add: "onefile.rb", rm: "badfile.cxx"

تكون قيم التجزئة هنا هي الوسيطات أو الخيارات التي مُررت إلى أمر 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 الرسمي.