Les vérifications de connexion limitent les connexions (et donc les blocs) qui peuvent se connecter les uns aux autres.
Les vérifications de connexion sont utiles pour les types de modélisation. Par exemple : trois blocs n'ont pas d'activité connectée, car ils représentent du code qui renvoie différents types:
Les vérifications de connexion peuvent être utilisées pour empêcher ces blocs de se connecter. Ce donne aux utilisateurs des commentaires instantanés et évite de nombreuses erreurs simples.
Fonctionnement
Chaque connexion peut être associée à une "vérification de connexion" qui peut avoir une valeur nulle de chaînes.
Deux connexions peuvent se connecter si:
- Ce sont des types compatibles (par exemple, une sortie connectée une entrée).
- Ils ont au moins une chaîne en commun dans leur vérification de connexion.
Par exemple, les deux vérifications suivantes peuvent être connectées, car elles partagent le
Chaîne 'apple':
['apple', 'ball', 'cat']
['apple', 'bear', 'caterpillar']
Toutefois, ces deux vérifications n'ont pas pu se connecter, car elles ne partagent aucune chaîne:
['apple', 'ball', 'cat']
['ape', 'bear', 'caterpillar']
Il existe un autre cas particulier. Si l'un des tableaux est null, alors les deux
connexions peuvent
également se connecter. Cela vous permet de définir des connexions
à n'importe quoi.
null
['ape', 'bear', 'caterpillar]
Définir des vérifications
Par défaut, une vérification de connexion null est appliquée à toutes les connexions, ce qui signifie qu'elles peuvent
se connecter à n'importe quoi. Les vérifications de connexion doivent être attribuées manuellement.
La manière dont vous attribuez ces vérifications aux connexions varie selon que vous utilisiez des définitions de blocs JSON ou des définitions de blocs JavaScript.
JSON
Pour les connexions de niveau supérieur, vous attribuez le test directement à la propriété
définit la connexion. La valeur que vous attribuez peut être null, une chaîne (qui
devient la seule entrée du contrôle de connexion), ou un tableau de chaînes.
{
'type': 'custom_block',
'output': null,
'nextStatement': 'a connection check entry',
'previousStatement': ['four', 'connection', 'check', 'entries']
}
Pour les entrées, vous pouvez attribuer la vérification à une propriété check de l'entrée
définition. Si la propriété check n'existe pas, la vérification est considérée comme
null La valeur que vous attribuez peut être une chaîne ou un tableau de chaînes.
{
'type': 'custom_block',
'message0': '%1 %2',
'args0': [
{
'type': 'input_value',
'check': 'a connection check entry'
},
{
'type': 'input_statement',
'check': ['four', 'connection', 'check', 'entries']
}
]
}
JavaScript
Pour les connexions de niveau supérieur, vous pouvez transmettre la vérification directement à la méthode
définit la connexion. Si vous échouez, la vérification est considérée comme
null La valeur que vous transmettez peut être une chaîne (qui devient la seule entrée du champ
vérification de connexion) ou un tableau de chaînes.
Blockly.Blocks['custom_block'] = {
init: function() {
this.setOutput(true); // null check
this.setNextStatement(true, 'a connection check entry');
this.setPreviousStatement(true, ['four', 'connection', 'check', 'entries']);
}
}
Pour les entrées, vous pouvez transmettre la vérification à la méthode setCheck après avoir
défini l'entrée. Si la méthode setCheck n'est pas appelée, la vérification est
considéré comme null. La valeur que vous transmettez peut être une chaîne ou un tableau de chaînes.
Blockly.Blocks['custom_block'] = {
init: function() {
this.appendValueInput('NAME')
.setCheck('a connection check entry');
this.appendStatementInput('NAME')
.setCheck(['four', 'connection', 'check', 'entries']);
}
}
Chaînes de vérification intégrées
Les blocs intégrés ont des vérifications de connexion avec les valeurs 'Array',
'Boolean', 'Colour', 'Number' et 'String'. Si vous souhaitez que vos blocages
avec les blocs intégrés, vous pouvez utiliser ces valeurs pour les rendre
compatibles.
Exemples de valeurs
Lorsque vous définissez des vérifications des connexions pour les entrées et les sorties, vous devriez considérer les vérifications comme représentant des types.
Entrées les vérifications doivent inclure chaque « type » qu'ils acceptent, et génère vérifications doit inclure exactement ce qu'il "renvoie".
Accepter un seul type
Dans le cas le plus basique, où vous souhaitez créer un bloc qui "accepte" ou "retours" un type, vous devez l'inclure dans la vérification de la connexion de la connexion.
Accepter plusieurs types
Pour créer un bloc qui "accepte" plusieurs types, vous devez inclure tous les type accepté lors de la vérification de la connexion de l'entrée.
Par convention, si une sortie peut parfois être acceptée dans plusieurs situations (par exemple, si vous autorisez parfois l'utilisation de nombres sous forme de chaînes), la sortie doit être plus restrictifs, et les entrées doivent être plus permissives. Cette convention garantit que les sorties ne se connectent pas là où elles ne sont pas prises en charge.
Accepter tous les types
Pour créer un bloc qui "accepte" quel que soit le type, vous devez définir
vérification de la connexion à null.
Sous-types renvoyés
Pour créer un bloc qui "renvoie" un sous-type, vous devez inclure à la fois le type et le supertype dans la vérification de la connexion de la sortie.
Dans le cas des sous-types, il est possible d'avoir plusieurs vérifications dans un contrôle de sortie, car le bloc "renvoie" toujours les deux types.
Renvoie des types paramétrés
Pour créer un bloc qui "renvoie" un type paramétré, vous devez inclure à la fois la version paramétrée et la version non paramétrée dans le vérification de la connexion.
Selon le niveau de rigueur que vous souhaitez appliquer à votre langage de blocage, vous pouvez également Incluez la ou les variance(s) du type.
Comme pour les sous-types, il est possible d'avoir plusieurs vérifications dans un contrôle des résultats dans ce cas, car le bloc "renvoie" toujours les deux types.
Exemples de piles ou d'instructions
Les développeurs définissent les vérifications précédentes et suivantes de plusieurs façons. connexions externes. On les voit généralement comme une restriction d'ordre des blocs.
Les connexions suivantes doivent inclure les blocs qui doivent suivre le bloc actuel, et les connexions précédentes incluent ce qu'est le bloc actuel.
Maintenir les blocs dans l'ordre
Pour créer un ensemble de blocs qui se connectent dans un ordre défini, vous devez inclure quels blocs doivent suivre le bloc actuel lors de la prochaine vérification de connexion ; et ce qu'est le bloc actuel lors de la vérification de connexion précédente.
Autoriser de nombreux blocs intermédiaires
Pour créer un ensemble de blocs ordonnés qui permettent de nombreux volumes centraux, vous devez inclure au moins une entrée de l'enregistrement de connexion précédent du bloc du milieu la prochaine vérification de connexion du bloc du milieu. Cela permet de suivre le bloc par lui-même.
N'autoriser aucun bloc intermédiaire
Pour créer un ensemble de blocs ordonnés où les blocs du milieu sont facultatifs, vous devez afin d'inclure au moins une entrée de la connexion précédente du bloc central et la vérification de connexion précédente du dernier bloc dans le prochain bloc vérification de la connexion. Cela permet au premier bloc d'être suivi soit par un bloc central, ou un dernier bloc.
Piles ou pile
Pour créer un bloc qui ne peut être suivi que par les blocages d'un seul groupe ou les blocages à partir d'une autre (et non des deux), vous devez effectuer deux opérations:
Vous devez inclure au moins une entrée des deux groupes précédents lors de la prochaine vérification de connexion du premier bloc.
Vous devez définir les paramètres vérification de connexion suivante pour n'inclure que les valeurs qui se trouvaient lors des vérifications de connexion précédentes (ils ne peuvent donc être suivis par blocs du même groupe).
Limites
Ce système est assez robuste et peut résoudre de nombreux cas d'utilisation, mais il comporte quelques limites.
Limiter le contexte élargi
Ce système ne permet pas, en soi, de limiter l'accès à "un contexte plus large". dans
auquel une connexion est autorisée à se connecter. Par exemple, vous ne pouvez pas dire qu'un
Le bloc break ne peut exister qu'à l'intérieur d'un bloc loop. La connexion
ne prend en compte que les deux connexions
immédiates qui sont connectées.
Pour ce faire, vous pouvez utiliser le système d'événements afin d'écouter déplacer le bloc et vérifiez si le volume est mal positionné.
Blockly.Blocks['custom_block'] = {
init: function() { }
onchange: function(e) {
if (this.workspace.isDragging()) return;
if (e.type !== Blockly.Events.BlockMove) return;
if (!this.getSurroundLoop()) this.outputConnection.disconnect();
}
loopTypes: new Set(); // Your valid *block types* (not connection checks).
getSurroundLoop: function () {
let block = this.getSurroundParent();
do {
if (loopTypes.has(block.type)) return block;
block = block.getSurroundParent();
} while (block);
return null;
},
}
Types génériques
Ce système ne permet pas, en soi, de définir des types génériques. Par exemple : vous ne pouvez pas créer qui "renvoie" quelle que soit son entrée.
Vous pouvez y parvenir en quelque sorte en modifiant activement la vérification de la connexion sur le la sortie du bloc pour qu'elle corresponde à son entrée. Vous pouvez utiliser le système d'événements pour écouter les événements de déplacement de bloc.
Blockly.Blocks['custom_block'] = {
init: function() { }
onchange: function(e) {
if (e.type !== Blockly.Events.BlockMove) return;
this.setOutput(
true, this.getInputTargetBlock()?.outputConnection.getCheck());
}
}
Toutefois, si le bloc connecté est également générique, cela ne fonctionne pas correctement. Il n'existe pas de solution de contournement appropriée pour ce cas de figure.
Vérificateurs de connexion
Si ce système ne fonctionne pas pour votre cas d'utilisation, vous pouvez également de connexion sont comparées en créant vérificateur de connexion personnalisé.
Par exemple, si vous souhaitez créer un système plus avancé qui gère certaines limitations, vous pouvez créer le vérificateur de connexion.