Uma simplificação para passar var entre aplicações

Sr(a)s

Gostaria de, muito modestamente, apresentar a vcs uma alternativa para minimizar essa interface para registrar e passar variáveis globais, na minha opinião horrorosa - para uma ferramenta RAD.

O procedimento disponível no SC é :

1 - criar o campo da variável entre colchetes (na app de origem e na de destino);
2 - atribuir valor inicial a ela no evento no scripinit;
3 - gerar o fonte (sem gerar o fonte elas não aparecem na interface de var globais);
4 - ir no painel de variáveis globais, identificar a var global criada, definir que é uma var “sessão” (melhor também optar por GET e POST);
5 - no parâmentro “Opcional” não há nenhuma informação em manuais ou cursos informando pra que serve essa parâmetro, até perguntei no forum e não tive resposta até agora;
6 - defini-la como “Saída” ou “Entrada” (a despeito de que um var global vc pode ter a necessidade de recebê-la (“Entrada”) e passá-la para uma outra aplicação (“Saída”);

A solução seria criar uma única variável global (pode ter até mais de uma) que seria um agregado de valores de outras variáveis.

Apenas com exemplo, em uma App_Origem poderíamos ter uma query com essas colunas que eu teria, eventualmente, que passar para a App_Destino e, como é hoje tem que passar pelo “calvário” relatado acima:

>>>>>  Então, na App_Origem faria isso:

$w_comandoSQL = 'SELECT
“numeroDaProva”, – 00
“idQuestao”, – 01
“numeroSequenciaQuestao”, – 02
“idProcesso”, – 03
“idCandidato”, – 04
“numInscricaoCandidato”, – 05
“respostaIdAlternativa”, – 06
“respostaOrdemAlternativa”, – 07
status – 08

				FROM public.tb_candidato
				where "numeroDaProva" = '.[w_numeroDaProva]. ' AND "idQuestao" = '.[w_idQuestao]. // estas duas globais são param SQL original
			       'order by "ordemQuestao","numeroSequenciaQuestao";';

sc_lookup(dataset,$w_comandoSQL);

if (!empty({dataset}))
{
[g_atributos] = {dataset[0][0]}.".".{dataset[0][1]}.".".{dataset[0][2]}.".".{dataset[0][3]}. “.”.{dataset[0][4]}.".".{dataset[0][5]}.".".{dataset[0][6]}.".".{dataset[0][7]}.".".{dataset[0][8]};
}

// acho que g_atributos nem precisaria ser uma global definida na origem e destino. Poderia ser uma local (acho).

sc_redir(App_Destino,parm1=[g_atributos]);

Na App_Destino, eu faria um “explode” dos conteúdos e poderia utilizar todos conteúdos como variáveis locais, assim:

$codigo = [g_atributos];
list($v0, $v1,$v2,$v3 ,$v4 ,$v5 ,$v6 ,$v7 ,$v8) = explode(".", $codigo);

$w_numeroSequenciaQuestao = $v2;
$w_numInscricaoCandidato = $v5;
[g_idCandidato] = $v4;

… e assim por diante, atribuindo à variáveis locais os conteúdos de variáveis genéricas $v0, $v1… cujos conteúdos foram portados no agregado [g_atributos] que, na pratica, eu tenho a impressão, nem precisaria ser uma global (a testar).
Obviamente isso poderia ser implementado como uma macro, ou um bultin ou uma classe.

Eu testei e deu certo.
Mas, como não tenho a expertise da maioria do membros do forum que têm militância em código PHP e implementações em SC, a sugestão fica em aberto, para avaliação…

… em troca…, gostaria que alguém me respondesse :

1 - qual o conceito de sessão para o PHP - uma aplicação ou qualquer fuction chamada são sessões distintas, ou seja, chamei uma segunda aplicação ou function, uma outra session é criada. É isso ???

2 - pra que “diabos” serve o parâmetro “Opcional” na interface SC para definir var globais ?

Agradeço.

App A -> criar global:

[my_global] = [‘A’=>1,’B’=>2];

// não mexer nada em globais

App B -> qualquer evento

list($a,$b) = [my_global];
echo $a, ‘ ‘, $b;

Uma extensa explicação para uma sugestão que não melhora em nada a questão, e não acho tão ruim assim a questão de passagem de parâmetros via aplicações.

3 Curtidas

Não ter que declarar as globais em cada aplicação envolvida e simplesmente usar os conteúdos das variáveis, passados pela única var global que teria que ser criada e, ainda, usar os conteúdos enquanto variáveis locais não melhora em nada a questão ? Ainda, os erros recorrentes de passagem de variáveis globais de mesmo nome, onde a aplicação de destino não a reconhece e é necessário criar outra variável com nome diferente, acha que isso não pode ajudar? Vc está certo disso ?
A propósito, poderia me ajudar indicando onde posso obter informações sobre aplicação e uso do parâmetro “Opcional” no registro de variáveis globais ?
Obrigado Haroldo.

Variável global marcada como opcional o nome interno dela
Vem a palavra temp de temporário.

Acho eu que o tempo dela seria apenas durante a carga da aplicação.

A informação que tive com o backoffice do SC é que o parametro “opcional” faz com que a variável global não seja validada na aplicação de destino.

1 Curtida