As verificações de conexão restringem quais conexões (e, portanto, blocos) podem se conectar e se relacionam entre si.
As verificações de conexão são úteis para tipos de modelagem. Por exemplo, os seguintes três blocos não têm negócios sendo conectados, porque eles representam códigos que retorna tipos diferentes:
As verificações de conexão podem ser usadas para evitar que esses blocos se conectem. Isso fornece aos usuários feedback instantâneo e evita muitos erros simples.
Como funcionam
Toda conexão pode ser associada a uma "verificação de conexão" que é um valor nulo matriz de strings.
Duas conexões podem se conectar se:
- Eles são tipos compatíveis (por exemplo, uma saída conectada a uma entrada).
- Elas têm pelo menos uma string em comum na verificação de conexão.
Por exemplo, as duas verificações a seguir podem se conectar porque compartilham o
String 'apple'
:
['apple', 'ball', 'cat']
['apple', 'bear', 'caterpillar']
No entanto, não foi possível realizar estas duas verificações porque elas não compartilham nenhuma string:
['apple', 'ball', 'cat']
['ape', 'bear', 'caterpillar']
Existe outro caso especial. Se uma das matrizes for null
, as duas
também podem se conectar. Isso permite definir conexões que podem conectar
a qualquer coisa.
null
['ape', 'bear', 'caterpillar]
Definir verificações
Por padrão, todas as conexões têm uma verificação de conexão null
, o que significa que elas podem
se conectar a qualquer coisa. Verificações de conexão precisam ser atribuídas manualmente.
A forma como você atribui verificações de conexão às conexões varia de acordo com se você estiver usando definições de bloco JSON ou de bloco JavaScript.
JSON
Para conexões de nível superior, você atribui a verificação diretamente à propriedade que
define a conexão. O valor atribuído pode ser null
, uma string (que
se torna a única entrada na verificação de conexão) ou uma matriz de strings.
{
'type': 'custom_block',
'output': null,
'nextStatement': 'a connection check entry',
'previousStatement': ['four', 'connection', 'check', 'entries']
}
Para entradas, você pode atribuir a verificação a uma propriedade check
da entrada
definição. Se a propriedade check
não existir, a verificação será considerada.
null
. O valor atribuído pode ser uma string ou uma matriz de strings.
{
'type': 'custom_block',
'message0': '%1 %2',
'args0': [
{
'type': 'input_value',
'check': 'a connection check entry'
},
{
'type': 'input_statement',
'check': ['four', 'connection', 'check', 'entries']
}
]
}
JavaScript
Para conexões de nível superior, você pode passar a verificação diretamente para o método que
define a conexão. Se você não passar um valor, o cheque será considerado
null
: O valor que você passa pode ser uma string (que se torna a única entrada na
verificação de conexão) ou uma matriz de strings.
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']);
}
}
Para entradas, você pode passar a verificação para o método setCheck
, depois de
definiu a entrada. Se o método setCheck
não for chamado, a verificação será
considerada null
. O valor transmitido pode ser uma string ou uma matriz de strings.
Blockly.Blocks['custom_block'] = {
init: function() {
this.appendValueInput('NAME')
.setCheck('a connection check entry');
this.appendStatementInput('NAME')
.setCheck(['four', 'connection', 'check', 'entries']);
}
}
Strings de verificação integradas
Os blocos integrados têm verificações de conexão com os valores 'Array'
,
'Boolean'
, 'Colour'
, 'Number'
e 'String'
. Se você quiser que seus blocos
interoperem com os blocos integrados, é possível usar esses valores para torná-los
compatíveis.
Exemplos de valor
Ao definir verificações de conexão para entradas e saídas, geralmente considerar que as verificações representam tipos.
Entradas devem incluir cada "tipo" que eles aceitam e gera verifica precisam incluir exatamente o que eles "retornam".
Aceitar um único tipo
No caso mais básico, em que você quer criar um bloco que "aceita" ou "devoluções" um tipo, será necessário incluí-lo na verificação de conexão.
Aceitar vários tipos
Para criar um bloco que "aceite" vários tipos, é necessário incluir todos o tipo aceito na verificação de conexão da entrada.
Por convenção, se uma saída às vezes puder ser aceita em várias situações (por exemplo, se você permite que números sejam usados às vezes como strings), a saída deve ser mais restritivas, e as entradas devem ser mais permissivas. Esta convenção garante que as saídas não se conectem onde não são compatíveis.
Aceita qualquer tipo
Para criar um bloco que "aceite" qualquer tipo, é preciso definir o valor
verificação de conexão a null
.
Subtipos de retorno
Para criar um bloco que "retorna" um subtipo, você precisa incluir o tipo e o supertipo na verificação de conexão da saída.
No caso de subtipos, não há problema em ter várias verificações em uma verificação de saída, porque o bloco sempre "retorna" os dois tipos.
Retornar tipos parametrizados
Para criar um bloco que "retorna" um tipo parametrizado, é preciso incluir a versão parametrizada e a não parametrizada na saída verificação de conexão.
Dependendo da rigidez com que você quer aplicar a linguagem de bloqueio, também pode ser necessário incluir as variâncias do tipo.
Assim como com os subtipos, não há problema em ter várias verificações em uma verificação de saída neste caso, como o bloco sempre "retorna" os dois tipos.
Exemplos de pilha ou instrução
Os desenvolvedores definem as verificações dos eventos anteriores e posteriores de algumas formas conexões de rede. Normalmente, você pensa nisso como uma restrição da ordem dos blocos.
As próximas conexões devem incluir quais blocos devem seguir o atual e conexões anteriores incluem o que o bloco atual "é".
Manter os blocos em ordem
Para criar um conjunto de blocos que se conectam em uma ordem definida, você precisa incluir quais blocos devem seguir o atual na próxima verificação de conexão, e o que é o bloco atual na verificação de conexão anterior.
Permitir muitos blocos intermediários
Para criar um conjunto de blocos ordenados que permitem vários blocos intermediários, é preciso incluir pelo menos uma entrada da verificação de conexão anterior do bloco do meio na próxima verificação de conexão do bloco do meio. Isso permite que o bloco seja seguido mais de si mesmo.
Não permitir blocos intermediários
Para criar um conjunto de blocos ordenados em que os blocos intermediários são opcionais, você precisa incluir pelo menos uma entrada da conexão anterior do bloco do meio e a verificação da conexão anterior do último bloco na próxima linha verificação de conexão. Isso permite que o primeiro bloco seja seguido por um bloco ou um último bloco.
Pilhas
Para criar um bloco que só pode ser seguido por bloqueios de um grupo ou blocos de outro (e não de ambos), será preciso fazer duas coisas:
Você precisa incluir pelo menos uma entrada de ambos os grupos anteriores verificações de conexão na próxima verificação de conexão do primeiro bloco.
Você precisa definir A próxima conexão verifica para incluir apenas valores que estão nas verificações de conexão anteriores (para que só possam ser seguidas por blocos do mesmo grupo).
Limitações
Esse sistema é bastante robusto e pode resolver muitos casos de uso, mas tem alguns limitações.
Restringir o contexto maior
Este sistema, por si só, não suporta a restrição do "contexto maior" no
a que uma conexão tem permissão para se conectar. Por exemplo, não é possível dizer que um
O bloco break
só pode existir dentro de um bloco loop
. A conexão
o sistema de verificação considera apenas as duas conexões imediatas sendo conectadas.
Você pode fazer isso usando o sistema de eventos para ouvir block move e verifique se o bloco está posicionado incorretamente.
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;
},
}
Tipos genéricos
Esse sistema, por si só, não é compatível com a definição de tipos genéricos. Por exemplo: não é possível criar uma "Identidade" bloco, que "retorna" seja qual for a entrada.
Para oferecer isso de alguma forma, altere ativamente a verificação de conexão no saída do bloco para corresponder à entrada. O que você pode fazer usando o sistema de eventos para ouvir eventos de movimentação de blocos.
Blockly.Blocks['custom_block'] = {
init: function() { }
onchange: function(e) {
if (e.type !== Blockly.Events.BlockMove) return;
this.setOutput(
true, this.getInputTargetBlock()?.outputConnection.getCheck());
}
}
No entanto, se o bloco conectado também for genérico, isso não vai funcionar corretamente. Não há uma boa solução para esse caso.
Verificadores de conexão
Se esse sistema não funcionar no seu caso, mude a forma como o verificações de conexão são comparadas criando verificador de conexão personalizado.
Por exemplo, se você quiser criar um sistema mais avançado que gerencie algumas limitações deste, é possível criar um verificador de conexão.