2015-01-27 11 views
6

Sto ancora imparando molto su come FBP e NoFlo funzionano da un punto di vista del processo, quindi mentre posso hackerare qualcosa insieme che fa il lavoro, non sono sicuro se introdurre problemi da qualche altra parte.Quali di questi approcci dovrebbero essere utilizzati per attendere l'input su tutte le porte prima di inviare i pacchetti?

In questo caso, sto creando un componente che attende un input su ciascuna delle sue 2 porte prima di inviare i dati alla porta di uscita. Perché? Ho bisogno di dati da entrambi gli input per costruire il pacchetto di output (nome del gruppo e pacchetto di input).

Sono riuscito a ottenere questo utilizzando 2 approcci e mi piacerebbe sapere quale approccio è migliore, o almeno i lati su/giù per ciascun approccio.

La componente di cui sto parlando qui è vizicities/Gruppo:

enter image description here

Approccio 1: Accodamento pacchetti dalla input1 internamente fino a quando l'input2 ha ricevuto un pacchetto

var noflo = require("noflo"); 

exports.getComponent = function() { 
    var AddGroup = new noflo.Component(); 
    AddGroup.description = "This component adds a group to the data packets"; 

    var packets = []; 
    var groupName = ""; 

    // Register ports and event handlers 
    AddGroup.inPorts.add("in", { datatype: "all" }, function(event, payload) { 
    switch (event) { 
     case "begingroup": 
     AddGroup.outPorts.out.beginGroup(payload); 
     break; 
     case "endgroup": 
     AddGroup.outPorts.out.endGroup(); 
     break; 
     case "data": 
     // Queue packet 
     packets.push(payload); 
     break; 
     case "disconnect": 
     // Only send output if group has been set 
     if (groupName) { 
      for (var i = 0; i < packets.length; i++) { 
      AddGroup.outPorts.out.beginGroup(groupName); 
      AddGroup.outPorts.out.send(packets); 
      AddGroup.outPorts.out.endGroup(); 
      } 

      // Disconnect output port when input port disconnects 
      AddGroup.outPorts.out.disconnect(); 
     } 
     break; 
    } 
    }); 

    AddGroup.inPorts.add("group", { datatype: "string" }, function(event, payload) { 
    switch (event) { 
     case "begingroup": 
     break; 
     case "endgroup": 
     break; 
     case "data": 
     groupName = payload; 
     break; 
     case "disconnect": 
     // TODO: Does this dupe anything with the same logic on the in port? 
     // Only send output if group has been set 
     if (groupName) { 
      for (var i = 0; i < packets.length; i++) { 
      AddGroup.outPorts.out.beginGroup(groupName); 
      AddGroup.outPorts.out.send(packets); 
      AddGroup.outPorts.out.endGroup(); 
      } 

      // Disconnect output port when input port disconnects 
      AddGroup.outPorts.out.disconnect(); 
     } 
     break; 
    } 
    }); 

    AddGroup.outPorts.add("out", { datatype: "all" }); 

    return AddGroup; // Return new instance 
}; 

Approccio 2: utilizzo dell'helper WirePattern

Entrambi gli approcci sembrano funzionare, anche se chiaramente ci deve essere un motivo per utilizzare l'uno sull'altro. Qualcuno può chiarire questo per me?

risposta

3

WirePattern è il metodo consigliato nel moderno NoFlo, poiché fornisce un ulteriore controllo sulla sincronizzazione dei pacchetti quando necessario. È possibile eseguire il fuoco quando tutti gli input richiesti ottengono i dati oppure è possibile richiedere un gruppo rigoroso (o anche un payload del pacchetto).

Un sacco di componenti NoFlo comuni sono ancora in attesa di WirePattern-ization, ma per qualcosa di nuovo, e ancora di più per qualsiasi cosa asincrona, è il modo consigliato.

+0

Grazie Henri, questo chiarisce le cose! La versione di WirePattern è molto più pulita, quindi ho preferito questo approccio. Al momento sto capendo la differenza tra in-ports e params, ma tutto funziona almeno. –

+0

Le porte dei parametri vengono utilizzate per la configurazione di un componente. Se li imposti a 'required', devono essere forniti una volta prima che il tuo WirePattern si accenda, ma dopo di ciò i valori vengono mantenuti in' c.params. '. Le porte dei parametri opzionali non bloccano l'esecuzione di WirePattern e pertanto potrebbero avere o meno valori in base alla modalità di creazione del grafico. – bergie

Problemi correlati