Szukaj…


Uwagi

Jak działa Blueprint API?

Kiedy żagle początkowo zaczynają używać sails lift , żagle sprawdzają, czy masz zdefiniowany jakiś kontroler. W naszym przykładzie mamy jeden kontroler, kontroler użytkownika. Następnie żagle zapewniają dostęp do akcji planu dla tego kontrolera użytkownika, tak jakbyśmy sami wbudowali je w kontroler. Żagle automatycznie tworzą trasy planu w momencie podniesienia serwera. Więc nawet jeśli nie zdefiniowano żadnych tras w /config/routes.js i nie określono jawnie żadnej akcji w /api/controllers/UserController.js , po podniesieniu serwera wszystkie te trasy i akcje są dostępne.

Trasy Blueprint

Po uruchomieniu sails lift z włączonymi planami struktura sprawdza kontrolery, modele i konfigurację w celu automatycznego powiązania niektórych tras. Te niejawne trasy planu umożliwiają aplikacji odpowiadanie na niektóre żądania bez konieczności ręcznego wiązania tych tras w pliku config/routes.js . Domyślnie trasy planu wskazują na odpowiadające im akcje planu, z których każdą można zastąpić niestandardowym kodem.

W Żaglach istnieją trzy rodzaje tras do planu:

  • RESTful trasy , gdzie ścieżka jest zawsze /:model/:id? . Po zdefiniowaniu modelu User i kontrolera, plan domyślnie wiąże trasy RESTful w następujący sposób -
    'GET /user/:id?': {
      controller: 'User',
      action: 'find'
    },
    'POST /user': {
      controller: 'User',
      action: 'create'
    },
    'PUT /user/:id?': {
      controller: 'User',
      action: 'update'
    },
    'DELETE /user/:id?': {
      controller: 'User',
      action: 'destroy'
    }
    
    Te trasy używają czasownika HTTP do określenia akcji, która ma zostać podjęta, nawet jeśli trasa jest taka sama. Zatem żądanie POST do /user utworzy nowego użytkownika, żądanie PUT do /user/123 zaktualizuje użytkownika kluczem podstawowym 123, a żądanie DELETE do /user/123 usunie użytkownika, którego kluczem podstawowym jest 123. W w środowisku produkcyjnym trasy RESTful powinny być zasadniczo chronione przez zasady, aby uniknąć nieautoryzowanego dostępu.
  • Trasy skrótów , w których działanie jest zakodowane na ścieżce. W naszym modelu użytkownika i kontrolerze Sails wiąże domyślnie następujące cztery trasy skrótów.

    'GET /user/find/:id?': {
      controller: 'User',
      action: 'find'
    },
    'GET /user/create/:id?': {
      controller: 'User',
      action: 'create'
    },
    'GET /user/update/:id?': {
      controller: 'User',
      action: 'update'
    },
    'GET /user/destroy/:id?': {
      controller: 'User',
      action: 'destroy'
    }
    

    Na przykład skrót /user/create?name=joe tworzy nowego użytkownika, podczas gdy /user/update/1?name=mike aktualizuje pole nazwy użytkownika # 1. Pamiętaj, że te trasy odpowiadają tylko na żądania GET . Trasy skrótów są bardzo przydatne do programowania, ale ogólnie powinny być wyłączone w środowisku produkcyjnym. Nie jest przeznaczony do użytku w produkcji.

  • Trasy akcji , które automatycznie tworzą trasy dla niestandardowych akcji kontrolera. Na przykład, niech query będzie działaniem niestandardowym zdefiniowanym w Kontrolerze użytkownika. Wówczas następujące trasy byłyby domyślnie dostępne dla żagli -

    'GET /user/query/:id?': {
      controller: 'User',
      action: 'query'
    },
    'POST /user/query/:id?': {
      controller: 'User',
      action: 'query'
    },
    'PUT /user/query/:id?': {
      controller: 'User',
      action: 'query'
    },
    'DELETE /user/query/:id?': {
      controller: 'User',
      action: 'query'
    }
    

    Jeśli żądanie zostanie wykonane w /user/query/:id? trasa następnie niezależna od czasownika HTTP, działanie byłoby takie samo. W przeciwieństwie do RESTful i tras skrótów, trasy akcji nie wymagają, aby kontroler miał odpowiedni plik modelu. Co oznacza, że jeśli zdefiniujesz kontroler w pliku /api/controllers/FooController.js , ale nie ma modelu w pliku /api/models/Foo.js , nie będzie trasy RESTful ani skrótu w /foo ale nadal będą istniały trasy akcji Dostępne do użycia.

Kolejność dopasowywania tras

Kiedy nadejdzie żądanie, żagle najpierw dopasują trasę do wyraźnie określonych tras. Jeśli pasuje, to nie jest wykonywane dalsze dopasowanie i wykonywana jest odpowiednia akcja. Ale jeśli się nie zgadza, trasa jest najpierw dopasowywana do tras działania planu, jeśli nie pasuje, to do tras odpoczynku, a jeśli nie pasuje, to też trasy skrótów. Więc jeśli plik /config/routes.js ma jakieś wpisy, takie jak następujące-

  '/user/query/:id?': {
    controller: 'User',
    action: 'find'
  }

Wtedy nie można oczekiwać, że trasy akcji query zadziałają. Ponieważ ta sama trasa, co trasa query , zostanie dopasowana do jawnie zdefiniowanej trasy i zostanie wykonana akcja find kontrolera użytkownika.

Działania na planie

Działania na planie (nie należy mylić z trasami działań na planie) są czynnościami ogólnymi zaprojektowanymi do współpracy z dowolnym kontrolerem, który ma model o tej samej nazwie (np. ParrotController potrzebuje modelu Parrot ). Pomyśl o nich jako o domyślnym zachowaniu twojej aplikacji. Na przykład, jeśli masz model User.js i pusty kontroler UserController.js , find , create , update , destroy , populate , add i remove działania, które istnieją niejawnie, bez konieczności ich zapisywania.

Domyślnie trasy RESTful planu i trasy skrótów są powiązane z odpowiadającymi im działaniami planu. Jednak dowolną akcję planu można zastąpić dla konkretnego kontrolera, tworząc niestandardową akcję w tym pliku kontrolera (np. ParrotController.find ). Alternatywnie możesz zastąpić akcję planu w dowolnym miejscu w aplikacji , tworząc własną niestandardową akcję planu.

Żagle są dostarczane z następującymi działaniami planu:

  • odnaleźć
  • findOne
  • Stwórz
  • aktualizacja
  • zniszczyć
  • zaludniać
  • Dodaj
  • usunąć

Wyłączanie tras Blueprint

  • Podstawa globalna : konfiguracja interfejsu Blueprint API jest zdefiniowana w pliku /config/blueprint.js . Stamtąd możesz włączyć lub wyłączyć wszystkie trzy typy tras planu dla wszystkich kontrolerów. Na przykład, jeśli chcesz wyłączyć trasy skrótów do /config/blueprint.js dla wszystkich swoich kontrolerów, ale chcesz zachować włączone zarówno trasy akcji, jak i odpoczynku, wówczas /config/blueprint.js powinien wyglądać tak:

    module.exports.blueprints = {
      action: true,
      rest: true,
      shortcut: false
    }
    
  • Na kontrolerze : Możesz również przesłonić dowolne ustawienia z /config/blueprints.js dla poszczególnych kontrolerów, definiując klucz „_config” w definicji kontrolera i przypisując mu obiekt konfiguracyjny z nadpisaniami dla ustawień w tym pliku. Na przykład, jeśli chcesz, aby trasy skrótów były włączone tylko dla kontrolera użytkownika, ale nie dla innych kontrolerów, to przy powyższej konfiguracji planu musisz mieć następującą parę wartości klucza w kontrolerze użytkownika.

    module.exports = {
      _config: {
        actions: true,
        shortcuts: true,
        rest: true
      }
    }
    
    


Modified text is an extract of the original Stack Overflow Documentation
Licencjonowany na podstawie CC BY-SA 3.0
Nie związany z Stack Overflow