Προσβασιμότητα στον Ιστό: Γιατί τα πρότυπα W3C συχνά αγνοούνται
Επιστήμη Δεδομένων Και Βάσεις Δεδομένων
Πίσω Μέρος
Ένας οδηγός για μηχανές σιδηροτροχιών στην άγρια φύση: Πραγματικός κόσμος Παραδείγματα κινητήρων σιδηροτροχιών σε δράση
Γιατί οι Κινητήρες Rails δεν χρησιμοποιούνται πιο συχνά; Δεν ξέρω την απάντηση, αλλά νομίζω ότι η γενίκευση του 'Όλα είναι μια μηχανή' έχει κρύψει τους προβληματικούς τομείς που μπορούν να βοηθήσουν στην επίλυση.
Το υπέροχο Τεκμηρίωση οδηγού ράγας για να ξεκινήσετε με το Rails Engines, αναφέρονται τέσσερα δημοφιλή παραδείγματα εφαρμογών Rails Engine: Forem, Devise, Spree και RefineryCMS. Αυτές είναι φανταστικές περιπτώσεις χρήσης πραγματικού κόσμου για κινητήρες που χρησιμοποιούν διαφορετική προσέγγιση για την ενσωμάτωση με μια εφαρμογή Rails.
Η εξέταση τμημάτων του τρόπου διαμόρφωσης και σύνθεσης αυτών των πολύτιμων λίθων θα δώσει προχωρημένους Προγραμματιστές Ruby on Rails πολύτιμες γνώσεις σχετικά με τα μοτίβα ή τις τεχνικές που δοκιμάζονται στο φυσικό περιβάλλον, οπότε όταν έρθει η ώρα, μπορείτε να έχετε μερικές επιπλέον επιλογές για να αξιολογήσετε.
Περιμένω να έχετε μια σύντομη εξοικείωση με τον τρόπο λειτουργίας ενός κινητήρα, οπότε αν αισθάνεστε ότι κάτι δεν είναι αρκετά προστιθέμενο, παρακαλούμε να διαβάσετε τον πιο εξαιρετικό οδηγό ράγας Ξεκινώντας με κινητήρες .
Χωρίς άλλη παραλλαγή, ας δούμε τον άγριο κόσμο των παραδειγμάτων μηχανών Rails!
πώς να δημιουργήσετε μια ιδέα
Πηγαίνω
Μια μηχανή για Rails που στοχεύει να είναι το καλύτερο μικρό σύστημα φόρουμ ποτέ
Αυτό το στολίδι ακολουθεί την κατεύθυνση του οδηγού σιδηροτροχιών για κινητήρες στο γράμμα. Είναι ένα αρκετά μεγάλο παράδειγμα και η διάβασή του θα σας δώσει μια ιδέα για το πόσο μακριά μπορείτε να επεκτείνετε τη βασική εγκατάσταση.
Είναι ένα πολύτιμο κόσμημα με έναν κινητήρα που χρησιμοποιεί μερικές τεχνικές για να ενσωματωθεί στην κύρια εφαρμογή.
module ::Forem class Engine Το ενδιαφέρον μέρος εδώ είναι το Decorators.register! μέθοδος τάξης, που εκτίθεται από το στολίδι Διακοσμητές. Ενσωματώνει τη φόρτωση αρχείων που δεν θα συμπεριληφθούν στη διαδικασία αυτόματης φόρτωσης Rails. Μπορεί να θυμάστε ότι χρησιμοποιώντας ρητά require Οι δηλώσεις καταστρέφουν την αυτόματη επαναφόρτωση σε λειτουργία ανάπτυξης, οπότε αυτή είναι μια σωτήρια ζωή! Θα είναι σαφέστερο να χρησιμοποιήσετε το παράδειγμα από τον Οδηγό για να δείξετε τι συμβαίνει:
config.to_prepare do Dir.glob(Rails.root + 'app/decorators/**/*_decorator*.rb').each do |c| require_dependency(c) end end Το μεγαλύτερο μέρος της μαγείας για τη διαμόρφωση του Forem συμβαίνει στον κορυφαίο ορισμό της κύριας μονάδας του Forem. Αυτό το αρχείο βασίζεται σε ένα user_class μεταβλητή που ορίζεται σε ένα αρχείο αρχικοποιητή:
Forem.user_class = 'User' Το επιτυγχάνετε χρησιμοποιώντας mattr_accessor αλλά όλα βρίσκονται στον οδηγό Rails, οπότε δεν θα το επαναλάβω εδώ. Με αυτό στη θέση του, το Forem στη συνέχεια διακοσμεί την κατηγορία χρηστών με όλα όσα χρειάζεται για να εκτελέσει την εφαρμογή της:
module Forem class <'Forem::Post', :foreign_key => 'user_id' # ... def forem_moderate_posts? Forem.moderate_first_post && !forem_approved_to_post? end alias_method :forem_needs_moderation?, :forem_moderate_posts? # ... Που αποδεικνύεται αρκετά! Έχω αποκοπεί η πλειοψηφία αλλά έχω αφήσει σε έναν ορισμό συσχέτισης, καθώς και μια μέθοδο εμφάνισης για να σας δείξω τον τύπο γραμμών που μπορείτε να βρείτε εκεί.
Η αναλαμπή ολόκληρου του αρχείου μπορεί να σας δείξει πόσο διαχειρίσιμη μεταφορά μέρους της εφαρμογής σας για επαναχρησιμοποίηση σε μια μηχανή.
Η διακόσμηση είναι το όνομα του παιχνιδιού στην προεπιλεγμένη χρήση του κινητήρα. Ως τελικός χρήστης του στολιδιού μπορείτε να παρακάμψετε το μοντέλο, την προβολή και τους ελεγκτές δημιουργώντας τις δικές σας εκδόσεις των τάξεων χρησιμοποιώντας συμβάσεις διαδρομής αρχείων και ονομάτων αρχείων που περιγράφονται στο στολίδι README. Υπάρχει όμως ένα κόστος που σχετίζεται με αυτήν την προσέγγιση, ειδικά όταν ο Κινητήρας αναβαθμιστεί σημαντικά - η συντήρηση του να διατηρείτε τις διακοσμήσεις σας σε λειτουργία μπορεί γρήγορα να ξεφύγει από το χέρι. Δεν αναφέρομαι εδώ στο Forem, πιστεύω ότι είναι σταθεροί στη διατήρηση μιας στενής πλέξης λειτουργικότητας, αλλά λάβετε υπόψη αυτό εάν δημιουργήσετε έναν κινητήρα και αποφασίσετε να κάνετε μια γενική επισκευή.
Ας ανακεφαλαιώσουμε αυτό: αυτό είναι το προεπιλεγμένο σχέδιο σχεδίασης κινητήρα Rails που βασίζεται σε τελικούς χρήστες που διακοσμούν προβολές, ελεγκτές και μοντέλα, μαζί με τη διαμόρφωση βασικών ρυθμίσεων μέσω αρχείων αρχικοποίησης. Αυτό λειτουργεί καλά για πολύ εστιασμένη και σχετική λειτουργικότητα.
Ρητό
Θα βρείτε μια μηχανή που μοιάζει πολύ με μια εφαρμογή Rails, με views, controllers και models καταλόγους. Το Devise είναι ένα καλό παράδειγμα εγκλεισμού μιας εφαρμογής και έκθεσης ενός βολικού σημείου ενοποίησης. Ας δούμε πώς ακριβώς λειτουργεί.
Θα αναγνωρίσετε αυτές τις γραμμές κώδικα εάν είστε προγραμματιστής Rails για περισσότερες από μερικές εβδομάδες:
class User Κάθε παράμετρος πέρασε στο devise Η μέθοδος αντιπροσωπεύει μια ενότητα εντός του Devise Engine. Υπάρχουν δέκα από αυτές τις ενότητες συνολικά που κληρονομούν από το γνωστό ActiveSupport::Concern. Αυτά επεκτείνουν το User τάξη επικαλούμενος το devise μέθοδο εντός του πεδίου εφαρμογής της.
Έχοντας αυτό το είδος σημείου ενοποίησης είναι πολύ ευέλικτο, μπορείτε να προσθέσετε ή να αφαιρέσετε οποιαδήποτε από αυτές τις παραμέτρους για να αλλάξετε το επίπεδο λειτουργικότητας που απαιτείται για την εκτέλεση της μηχανής. Σημαίνει επίσης ότι δεν χρειάζεται να κωδικοποιήσετε το μοντέλο που θα θέλατε να χρησιμοποιήσετε σε ένα αρχείο αρχικοποιητή, όπως προτείνεται από τον οδηγό Rails on Engines. Με άλλα λόγια, αυτό δεν είναι απαραίτητο:
Devise.user_model = 'User' Αυτή η αφαίρεση σημαίνει επίσης ότι μπορείτε να το εφαρμόσετε σε περισσότερα από ένα μοντέλα χρήστη στην ίδια εφαρμογή (για παράδειγμα | admin και user), ενώ η προσέγγιση του αρχείου διαμόρφωσης θα σας αφήσει να συνδεθείτε με ένα μόνο μοντέλο με έλεγχο ταυτότητας. Αυτό δεν είναι το μεγαλύτερο σημείο πώλησης, αλλά δείχνει έναν διαφορετικό τρόπο επίλυσης ενός προβλήματος.
Το Devise επεκτείνεται ActiveRecord::Base με τη δική του ενότητα που περιλαμβάνει το devise ορισμός μεθόδου:
γιατί χρησιμοποιείται ο κόμβος js
# lib/devise/orm/active_record.rb ActiveRecord::Base.extend Devise::Models Οποιαδήποτε τάξη κληρονομείται από ActiveRecord::Base θα έχει τώρα πρόσβαση στις μεθόδους κλάσης που ορίζονται στο Devise::Models:
#lib/devise/models.rb module Devise module Models # ... def devise(*modules) selected_modules = modules.map(&:to_sym).uniq # ... selected_modules.each do |m| mod = Devise::Models.const_get(m.to_s.classify) if mod.const_defined?('ClassMethods') class_mod = mod.const_get('ClassMethods') extend class_mod # ... end include mod end end # ... end end (Έχω αφαιρέσει πολύ κώδικα (# ...) για να επισημάνω τα σημαντικά μέρη.)
Παραφράζοντας τον κωδικό, για κάθε όνομα λειτουργικής μονάδας που μεταβιβάζεται στο devise μέθοδος είμαστε:
- φόρτωση της λειτουργικής μονάδας που καθορίσαμε ότι ζει κάτω από
Devise::Models (Devise::Models.const_get(m.to_s.classify) - επέκταση του
User τάξη με το ClassMethods ενότητα εάν έχει ένα - συμπεριλάβετε την καθορισμένη λειτουργική μονάδα (
include mod) για να προσθέσετε τις μεθόδους εμφάνισής της στην τάξη που καλεί το devise μέθοδος (User)
Εάν θέλετε να δημιουργήσετε μια ενότητα που θα μπορούσε να φορτωθεί με αυτόν τον τρόπο, θα πρέπει να βεβαιωθείτε ότι ακολουθεί το συνηθισμένο ActiveSupport::Concern διεπαφή, αλλά ονομάστε το κάτω από το Devise:Models καθώς αυτό είναι όπου κοιτάζουμε να ανακτήσουμε τη σταθερά:
module Devise module Models module Authenticatable extend ActiveSupport::Concern included do # ... end module ClassMethods # ... end end end end Φτου.
Εάν έχετε χρησιμοποιήσει στο παρελθόν τις ανησυχίες του Rails και έχετε βιώσει την επαναχρησιμοποίηση που προσφέρουν, τότε μπορείτε να εκτιμήσετε τις ωραίες αυτής της προσέγγισης. Με λίγα λόγια, η διάλυση της λειτουργικότητας καθιστά ευκολότερη τη δοκιμή αφαιρεθεί από μια ActiveRecord μοντέλο και έχει χαμηλότερο κόστος από το προεπιλεγμένο μοτίβο που χρησιμοποιείται από το Forem για την επέκταση της λειτουργικότητας.
Αυτό το μοτίβο συνίσταται στη διάσπαση της λειτουργικότητάς σας σε Rails Concerns και στην έκθεση ενός σημείου διαμόρφωσης για συμπερίληψη ή εξαίρεση αυτών εντός ενός δεδομένου πεδίου. Ένας κινητήρας που έχει δημιουργηθεί με αυτόν τον τρόπο είναι βολικός για τον τελικό χρήστη - συμβάλλοντας στην επιτυχία και τη δημοτικότητα του Devise. Και τώρα ξέρετε πώς να το κάνετε επίσης!
Γλέντι
Μια ολοκληρωμένη λύση ανοιχτού κώδικα ηλεκτρονικού εμπορίου για το Ruby on Rails
Ο Spree πέρασε από μια κολοσσιαία προσπάθεια να θέσει υπό έλεγχο τη μονολιθική εφαρμογή τους με τη μετάβαση στη χρήση κινητήρων. Ο σχεδιασμός της αρχιτεκτονικής με τον οποίο κυκλοφορεί τώρα είναι ένα στολίδι 'Spree' που περιέχει πολλούς πολύτιμους λίθους Engine.
Αυτές οι μηχανές δημιουργούν κατατμήσεις στη συμπεριφορά που μπορεί να συνηθίσετε να βλέπετε σε μια μονολιθική εφαρμογή ή να κατανέμονται σε διάφορες εφαρμογές:
- spree_api (RESTful API)
- spree_frontend (Στοιχεία που βλέπουν ο χρήστης)
- spree_backend (Περιοχή διαχειριστή)
- spree_cmd (Εργαλεία γραμμής εντολών)
- spree_core (Μοντέλα & Mailers, τα βασικά στοιχεία του Spree που δεν μπορεί να εκτελεστεί χωρίς)
- spree_sample (Δείγμα δεδομένων)
Τα πολύτιμα στολίδια τα συνδυάζουν μαζί αφήνοντας στον προγραμματιστή μια επιλογή στο επίπεδο λειτουργικότητας που απαιτείται. Για παράδειγμα, θα μπορούσατε να τρέξετε μόνο με το spree_core Μηχανήστε και τυλίξτε τη δική σας διεπαφή γύρω από αυτήν.
Το κύριο στολίδι Spree απαιτεί αυτούς τους κινητήρες:
# lib/spree.rb require 'spree_core' require 'spree_api' require 'spree_backend' require 'spree_frontend' Κάθε Κινητήρας πρέπει στη συνέχεια να προσαρμόσει το engine_name και root διαδρομή (το τελευταίο συνήθως δείχνει στο στολίδι ανώτερου επιπέδου) και να διαμορφώσουν τον εαυτό τους συνδέοντας τη διαδικασία προετοιμασίας:
# api/lib/spree/api/engine.rb require 'rails/engine' module Spree module Api class Engine :load_config_initializers do |app| app.config.spree = Spree::Core::Environment.new end # ... end end end Μπορεί ή όχι να αναγνωρίσετε αυτήν τη μέθοδο αρχικοποίησης: αποτελεί μέρος της Railtie και είναι ένα άγκιστρο που σας δίνει την ευκαιρία να προσθέσετε ή να αφαιρέσετε βήματα από την προετοιμασία του πλαισίου Rails. Το Spree βασίζεται σε αυτό το άγκιστρο σε μεγάλο βαθμό για να διαμορφώσει το περίπλοκο περιβάλλον του για όλους τους κινητήρες του.
Χρησιμοποιώντας το παραπάνω παράδειγμα κατά το χρόνο εκτέλεσης, θα έχετε πρόσβαση στις ρυθμίσεις σας μεταβαίνοντας στο ανώτερο επίπεδο Rails συνεχής:
c++ .o file
Rails.application.config.spree Με αυτόν τον οδηγό μοτίβου σχεδίασης κινητήρα Rails παραπάνω θα μπορούσαμε να το ονομάσουμε καθημερινά, αλλά ο Spree έχει έναν τόνο εκπληκτικού κώδικα, οπότε ας δούμε πώς χρησιμοποιούν την αρχικοποίηση για να μοιραστούν τη διαμόρφωση μεταξύ Engines και της κύριας εφαρμογής Rails.
Το Spree έχει ένα σύνθετο σύστημα προτιμήσεων που φορτώνει προσθέτοντας ένα βήμα στη διαδικασία προετοιμασίας:
# api/lib/spree/api/engine.rb initializer 'spree.environment', :before => :load_config_initializers do |app| app.config.spree = Spree::Core::Environment.new end Εδώ, συνδέουμε με app.config.spree ένα νέο Spree::Core::Environment παράδειγμα. Μέσα στην εφαρμογή ράγες θα έχετε πρόσβαση σε αυτό μέσω Rails.application.config.spree από οπουδήποτε - μοντέλα, ελεγκτές, προβολές.
Προχωρώντας προς τα κάτω, το Spree::Core::Environment τάξη που δημιουργούμε μοιάζει με αυτό:
module Spree module Core class Environment attr_accessor :preferences def initialize @preferences = Spree::AppConfiguration.new end end end end Εκθέτει ένα :preferences μεταβλητή ορίστηκε σε μια νέα παρουσία του Spree::AppConfiguration τάξη, η οποία με τη σειρά της χρησιμοποιεί ένα preference μέθοδος που ορίζεται στο Preferences::Configuration class για να ορίσετε επιλογές με προεπιλογές για τη γενική διαμόρφωση της εφαρμογής:
module Spree class AppConfiguration Δεν θα δείξω το Preferences::Configuration αρχειοθετήστε γιατί θα χρειαστεί λίγη εξήγηση, αλλά ουσιαστικά είναι συντακτική ζάχαρη για λήψη και ρύθμιση προτιμήσεων. (Στην πραγματικότητα, πρόκειται για υπεραπλούστευση της λειτουργικότητάς του, καθώς το σύστημα προτιμήσεων θα αποθηκεύει άλλες εκτός από τις προεπιλεγμένες τιμές για υπάρχουσες ή νέες προτιμήσεις στη βάση δεδομένων, για οποιαδήποτε κλάση ActiveRecord με στήλη :preference αλλά δεν χρειάζεται να το ξέρετε αυτό.)
Εδώ είναι μία από αυτές τις επιλογές σε δράση:
module Spree class Calculator Οι αριθμομηχανές ελέγχουν κάθε είδους πράγματα στο Spree - έξοδα αποστολής, προσφορές, προσαρμογές τιμών προϊόντος - οπότε έχοντας έναν μηχανισμό για την ανταλλαγή τους με αυτόν τον τρόπο αυξάνεται η επεκτασιμότητα του κινητήρα.
Ένας από τους πολλούς τρόπους με τους οποίους μπορείτε να παρακάμψετε τις προεπιλεγμένες ρυθμίσεις για αυτές τις προτιμήσεις είναι ένας αρχικοποιητής στην κύρια εφαρμογή Rails:
# config/initializergs/spree.rb Spree::Config do |config| config.admin_interface_logo = 'company_logo.png' end Εάν έχετε διαβάσει το RailsGuide για κινητήρες , λαμβάνοντας υπόψη τα μοτίβα σχεδίασής τους ή έχετε δημιουργήσει μόνοι σας έναν κινητήρα, θα γνωρίζετε ότι είναι ασήμαντο να εκθέτετε ένα ρυθμιστικό σε ένα αρχείο αρχικοποιητή για να το χρησιμοποιήσει κάποιος. Ίσως να αναρωτιέστε, γιατί όλη η αναστάτωση με το σύστημα ρύθμισης και προτιμήσεων; Θυμηθείτε, το σύστημα προτιμήσεων επιλύει ένα πρόβλημα τομέα για το Spree. Η συμμετοχή στη διαδικασία προετοιμασίας και η πρόσβαση στο πλαίσιο Rails θα μπορούσε να σας βοηθήσει να ικανοποιήσετε τις απαιτήσεις σας με διατηρήσιμο τρόπο.
πώς γράφεις κώδικα
Αυτό το μοτίβο σχεδιασμού κινητήρα εστιάζεται στη χρήση του πλαισίου Rails ως σταθερά μεταξύ των πολλών κινούμενων μερών του για την αποθήκευση ρυθμίσεων που (γενικά) δεν αλλάζουν κατά το χρόνο εκτέλεσης, αλλά αλλάζουν μεταξύ των εγκαταστάσεων εφαρμογών.
Εάν έχετε προσπαθήσει ποτέ λευκή ταμπέλα μια εφαρμογή Rails, μπορεί να είστε εξοικειωμένοι με αυτό το σενάριο προτιμήσεων, και έχετε αισθανθεί τον πόνο των περίπλοκων πινάκων «ρυθμίσεων» της βάσης δεδομένων σε μια μακρά διαδικασία εγκατάστασης για κάθε νέα εφαρμογή. Τώρα ξέρετε ότι υπάρχει διαφορετική διαδρομή και είναι καταπληκτική - υψηλά πέντε!
Διυλιστήριο CMS
Ένα σύστημα διαχείρισης περιεχομένου ανοιχτού κώδικα για Rails
Σύμβαση για τη διαμόρφωση κανενός; Οι μηχανές Rails μπορούν σίγουρα να μοιάζουν περισσότερο με μια άσκηση διαμόρφωσης κατά καιρούς, αλλά το RefineryCMS θυμάται μερικά από αυτά τα μαγικά Rails. Αυτό είναι όλο το περιεχόμενο του lib Ευρετήριο:
# lib/refinerycms.rb require 'refinery/all' # lib/refinery/all.rb %w(core authentication dashboard images resources pages).each do |extension| require 'refinerycms-#{extension}' end Ουάου. Εάν δεν μπορείτε να το καταλάβετε, η ομάδα του διυλιστηρίου γνωρίζει πραγματικά τι κάνουν. Κυλούν με την έννοια ενός extension που είναι στην ουσία ένας άλλος κινητήρας. Όπως το Spree, διαθέτει ένα πολύτιμο στολίδι, αλλά χρησιμοποιεί μόνο δύο ράμματα και συγκεντρώνει μια συλλογή κινητήρων για να προσφέρει το πλήρες σύνολο λειτουργιών.
Οι επεκτάσεις δημιουργούνται επίσης από τους χρήστες του Engine, για να δημιουργήσουν τις δικές τους λειτουργίες CMS για blogging, ειδήσεις, χαρτοφυλάκια, μαρτυρίες, ερωτήσεις κ.λπ. (είναι μια μεγάλη λίστα), όλα συνδέονται με τον πυρήνα του RefineryCMS.
Αυτός ο σχεδιασμός μπορεί να τραβήξει την προσοχή σας για την αρθρωτή προσέγγισή του και το διυλιστήριο είναι ένα εξαιρετικό παράδειγμα αυτού του σχεδίου σχεδίασης Rails. 'Πώς λειτουργεί?' Σε ακούω να ρωτάς.
Το core ο κινητήρας χαρτογραφεί μερικά άγκιστρα για να χρησιμοποιούν οι άλλοι κινητήρες:
# core/lib/refinery/engine.rb module Refinery module Engine def after_inclusion(&block) if block && block.respond_to?(:call) after_inclusion_procs << block else raise 'Anything added to be called after_inclusion must be callable (respond to #call).' end end def before_inclusion(&block) if block && block.respond_to?(:call) before_inclusion_procs << block else raise 'Anything added to be called before_inclusion must be callable (respond to #call).' end end private def after_inclusion_procs @@after_inclusion_procs ||= [] end def before_inclusion_procs @@before_inclusion_procs ||= [] end end end Όπως μπορείτε να δείτε το before_inclusion και after_inclusion απλώς αποθηκεύστε μια λίστα με διαδικασίες που θα εκτελεστούν αργότερα. Η διαδικασία συμπερίληψης διυλιστηρίων επεκτείνει τις τρέχουσες εφαρμογές Rails με τους ελεγκτές και τους βοηθούς του διυλιστηρίου. Εδώ είναι ένα σε δράση:
# authentication/lib/refinery/authentication/engine.rb before_inclusion do [Refinery::AdminController, ::ApplicationController].each do |c| Refinery.include_once(c, Refinery::AuthenticatedSystem) end end Είμαι βέβαιος ότι έχετε τοποθετήσει μεθόδους ελέγχου ταυτότητας στο ApplicationController και AdminController πριν, αυτός είναι ένας προγραμματικός τρόπος να το κάνουμε.
Πώς να προσθέσετε το api στο wordpress
Κοιτάζοντας το υπόλοιπο αυτού του αρχείου Authentication Engine θα μας βοηθήσει να συγκεντρώσουμε μερικά άλλα βασικά στοιχεία:
module Refinery module Authentication class Engine <::Rails::Engine extend Refinery::Engine isolate_namespace Refinery engine_name :refinery_authentication config.autoload_paths += %W( #{config.root}/lib ) initializer 'register refinery_user plugin' do Refinery::Plugin.register do |plugin| plugin.pathname = root plugin.name = 'refinery_users' plugin.menu_match = %r{refinery/users$} plugin.url = proc { Refinery::Core::Engine.routes.url_helpers.admin_users_path } end end end config.after_initialize do Refinery.register_extension(Refinery::Authentication) end # ... end end Κάτω από την κουκούλα, οι επεκτάσεις διυλιστηρίου χρησιμοποιούν ένα Plugin Σύστημα. Το initializer το βήμα θα φαίνεται οικείο από την ανάλυση κώδικα Spree, εδώ μόλις συναντήσαμε το register απαιτήσεις μεθόδων που πρέπει να προστεθούν στη λίστα Refinery::Plugins ότι το core Η επέκταση παρακολουθεί και το Refinery.register_extension προσθέτει απλώς το όνομα της ενότητας σε μια λίστα που είναι αποθηκευμένη σε έναν βοηθητή κλάσης.
Εδώ είναι ένα σοκαριστικό: το Refinery::Authentication Η τάξη είναι πραγματικά ένα περιτύλιγμα γύρω από το Devise, με κάποια προσαρμογή. Έτσι είναι οι χελώνες μέχρι κάτω!
Οι επεκτάσεις και τα πρόσθετα είναι έννοιες που έχει αναπτυχθεί από το Refinery για να υποστηρίξει το πλούσιο οικοσύστημα των εφαρμογών και των εργαλείων mini-rails - think rake generate refinery:engine. Το μοτίβο σχεδίασης διαφέρει από το Spree επιβάλλοντας ένα επιπλέον API γύρω από το Rails Engine για να βοηθήσει στη διαχείριση της σύνθεσής τους.
Το ιδίωμα του 'The Rails Way' βρίσκεται στον πυρήνα του διυλιστηρίου, το οποίο υπάρχει όλο και περισσότερο στις εφαρμογές mini-rails, αλλά από έξω δεν θα το ξέρετε αυτό. Ο σχεδιασμός ορίων σε επίπεδο σύνθεσης εφαρμογών είναι εξίσου σημαντικός, πιθανότατα περισσότερο από το να δημιουργήσετε ένα καθαρό API για τις τάξεις και τις ενότητες που χρησιμοποιούνται στις εφαρμογές Rails.
Η αναδίπλωση κώδικα που δεν έχετε άμεσο έλεγχο είναι ένα συνηθισμένο μοτίβο, είναι μια πρόβλεψη για τη μείωση του χρόνου συντήρησης για το πότε αυτός ο κώδικας αλλάζει, περιορίζοντας τον αριθμό των θέσεων που θα χρειαστεί να κάνετε τροποποιήσεις για την υποστήριξη αναβαθμίσεων. Η εφαρμογή αυτής της τεχνικής παράλληλα με τη λειτουργικότητα διαμερισμάτων δημιουργεί μια ευέλικτη πλατφόρμα σύνθεσης και εδώ είναι ένα πραγματικό παράδειγμα που κάθεται ακριβώς κάτω από τη μύτη σας - πρέπει να αγαπάτε τον ανοιχτό κώδικα!
συμπέρασμα
Έχουμε δει τέσσερις προσεγγίσεις για το σχεδιασμό μοτίβων μηχανών Rails, αναλύοντας δημοφιλείς πολύτιμους λίθους που χρησιμοποιούνται σε πραγματικές εφαρμογές. Αξίζει να διαβάσετε τα αποθετήρια τους για να μάθετε από μια πληθώρα εμπειριών που έχουν ήδη εφαρμοστεί και επαναληφθεί. Σταθείτε στους ώμους των γιγάντων.
Σε αυτόν τον οδηγό Rails, εστιάσαμε στα σχέδια και τις τεχνικές σχεδίασης για την ενσωμάτωση των Rails Engines και των εφαρμογών Rails των τελικών χρηστών τους, ώστε να μπορείτε να προσθέσετε τις γνώσεις αυτών στις Ζώνη εργαλείων ράγας .
Ελπίζω να έχετε μάθει τόσο πολύ από την αναθεώρηση αυτού του κώδικα και να αισθάνεστε εμπνευσμένοι για να δώσετε στους Rails Engines μια ευκαιρία όταν ταιριάζουν στο λογαριασμό. Ένα μεγάλο ευχαριστώ στους συντηρητές και τους συντελεστές των πολύτιμων λίθων που εξετάσαμε. Πολύ καλή δουλειά!
Σχετίζεται με: Timestamp Truncation: A Ruby on Rails ActiveRecord Tale
