Ricerca…


Osservazioni

Come funziona l'API di Blueprint?

Quando le vele iniziano a usare le sails lift , le vele guardano per vedere se hai un controller definito. Nel nostro esempio, abbiamo un controller, il controller utente. Sails fornisce quindi l'accesso alle azioni blueprint per questo controller utente come se fossero state create direttamente nel controller. Anche le vele creano automaticamente percorsi di progetto al momento del sollevamento del server. Quindi, anche se in /config/routes.js non sono definiti /api/controllers/UserController.js , e in /api/controllers/UserController.js non viene definita alcuna azione esplicita, dopo aver /api/controllers/UserController.js il server tutte queste rotte e azioni sono disponibili per l'uso.

Percorsi Blueprint

Quando si esegue il sails lift con i modelli abilitati, il framework controlla i controller, i modelli e la configurazione per collegare automaticamente determinati percorsi. Questi percorsi impliciti del modello consentono alla tua app di rispondere a determinate richieste senza che tu debba vincolare manualmente tali percorsi nel tuo file config/routes.js . Per impostazione predefinita, i percorsi del modello puntano alle corrispondenti azioni del progetto, ognuna delle quali può essere sostituita con un codice personalizzato.

Ci sono tre tipi di rotte blueprint in Sails:

  • Percorsi RESTful , dove il percorso è sempre /:model/:id? . Quando il modello User e il controller sono definiti, il blueprint associa implicitamente le rotte RESTful nel seguente modo:
    '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'
    }
    
    Queste rotte utilizzano il verbo HTTP per determinare l'azione da eseguire anche se il percorso è lo stesso. Quindi, una richiesta POST a /user creerà un nuovo utente, una richiesta PUT a /user/123 aggiornerà l'utente con la chiave primaria 123 e una richiesta DELETE a /user/123 cancellerà l'utente la cui chiave primaria è 123. In un ambiente di produzione, le rotte RESTful dovrebbero generalmente essere protette da policy per evitare accessi non autorizzati.
  • Percorsi di scelta rapida , in cui l'azione da intraprendere è codificata nel percorso. Per il nostro modello di utente e controller, Sails associa implicitamente quattro percorsi di scelta rapida.

    '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'
    }
    

    Ad esempio, il collegamento /user/create?name=joe crea un nuovo utente, mentre /user/update/1?name=mike aggiorna il campo del nome dell'utente # 1. Nota che questi percorsi rispondono solo alle richieste GET . I percorsi di scelta rapida sono molto utili per lo sviluppo, ma in genere dovrebbero essere disabilitati in un ambiente di produzione. Non è progettato per essere utilizzato in produzione.

  • Percorsi di azione , che creano automaticamente percorsi per le azioni del controller personalizzato. Ad esempio, lascia che la query sia un'azione personalizzata definita nel controller utente. Quindi seguire le rotte sarebbe implicitamente disponibile per le vele -

    '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'
    }
    

    Se la richiesta è fatta in /user/query/:id? percorso quindi indipendente sul verbo HTTP l'azione sarebbe la stessa. A differenza dei percorsi RESTful e di scelta rapida, i percorsi di azione non richiedono che un controller abbia un file modello corrispondente. Il che significa che se si definisce un controller nel file /api/controllers/FooController.js ma nessun modello nel file /api/models/Foo.js , non ci sarebbe nessun RESTful o percorso di scorciatoia con /foo ma ci saranno comunque percorsi di azione disponibile per l'uso.

Ordine di percorsi corrispondenti

Quando arriva una richiesta, le vele corrisponderanno prima alla rotta contro rotte esplicitamente definite. Se corrisponde, non viene eseguita alcuna ulteriore corrispondenza e viene eseguita l'azione corrispondente. Ma se non corrisponde, la rotta viene confrontata in primo luogo con le rotte di azione del modello, se non corrisponde a quelle di riposo e se non corrisponde a quelle di collegamento. Quindi se il tuo file /config/routes.js ha qualche voce come la seguente-

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

Quindi non è possibile aspettarsi che i percorsi di azione della query funzionino. Poiché la stessa route del percorso di azione della query dovrebbe essere confrontata con le rotte di definizione esplicita e l'azione di find del controller utente verrà eseguita.

Azioni blueprint

Le azioni Blueprint (da non confondere con i percorsi di azione blueprint) sono azioni generiche progettate per funzionare con qualsiasi controller che ha un modello con lo stesso nome (ad esempio ParrotController avrebbe bisogno di un modello Parrot ). Pensa a loro come il comportamento predefinito per la tua applicazione. Ad esempio, se hai un modello User.js e un controller UserController.js vuoto, find , create , update , destroy , populate , add e remove azioni implicitamente, senza doverle scrivere.

Per impostazione predefinita, i percorsi RESTful e le rotte di scelta rapida di blueprint sono associati alle rispettive azioni blueprint corrispondenti. Tuttavia, qualsiasi azione di modello può essere sovrascritta per un particolare controller creando un'azione personalizzata in quel file di controller (ad es. ParrotController.find ). In alternativa, puoi sovrascrivere l'azione del modello ovunque nella tua app creando la tua azione personalizzata.

Sails viene fornito con le seguenti azioni blueprint:

  • trova
  • trova uno
  • creare
  • aggiornare
  • distruggere
  • popolare
  • Inserisci
  • rimuovere

Disabilitare rotte Blueprint

  • Base globale : la configurazione dell'API Blueprint è definita nel file /config/blueprint.js . Da qui puoi abilitare o disabilitare tutti e tre i tipi di rotte blueprint per tutti i controller. Ad esempio, se si desidera disabilitare i percorsi di scelta rapida del modello per tutti i controller, ma si desidera mantenere attive sia le rotte di azione che quelle di riposo, allora il tuo /config/blueprint.js dovrebbe essere come questo -

    module.exports.blueprints = {
      action: true,
      rest: true,
      shortcut: false
    }
    
  • In base al controller : è inoltre possibile sovrascrivere qualsiasi impostazione da /config/blueprints.js in base al controller definendo una chiave "_config" nella definizione del controller e assegnandole un oggetto di configurazione con le sostituzioni per le impostazioni in questo file. Ad esempio, se si desidera avere percorsi di scelta rapida abilitati solo per il controller utente ma non per altri controller, con la configurazione del modello di cui sopra è necessario avere la seguente coppia di valori chiave nel controller utente.

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


Modified text is an extract of the original Stack Overflow Documentation
Autorizzato sotto CC BY-SA 3.0
Non affiliato con Stack Overflow