Exemplo de Utiliza o para Ebook

Scriptcase – Técnicas Avançadas
2012
Scriptcase
Técnicas Avançadas
Parte I
1
2012
Sumário
1. Introdução .................................................................................................................................................... 3
2. Banco de Dados (uma visão genérica) ........................................................................................................ 5
3. Segurança ................................................................................................................................................... 12
4. ScriptCase (SC). .......................................................................................................................................... 22
4.1. Introdução .......................................................................................................................................... 22
4.1.1. Acessando ScriptCase ................................................................................................................ 24
4.1.2. Criando um Projeto .................................................................................................................... 27
4.1.3. Nova Aplicação .......................................................................................................................... 32
4.1.4. Funcionalidades do ScriptCase .................................................................................................. 46
4.1.4.1. Menu Principal ................................................................................................................... 46
4.1.4.2. Barra de Ferramentas ........................................................................................................ 48
4.1.4.3. Barra de Tarefas ................................................................................................................. 49
4.1.4.4. Projeto Explorer ................................................................................................................. 49
4.1.5. Montando a Segurança do Nosso Sistema. .............................................................................. 52
4.1.6. Criando a Aplicação Login .......................................................................................................... 61
4.1.7. Criando uma Aplicação Tipo Menu. .......................................................................................... 78
4.1.8. Funcionalidade Esqueceu a Senha? .......................................................................................... 91
4.1.9. Valores Padrões. ...................................................................................................................... 103
4.1.10. Personalizando uma Aplicação do tipo Formulário. ............................................................... 105
4.1.11. Personalizando uma Aplicação do tipo Consulta. .................................................................. 148
4.1.12. Construindo/Alterando um Template .................................................................................... 169
4.1.13. Criando/Personalizando uma Aplicação Calendário .............................................................. 183
4.1.14. Registro de Logs/Acessos ........................................................................................................ 192
4.1.15. Segurança nas Aplicações ........................................................................................................ 193
4.1.16. Outras Aplicações do Nosso Sistema ...................................................................................... 198
2
2012
1. I ntrodução
O desenvolvimento de aplicações WEB para internet / intranets é uma forte tendência na Informática. Cada
vez mais, as empresas desenvolvem ou migram seus sistemas para plataforma WEB. No entanto, criar
aplicações para a internet não é tarefa simples. Aquisição de tecnologias, capacitação e diversidade de
linguagens são alguns dos desafios, além de representarem investimentos de alto custo.
Pensando nisto, a NetMake desenvolveu o ScriptCase, um ambiente de desenvolvimento de aplicações WEB

(consultas, relatórios, formulários e menus), baseadas em Banco de Dados. Facilidade de manuseio, rapidez
na criação de aplicações e inúmeros recursos de programação são características diferenciais do ScriptCase.
O ScriptCase roda em um servidor web e pode ser acessado via internet / intranet (qualquer browser), ou
seja, é uma ferramenta bastante diferenciada das demais por conta da sua portabilidade.
O ScriptCase permite criar novos sistemas ou agregar aplicações WEB a sistemas já existentes. Para o usuário
profissional, o ScriptCase permite a programação avançada (regras de negócio), permitindo até a criação de
sistemas complexos. Para o usuário final, devido a facilidade de manuseio - o ScriptCase requer apenas
conhecimento básico de SQL - torna-se forte gerador de relatórios e consultas em diversas saídas,
destacando-se os formatos PDF, XLS e RTF.
O objetivo geral deste curso é elaborar uma aplicação WEB, com diversos recursos avançados, utilizando
como ferramenta o ScriptCase e como objetivos genéricos aprenderemos algumas técnicas que facilitarão o
desenvolvimento desta aplicação.
Fontes
O ScriptCase gera os programas-fonte (PHP, JavaScript, HTML e AJAX). Os fontes gerados são totalmente
independentes da ferramenta, podendo ser copiados para qualquer servidor WEB. A linguagem PHP é
gratuita (GNU) e pode ser utilizada nos ambientes Windows ou Linux (todo processamento do PHP é feito no
servidor).
Pré Requisitos
Do ambiente: O ScriptCase deve ser instalado em um servidor web que possua o PHP instalado e o Zend
Optimizer e um banco de dados padrão SQL (MySql, SqLite, etc). Quanto ao servidor web, para ambiente
Microsoft pode ser o IIS ou o APACHE. No ambiente Linux, sugerimos o servidor APACHE.
Do usuário: O ScriptCase é utilizado a partir do browser, nos ambientes Windows ou Linux. É desejável
conhecimentos básicos de SQL.
Ferramentas Adicionais
3
2012
Além dos recursos para criação de aplicações web, o ScriptCase oferece recursos adicionais que o tornam um
ambiente completo para desenvolvimento de sistemas, leia sobre as ferramentas abaixo:
SQL Builder
Ferramenta para auxiliar a construção de consultas SQL em forma de wizard. Permite a escolha da base de
dados, tabelas, campos, order by e where, assim como, a realização de simulações dos comandos montados
e a sua salva para uso posterior.
WebHelp
Permite criar webhelps, de modo a padronizar uma documentação e facilitar a sua criação.
Principais Recursos:
Permite criar arquivos HTMLS com interface gráfica (WYSIWYG), css, upload de imagens e menu hierárquico.
Permite também ligar uma aplicação diretamente a uma página do help, sem a necessidade editar os helps
de cada aplicação.1
1
Texto extraído do Manual do ScriptCase – V.5.0.264, publicado no site www.scriptcase.com.br
4
2012
2. B anco de Dados (uma visão genérica)
Iniciaremos este estudo tratando de bancos de dados. O SC foi projetado para trabalhar com quase todos os
bancos relacionais que utilizem a linguagem SQL (Structured Query Language ou Linguagem de Consulta
Estruturada – veja figura abaixo), no nosso curso utilizaremos o MySQL como padrão. Não será nossa
intenção ensinar SQL, pois entendemos que este é um requisito básico de desenvolvedores de sistemas, mas
o conhecimento de algumas dicas tornará o nosso aprendizado mais eficaz.
Desenvolver uma aplicação não é uma tarefa fácil para um programador, mas bem mais simples para quem
possui conhecimentos em análises de sistemas, uma vez que escrever o código é a última das tarefas.
Estabelecendo uma escala cronológica podemos dizer que um sistema bem elaborado passa pelas seguintes
etapas de desenvolvimento:
a) Regras de Negócio - São declarações sobre a forma da empresa fazer negócio. Elas refletem políticas
do negócio. Organizações têm políticas para satisfazer os objetivos do negócio, satisfazer clientes,
fazer bom uso dos recursos, e obedecer às leis ou convenções gerais do negócio. Regras do Negócio
tornam-se requisitos, ou seja, podem ser implementados em um sistema de software como uma
forma de requisitos de software desse sistema. Representam um importante conceito dentro do
processo de definição de requisitos para sistemas de informação e devem ser vistas como uma
declaração genérica sobre a organização.
No processo de desenvolvimento de qualquer sistema, a regra de negócio visa detalhar as

funcionalidades particulares do software. Com isso facilita por parte dos programadores o
desenvolvimento de métodos de tratamento de exceções, particularidades que o sistema possa
executar e o mais importante, limitar ações fora do processo normal de funcionamento de um
sistema específico.
b) Casos de Estudo ou Métodos do Caso - Um método é um conjunto de processos pelos quais se torna
possível conhecer uma determinada realidade, produzir determinado objeto ou desenvolver certos
procedimentos ou comportamentos (OLIVEIRA, 1999). O método científico caracteriza-se pela
5
2012
escolha de procedimentos sistemáticos para descrição e explicação de uma determinada situação
sob estudo e sua escolha deve estar baseada em dois critérios básicos: a natureza do objetivo ao
qual se aplica e o objetivo que se tem em vista no estudo (FACHIN, 2001).
c) Casos de Uso - Um caso de uso representa uma unidade discreta da interação entre um usuário
(humano ou máquina) e o sistema. Um caso de uso é uma unidade de um trabalho significante. Por
exemplo: o “login para o sistema”, “registrar no sistema” e “criar pedidos” são todos casos de uso.
Cada caso de uso tem uma descrição o qual descreve a funcionalidade que irá ser construída no
sistema proposto. Um caso de uso pode “incluir” outra funcionalidade de caso de uso ou “estender”
outro caso de uso com seu próprio comportamento.
d) Montagem/Modelagem do Banco de dados.
e) Escrever o Código.
f) Testar a aplicação.
g) Mantê-la em funcionamento (em produção).
Como já foi mencionado anteriormente, não é propósito deste curso o aprofundamento dos conceitos
acima, veremos apenas, na prática, como eles funcionam.
Imaginemos o seguinte cenário:
Um hospital está nos contratando para desenvolver uma aplicação

baseada na web para gestão dos seus recursos humanos.
Situação Geral
Cliente: Hospital Nossa Senhora de Arapiraca
Endereço: Rua Engenheiro João Batista pereira, 129 – Centro – Arapiraca – 57.300-450 – AL.
Fone – 82 3521.9000
Contato – Dr. Jean Charles, Médico Cardiologista, graduado pela Universidade de Medicina do Agreste
Alagoano, Doutor em Cirurgia Cardiovascular pela Universidade de Havard, email
jeancharles@hnsarapiraca.com.br, celular 82 8866.5544
Recepcionista – Gisele Budchen, 2º grau completo, bons conhecimentos em informática, horário de

expediente de segunda a sexta, das 8:00 às 18:00hs.
Vigilante – José Marcos de Oliveira, 32 anos, ensino médio completo, residente no sítio Pau D´Arco, celular
82 3247.6451.
Gerente de Tecnologia – Paulo Roberto Simões Vaz, 38 anos, casado com Marta Rocha Castro Simões, pai
de Silvia Maria Castro Simões (18 anos), formado pelo Instituto de Tecnologia de Feira Grande, Esp em
Engenharia de Software pela FGV, residente na Rua José Alexandre, 356 – Baixão – Arapiraca – Alagoas.
6
2012
Diretor do Centro Cirúrgico – Dr. Antônio Carlos Batista de Melo, Médico Cirurgião, 58 anos, graduado pela
Universidade de Medicina do Agreste Alagoano, email carlosbatista@hotmail.com, atende as 2ª, 4ª e 6ª
das 8:00 ás 14:00.
Diretora do Laboratório de Análises Médicas – Dilma Russef, enfermeira, graduada pela Escola de
Medicina Santa Juliana, email dilmapresidenta@brasil.com.br.
Além de outros 459 funcionários com diversos níveis de escolaridade e formação, lotados nos 14
departamentos do hospital.
Com base neste cenário, imaginando que já conhecemos as regras de negócio, os estudos de casos e os casos
de uso, iremos montar/modelar nosso banco de dados.
Exercício 1:
Montem uma estrutura de dados que se adapte aos nossos objetivos.

A princípio existe apenas a necessidade de criarmos duas ou três tabelas (clientes, colaboradores e
departamentos), mas toda aplicação tem entre os seus conceitos básicos:
a) Tornar a sua operação mais simples possível;

b) Evitar erros de digitação;
c) Evitar o re-trabalho;
d) Evitar o maior número possível de atualizações.
Dessa forma aplicaremos um conceito muito comum em modelagem que é a normalização (NF) do banco.
O objetivo da normalização de um banco de dados é evitar os problemas que podem provocar falhas no
projeto do banco de dados, bem como eliminar a mistura de assuntos e as correspondentes redundâncias
dos dados desnecessárias. A abreviação usada, (NF), vem do inglês, "Normal Form".
O processo de normalização aplica uma série de regras sobre as tabelas (também chamadas de relações) de
um banco de dados, para verificar se estão corretamente projetadas.
Tipos de Formas Normais
a) Primeira forma normal (1NF);

b) Segunda forma normal (2NF);
c) Terceira forma normal (3NF);
d) Forma normal Boyce/Codd (BCNF)
Inicialmente veremos a 1NF, no decorrer do curso, havendo necessidade, veremos outras.
Um esquema de relação R está na 1FN se todos os seus atributos forem atômicos (simples) e
monovalorados, ou seja, não são permitidos atributos multivalorados, atributos compostos ou atributos
multivalorados compostos.
Exemplo:
7
2012
FUNCIONÁRIOS = {CODFUNC + NOME + CARGO + {PROJETO + DATAINI + DATAFIM}}
Para colocar na 1FN:
FUNCIONÁRIOS = {CODFUNC + NOME + CARGO}
FUNC_PROJ = {CODFUNC + PROJETO + DATAINI + DATAFIM}
OBS: A chave primária de FUNCIONÁRIOS vai ser a chave estrangeira de FUNC_PROJ.
Veja abaixo outro exemplo de tabela que não está na 1FN (considerando que o campo TELEFONES é
multivalorado):
PESSOAS = {ID + NOME + ENDERECO + TELEFONES}
Para deixar esta tabela na 1FN, deve-se separar o campo multivalorado TELEFONES em uma tabela adicional,
desta forma:
PESSOAS = {ID + NOME + ENDERECO}
TELEFONES = {PESSOA_ID + TELEFONE}
Outra forma de identificar se a tabela está na 1NF é verificando se existem tabelas aninhadas, ou seja, mais
de um registro para uma chave primária.
Observe o exemplo:
Considere um Pedido número 00001, para este pedido se observarmos o formulário em papel teremos
muitos campos a considerar, contudo usaremos apenas alguns para facilitar o entendimento.
PEDIDOS = {PEDIDO + CLIENTE + VENDEDOR + ATENDENTE + PRODUTO + QUANT + VALOR}
Neste momento devemos idealizar o pedido número: 00001 e efetuar os seguintes testes:
PEDIDO CLIENTE VENDEDOR ATENDENTE PRODUTO QUANT VALOR

00001 Paulo César José Silva João Tênis 1 50,00
00001 Paulo César José Silva João Sandália 2 60,00
00001 Paulo César José Silva João Carteira 1 80,00
Observe que para os dados do pedido 00001 lançados acima, apenas os atributos que estão em negrito SÃO
ÚNICOS, pois não se diferem. Os demais atributos mudam, não cumprindo a 1NF onde os atributos devem
ser atômicos, quer dizer únicos.
Para testarmos um dos atributos e ter certeza que este é atômico, podemos efetuar uma pergunta conforme
o exemplo abaixo:
Podemos ter outro cliente para o pedido 00001? = Não. Podemos ter apenas 1 cliente por pedido, sendo
assim este atributo é atômico único para 1 pedido.
Podemos ter outro vendedor para o pedido 00001? = Não. Podemos ter apenas 1 vendedor por pedido.
8
2012
Podemos ter outro produto para o pedido 00001? = Sim. Podemos ter vários produtos para um pedido,
sendo assim, os campos aninhados devem ser extraídos para outra tabela.
Assim sendo devermos normalizar esta tabela, transformando-a em duas: PEDIDOS e PRODUTOS. Essa é a
técnica fundamental da normalização.
Voltando ao nosso exercício, criaremos a seguinte estrutura de dados:
Tabela : Colaboradores
Campo Chave
Id Primária (pk)
Nome
Endereço
Estado civil(id) Estrangeira (fk)
Escolaridade(id) Estrangeira (fk)
Formação(id) Estrangeira (fk)
Cargo(id) Estrangeira (fk)
Função(id) Estrangeira (fk)
Lotação(id) Estrangeira (fk)
Habilidades(id) Estrangeira (fk)
Cônjuge
Telefone
email
Atendimento(id) Estrangeira (fk)
Nascimento
Tabela: Clientes
Campo Chave
Id Primária (pk)
Nome
Endereço
Contato
Telefone
Tabela: Estado Civil
Campo Chave
Id Primária (pk)
Descrição
Tabela: Escolaridade
Campo Chave
Id Primária (pk)
Descrição
9
2012
Tabela: Formação
Campo Chave
Id Primária (pk)
Descrição
Tabela: Cargo
Campo Chave
Id Primária (pk)
Descrição
Tabela Função
Campo Chave
Id Primária (pk)
Descrição
Tabela: Lotação
Campo Chave
Id Primária (pk)
Descrição
Tabela: Habilidades
Campo Chave
Id Primária (pk)
Descrição
Tabela: Atendimentos (horários)
Campo Chave
Id Primária (pk)
Descrição
Tabela: Dependentes
Campo Chave
Id Primária (pk)
Lotação(id) Estrangeira (fk)
Nome
Grau de parentesco(id) Estrangeira (fk)
10
2012
Tabela: Graus de Parentesco
Campo Chave
Id Primária (pk)
Descrição
Foram necessárias inicialmente 12 tabelas, mais adiante veremos que serão necessárias pelo menos mais
umas 20 tabelas pra completar esse pequeno ciclo.
Se você imaginou menos que 12 tabelas, deveremos rever alguns conceitos.
Se você concluiu que havia necessidade de pelo menos 15 tabelas, seu conhecimento e capacidade de
abstração são muito bons.
Se você concluiu que seriam necessárias mais que 15 tabelas talvez você precise entender que tudo em
informática tem um custo. Muita normalização implica em muito acesso ao disco, muita memória, muito
processador, etc. Entenda que o que é normalizado precisa ser desnormalizado em algum momento, para
facilitar o entendimento e as consultas realizadas pelo usuário final. Então a situação ideal é o meio termo.
Daremos uma pausa nesta etapa que busca firmar dois fundamentos:
a) Obter o máximo de informação possível para a elaboração do DB;

b) Normalizar o banco.
Vamos passar agora para outra questão muito importante na modelagem do nosso banco de dados –
Segurança da Informação.
11
2012
3. S egurança
Exercício 2:
Adotando ainda o cenário anterior, elaborem um esquema de segurança

para nosso sistema.
É preciso que se entenda que não existe sistema 100% seguro. Na melhor das hipóteses quem desenvolveu o
esquema de segurança saberá como quebrá-lo.
Uma aplicação stand alone (autônoma, sozinha), sem ser baseada na web, requer critérios de segurança bem
menos complexos, porém não menos importantes. Uma aplicação web requer esforço extremo no quesito
segurança. Um dos fatores que concorre para isso é que o usuário final (o cliente), na maioria das vezes, não
faz a mínima idéia do que se passa por traz de um aparato de segurança de uma aplicação web e por não
conhecê-los não toma providências no sentido de evitá-las. Dessa forma, caberá a você analista definir a
quase totalidade dos estudos de casos e casos de uso.
A segurança poderá e deverá ser feita em três camadas:
a) No banco de dados – Todo DB relacional possui um forte esquema de segurança;

b) Na aplicação - O SC tem incorporado um bom esquema de segurança, falaremos sobre isso no
momento oportuno, mas caberá ao projetista do banco reforçá-la e implementá-la.
c) No servidor – O gerente de rede dará suporte nesta etapa.
Nossa intenção agora é montar um esquema no banco de dados que reforce a segurança na camada da
aplicação.
As boas práticas de segurança estabelecem os seguintes níveis mínimos.
a) Nível de aplicação – Saber quem pode acessar quais aplicações, e quais os privilégios deste acesso
(incluir, alterar, excluir e consultar);
b) Nível de registro – Saber quem é dono do registro e, mesmo como proprietário, quais os privilégios
serão atribuídos a este registro (incluir, alterar, excluir e consultar).
Visto isso, precisaremos das seguintes tabelas:
Tabela: Usuários
Campo Chave
Id Primária (pk)
Nome
12
2012
Login Índice
senha
Tabela: Aplicações
Campo Chave
Id Primária (pk)
Descrição
Tabela: Grupos de Acesso (No Registro)
Campo Chave
Id Primária (pk)
Descrição
Tabela: Grupos (Na aplicação)
Campo Chave
Id Primária (pk)
Descrição
Tabela: Grupos de Aplicações (Na aplicação)
Campo Chave
Id Primária (pk)
Grupo de Acesso(id) Estrangeira (fk)
Aplicação(id) Estrangeira (fk)
Atributos de Acesso
Tabela: Perfil de Acesso (No registro)
Campo Chave
Id Primária (pk)
Descrição
Tabela: Perfil de Grupo (Na aplicação)
Campo Chave
Id Primária (pk)
Perfil de Acesso(id) Estrangeira (fk)
Grupos(id) Estrangeira (fk)
Atributos de Acesso
13
2012
Tabela: Grupo de Usuários (Na aplicação)
Campo Chave
Usuário(id) Estrangeira (fk)
Se você imaginou menos que 8 tabelas, seu esquema de segurança é extremamente frágil e deveremos rever
alguns conceitos.
Um esquema neste molde é satisfatório, mas poderemos ampliá-lo com algumas decisões, veja:
a) Na tabela de usuários, acrescentaremos um campo que forçasse a troca de senha temporariamente.

Havendo necessidade de trocar a senha é necessário um campo que informe a data da última troca e
outro informando qual o período de troca;
b) Poderemos reforçar a senha criptografando-a em 16 bits – md5 (mínimo recomendável);
c) Acrescentaremos em todas as tabelas um campo prop_reg (proprietário do registro) para
determinar quem é o proprietário do registro;
d) Acrescentaremos um campo situação na tabela usuários para determinar se o mesmo está ativo ou
inativo;
e) Acrescentaremos um campo Status na tabela Grupos de Proprietários para determinarmos se ele
está bloqueado ou livre. Caso esteja bloqueado, todos os usuários daquele grupo estarão
automaticamente bloqueados, sem a necessidade de bloquear/desbloquear um-por-um cada
usuário.
f) Acrescentaremos dois campos em todas as tabelas: login (quem criou o registro) e data da criação
do registro.
Veja, foram medidas simples que ampliaram nossa margem de segurança.
Nosso banco está assim agora.
Tabela: Usuários
Campo Chave
Id Primária (pk)
Nome
Login Índice
Situação
Trocar Senha?
Qual o período de
troca de senha?
Qual a última data
de troca?
senha Criptografada md5
prop_reg
Login Estrangeira (fk)
Data da criação
14
2012
Tabela: Aplicações
Campo Chave
Id Primária (pk)
Descrição
prop_reg
Data da criação
Tabela: Grupos de Acesso (No registro)
Campo Chave
Id Primária (pk)
Descrição
prop_reg
Data da criação
Tabela: Grupos (Na aplicação)
Campo Chave
Id Primária (pk)
Descrição
Status
prop_reg
Data da criação
Tabela: Grupos de Aplicações (Na aplicação)
Campo Chave
Id Primária (pk)
Atributos de Acesso
prop_reg
Data da criação
Tabela: Perfil de Acesso (No registro)
Campo Chave
Id Primária (pk)
Descrição
prop_reg
15
2012
Data da criação
Tabela: Perfil de Grupo (Na aplicação)
Campo Chave
Id Primária (pk)
Perfil de Acesso(id) Estrangeira (fk)
Grupo de Proprietários(id) Estrangeira (fk)
Atributos de Acesso
prop_reg
Data da criação
Tabela: Grupo de Usuários (Na aplicação)
Campo Chave
Usuário(id) Estrangeira (fk)
prop_reg
Data da criação
O SC oferece um utilitário muito interessante chamado de calendário (agendamento de compromissos). Esse

calendário é particular, porém é muito interessante criarmos uma forma de compartilhamento destas
informações, tornando-as coorporativas, afinal esse é o propósito de uma aplicação web. Aproveitando que
estamos tratando segurança, criaremos mais três tabelas que farão o compartilhamento deste calendário.
Tabela: perfil de Acesso da Agenda (No registro)
Campo Chave
Id Primária (pk)
Descrição (igual ao
login do usuário)
prop_reg
Prop_agd
Data da criação
Tabela: Grupo Acesso da Agenda (No registro)
Campo Chave
Id Primária (pk)
prop_reg
Prop_agd
16
2012
Data da criação
Tabela: Perfil de Grupo Agenda (No registro).
Campo Chave
Id Primária (pk)
Perfil de Acesso Estrangeira (fk)
Agenda(id)
prop_reg
Prop_agd
Data da criação
Está pronto nosso esquema de segurança? Ainda não. Parta do princípio que a pessoa que menos entende
de segurança de sistemas, no mundo, é você. Então, implantaremos mais um dispositivo - esquema de LOGs
de ACESSO e AÇÕES. Embora os DBs já produzam este tipo de segurança, normalmente eles possuem dois
pontos muito fracos:
a) Degeneram a performance do banco;

b) Suas auditorias são muito complicadas.
Para tanto acrescentaremos mais uma tabela que registrará toda e qualquer ação que for realizada pela
aplicação.
Tabela: LOGs
Campo Chave
Id Primária (pk)
Data e Hora
login Estrangeira (fk)
IP
Ação
Realizado
status
Nota:
A tabela de Logs sugerida não possuirá campos tipo BLOB para armazenamento de imagens,
desta forma não serão atualizadas operações com imagens no tratamento dos logs.
Outra ação bastante interessante é determinarmos quem está logado na aplicação. Essa tarefa é muito
complicada em aplicações web, uma vez que o usuário está utilizando-se de um navegador (Firefox, IE,
Google Chrome), que é uma aplicação externa, para acesso ao nosso sistema e para sair da aplicação baixa
17
2012
fechar o navegador. Utilizaremos a tabela acima para efetuarmos esse controle – mas desde já informo –
esta solução não representará 100% da realidade.
Comentários sobre o esquema de segurança
Segurança do Registro (Acesso)
O esquema de segurança foi montado para uma aplicação multi-empresa, onde cada empresa poderá gerir
os seus registros ou grupos de registros.
No esquema abaixo podemos observar que:
a) Cliente A tem controle sobre os registros do Cliente B, C e D;

b) Cliente B tem controle apenas dos seus registros;
c) Cliente C tem controle sobre os seus registros e os do Cliente D;
d) Cliente D tem controle apenas dos seus registros.
Esses controles são definidos pelas tabelas de acesso (grupo_acesso, perfil_grupo e perfil _acesso).
A tabela grupo_acesso definirá cada cliente (empresa) do sistema.
A tabela perfil_grupo definirá o controle que cada cliente terá sobre os demais clientes.
Sempre que um novo cliente é cadastrado, automaticamente será lançado um novo registro na tabela
grupo_acesso definido pela sua sigla e posteriormente o administrador definirá sobre quais grupos de
acesso ele terá o respectivo controle.
18
2012
Toda tabela terá um campo prop_reg que determinará a que grupo_acesso ele pertence,
conseqüentemente quais clientes terão acesso sobre ele.
Para efetuar este controle criaremos uma função no banco de dados denominada PermiteAcesso, que
receberá dois parâmetros: usuario e prop_reg. Veja abaixo:
A forma correta de chamar esta função é:
PermiteAcesso(‘usuario’, prop_reg) = ‘Sim’

Onde o usuario é quem está fazendo a consulta e prop_reg quem é o proprietário do registro da tabela que
está sendo consultada.
Esta função estará sempre presente em cláusulas WHERE das querys
Segurança na Aplicação
O controle dos usuários sobre as aplicações será definido por grupos que determinarão perfis de acesso
(Inclusão, Alteração, Exclusão e Consulta) às aplicações.
Por padrão nosso esquema criou dois grupos básicos:
19
2012
a) Administradores – Acesso total a todas as aplicações;
b) Acesso Restrito – Acesso total a um conjunto mínimo de aplicações (login, menu, troca de senhas,
agenda, esqueceu a senha e sair do sistema)
Outros grupos poderão ser criados por livre escolha, como por exemplo:
a) Cadastradores –Acesso total às aplicações do tipo Formulário;

b) Consultas – Acesso às aplicações do tipo Consulta.
Esses controles são definidos pelas tabelas de acesso (aplicações, grupos, grupo_aplicacoes e
usuario_grupos).
Tabela Definição Exemplos

grupos Descrição dos grupos Administrador, Acesso Restrito, etc
aplicacoes Descrição de todas as login, menu, form_usuarios, etc
aplicações do sistema
grupo_aplicacoes Definirá quais grupos terão Grupo Administadores – Acessos
acessos às aplicações e qual o A;I;E;C em todas as tabelas
perfil de acesso
Usuário_grupos Definirá a que grupo(s) Usuário administrador pertence a
pertence(m) cada usuário todos os grupos
Sempre que um novo usuário é cadastrado ele receberá o perfil do grupo de Acesso Restrito, posteriormente
o administrador definirá qual(is) grupo(s) ele pertencerá.
Segurança na Agenda (Registro)
Os registros das agendas poderão ser acessados de forma pessoal ou corporativa
Para efetuar este controle criaremos uma função no banco de dados denominada PermiteAcessoAgenda,
que receberá dois parâmetros: usuario e prop_agd. Veja abaixo:
20
2012
A forma correta de chamar esta função é:
PermiteAcessoAgenda(‘usuario’, prop_agd) = ‘Sim’

Onde o usuario é quem está fazendo a consulta e prop_agd quem é o proprietário do registro da tabela
agenda.
Sempre que um novo usuário é cadastrado, automaticamente será lançado um novo registro na tabela
grupo_acesso_agenda definido pelo login deste cliente e posteriormente o administrador definirá sobre
quais grupos de acesso a agenda este participará.
21
2012
4. S criptCase (SC).
4.1. Introdução
Sistema e Aplicação
Em linhas gerais, cada página web elaborada pelo Scripctcase é uma aplicação e o conjunto de aplicações
(páginas) compõem um sistema. Cabe salientar dois pontos:
a) Uma página web poderá, em alguns casos, ser composta de mais de uma aplicação;
b) Uma aplicação nem sempre será uma página – existem aplicações que não serão visualizadas em
páginas. Exemplo: uma aplicação de registro de saída do sistema de um usuário.
O ScriptCase elabora os seguintes tipos de aplicações:
CONSULTAS - São as aplicações para visualização dos dados. Uma consulta no ScriptCase tem também o
caráter de relatório, uma vez que gera a saída em PDF, XLS, XML, RTF e outros formatos.
FORMULÁRIOS - São as aplicações para atualização de Dados. O ScriptCase cria uma aplicação com todos
os recursos de inclusão, alteração, exclusão e navegação de registros.
Os Formulários estão divididos em 4 tipos de orientação: Simples, Múltiplos Registros, Grid editável e Grid
Editável (view).
ABAS - O ScriptCase permite através desta opção reunir várias aplicações já desenvolvidas e dar à aplicação
resultante um destes formatos ou ambos, onde cada aba ou cada opção da pasta corresponde a uma
aplicação.
22
2012
CONTROLE - São as aplicações criadas para infra-estrutura do sistema. Podem ser utilizadas para captação
de dados (parâmetros) que serão repassados a outras aplicações.
Ex.: login de sistema, seleção da empresa, seleção de acesso e etc.
MENU - As aplicações de menu servem para criar uma estrutura hierárquica de navegação das aplicações do
sistema. É um recurso extremamente útil, uma vez que organiza as aplicações de modo visual, facilitando o
acesso do usuário às aplicações.
MENU ÁRVORE - As aplicações de Menu Árvore servem para criar uma estrutura de navegação das
aplicações do sistema em formato Tree View (similar ao windows explorer). É um recurso extremamente útil,
uma vez que organiza as aplicações de modo visual, facilitando o acesso do usuário às aplicações.
FILTRO - Formulário de filtro para ligar alguma aplicação que necessite receber uma string contendo uma
cláusula where.
REPORT PDF - ScriptCase oferece uma ferramenta para gerar relatórios de qualidade, usando formatos pré-
definidos.
Use esta aplicação para gerar relatórios para as instituições de governo ou outra organização que formato
exigido específicos.
CONTAINER - Permite exibir vários tipos de aplicações aninhadas em Widgets semelhantes àquelas para o
iGoogle.
BLANK - Permite ao desenvolvedor escrever PHP / código HTML e exibir um resultado do processo.2
Um sistema será tratado dentro da estrutura do ScriptCase como um projeto. O projeto será o repositório de
todas as aplicações, rotinas, conexões ao banco e bancos de idiomas de um sistema.
2
Texto extraído do Manual do ScriptCase – V.5.0.264, publicado no site www.scriptcase.com.br
23
2012
4.1.1. Acessando ScriptCase
A tela acima representa a interface de logon, onde você deverá informar o seu código de usuário (login) e
senha.
Após a validação do usuário/senha e de acordo com o perfil estabelecido para o mesmo, o ScriptCase
disponibilizará as opções que o usuário terá acesso, assim como, os projetos que o mesmo poderá acessar.
Nota: O usuário do tipo "Administrador" tem privilégio de acesso a todas as funcionalidades do

ScriptCase, assim como, faz parte das suas funções o cadastro de novos usuários e o estabelecimento de
quais funções os mesmos terão acesso.
Uma vez autenticado/logado no ScriptCase, será apresentada a página do inicial de onde você pode
selecionar um projeto existente ou criar um novo projeto.
24
2012
Essa tela é composta dos seguintes itens:
a) Menu Principal;
b) Barra de Ferramentas;
c) Barra de Tarefas;
d) Área de Projetos.
Ao trabalharmos com um projeto esta área de projetos será dividida em duas áreas distintas: a) Projeto
Explorer; b) Lista de Aplicações. E teremos uma tela geral semelhante à figura abaixo.
25
2012
26
2012
4.1.2. Criando um Projeto
Podemos definir um projeto como sendo um sistema. Isso de forma bem simples, uma vez que se você
estender o conceito de sistema vários projetos poderão compor um único sistema. Exemplos:
a) Se você definir que o seu sistema é uma Folha de Pagamentos, então é aconselhável que o seu
projeto seja Folha de Pagamentos, conseqüentemente ele será o repositório de todas aplicações,
funções, rotinas, etc relativas à folha de pagamentos;
b) Se você definir que seu Sistema é um Gestor Financeiro, então é aconselhável que você divida este
sistema em partes (Contabilidade, Folha de pagamento, Contas a Receber/Pagar, etc) e cada parte
desta seja um projeto. Os projetos podem ser integrados entre si.
Uma divisão do sistema em partes facilitará a administração dos seus projetos.
Tudo isso é conceitual, você poderá definir um único projeto para um cliente que será repositório de todos
os sistemas, aplicações, etc relativos ao cliente.
Para criarmos um projeto basta clicar na figura
E teremos acesso a seguinte tela:
27
2012
Defina um nome para o seu projeto e descreva-o. Este nome não poderá conter espaços nem caracteres
especiais. Para o nosso curso o nome será treinamento.
O SC traz como exemplos alguns modelos de projeto, no nosso curso não os utilizaremos.
Click no botão
28
2012
Você poderá definir um banco de idiomas para o seu projeto. Nesta fase do nosso treinamento isso não é
interessante, veremos isso em outra oportunidade, click no botão
Outro ponto forte do SC é que você poderá definir lay-outs para seus sistemas. Essa definição poderá ser
feita em tempo de execução. Veremos esses tópicos mais adiante, por ora ficaremos na configuração básica.
Click no botão
29
2012
Como foi abordado nos capítulos anteriores, todo processo de desenvolvimento inicia-se pela modelagem do
banco de dados (DB), assim, ao criarmos um novo projeto, deveremos informar o Sistema Gestor do Banco
de Dados (DBMS – Data Base Manager System) que gerenciará nosso banco (DB).
No nosso curso definimos o MySQL, então click na figura correspondente.
30
2012
Supondo-se que sua base de dados está instalada em seu computador pessoal (localhost), escolha o usuário
e a senha, a seguir click no botão para selecionar a base de dados que utilizará
neste projeto, conforme exemplo abaixo.
Ao clicar no botão só serão disponibilizados os DBs que o usuário terá acesso, se

o usuário for o root terá acesso a todos os bancos.
Click no botão
Como esse é um novo projeto o SC abrirá uma tela sugerindo a criação de uma nova aplicação.
31
2012
4.1.3. Nova Aplicação
Existem dois modos de criação de uma nova aplicação:
a) Wizard;
b) Expressa.
Por ser mais completa utilizaremos a forma Expressa.
Um sistema por mais simples que seja terá pelo menos três aplicações:
a) Um Menu;
b) Uma tela de cadastro;
c) E uma tela de consulta/relatório.
Pois bem, antes de iniciarmos o sistema – objeto deste curso – faremos uma apresentação bem simples de
cada um desses tipos de aplicações e, a seguir, retornaremos às mesmas para um estudo mais avançado.
Os tipos de aplicações disponíveis foram descritas na Introdução deste capítulo, por ora veremos a criação
de uma aplicação do tipo formulário e utilizaremos como exemplo a tabela clientes da nossa base de dados.
32
2012
Selecione o tipo de aplicação Formulário.
E teremos a seguinte tela:
Escolha a conexão (conn_mysql)
Escolha a Tabela (clientes)
33
2012
Defina o nome da aplicação. Este nome não poderá conter espaços nem caracteres especiais. Poderemos
utilizar o nome padrão utilizado pelo SC (form_clientes).
Mesmo para os usuários mais experientes, 90 % das aplicações do tipo formulário são criadas desta maneira
ou seja, sem qualquer alteração dos valores padrões. O que pode mudar é o Tipo e sobre isso falaremos mais
adiante no estudo avançado.
34
2012
Click no botão e o SC criará a nova aplicação (form_clientes) e retornará para a edição da

mesma. Sempre haverá necessidade de editar uma aplicação recém gerada, mas esse será um passo que
daremos no estudo avançado.
Criaremos agora uma aplicação do tipo Consulta para a tabela clientes. Para tanto click no botão (Nova
Aplicação) localizado na barra de Ferramentas.
Defina a tabela (clientes).
35
2012
utilizar o nome padrão utilizado pelo SC (grid_clientes).
Click no botão e o SC criará a nova aplicação (grid_clientes) e retornará para a edição da

mesma. Sempre haverá necessidade de editar uma aplicação recém gerada, mas esse será um passo que
daremos no estudo avançado.
36
2012
Criaremos agora uma aplicação do tipo Menu para o nosso sistema. Para tanto click no botão (Nova
Aplicação) localizado na barra de Ferramentas e escolha o tipo de aplicação Menu
Click no botão
37
2012
Este é o cenário após a criação das três aplicações básicas.
Teremos agora que editar a aplicação menu, de forma tal que ela possa executar as aplicações geradas e sair
do sistema. Vamos lá.
Os passos seguintes serão:
a) Criar o item Clientes;

b) Dentro deste item, adicionarmos o sub-item Cadastrar Clientes;
c) Ainda dentro deste item (Clientes) adicionarmos o sub-item Consultar Clientes;
d) Criarmos o item Sair do Sistema.
Passo 1:
Na Configuração do Menu, crie o label Clientes e insira o Item.
38
2012
Passo 2:
Crie o label Cadastrar Clientes, informe a aplicação que será o link (form_clientes) e insira o Sub-item.
Passo 3:
Crie o label Consultar Clientes, informe a aplicação que será o link (grid_clientes) e insira o Item.
39
2012
Passo 4:
Crie o label Sair do Sistema, altere o Target para Sair e insira o Item.
Ao fazer isso você obterá a seguinte tela:
Você pode observar que o item Sair do Sistema está no mesmo nível dos itens Cadastrar Clientes e Consultar
Clientes, ou seja, está dentro do item Clientes, mas eu desejo que ele fique no mesmo nível (menu) que o
item Clientes. Para consertar isso utilize o botão , mostrado na figura anterior.
40
2012
Feito isso salve a aplicação clicando no botão Salvar, localizado na Barra de Ferramentas.
Pronto, agora que aplicações foram criadas na base de dados do SC precisamos gerar os códigos PHP.
Selecione a opção Projetos do Menu Principal e click em Gerar Código Fonte.
Teremos a seguinte tela:
41
2012
Terminado o processo, se tudo ocorreu bem, surgirá a seguinte tela.
Agora já poderemos executar o nosso sistema. Como ele se iniciará pela aplicação menu, click na sua aba
correspondente e a seguir click no botão Executar localizado na Barra de Ferramentas.
Eis o resultado do seu trabalho inicial.

42
2012
43
2012
44
2012
Evidentemente que um sistema neste estágio atual não deve ser apresentado sequer a nós mesmos, quanto
mais a um cliente. Poderia gastar algumas folhas de papel enumerando os problemas que encontramos nele,
mas a etapa de personalização das aplicações será descrita mais adiante. Por ora, nossa tarefa está concluída
– elaborar um pequeno sistema.
45
2012
4.1.4. Funcionalidades do ScriptCase
No tópico anterior aprendemos a criar alguns tipos de aplicações (menu, formulário e consulta) e montamos
um sistema. Esse sistema precisa ser totalmente editado (por diversos motivos), mas antes de efetuarmos
esta edição precisaremos conhecer melhor as potencialidades do ScriptCase – é o que veremos a seguir.
4.1.4.1. Menu Principal
O menu principal do SC disponibiliza as seguintes funcionalidades.
Arquivo
Novo Projeto Cria um novo projeto.
Abrir Projeto Lista os projetos que o usuário possui permissão.
Fechar Projeto Fecha o projeto em edição.
Nova Aplicação Cria novas aplicações de consultas, report pdf, formulários, abas,
controle, menu, filtro, container ou blank.
Criação Expressa Permite criar várias aplicações simultaneamente.
Aplicações Recentes Exibe as últimas aplicações editadas.
Menu Principal Navega para a página do menu principal do ScriptCase.
Restaurar Aplicação Utilizado para restaurar versões anteriores de uma aplicação.
Exportar Projeto Utilizado para exportar aplicações desenvolvidas utilizando o
ScriptCase.
Importar Projeto Utilizado para importar aplicações desenvolvidas utilizando o
ScriptCase.
Novos Módulos - Ferramenta para automatizar controle de acesso as suas
Segurança aplicações.
Logout Fecha o ScriptCase.
Exibir
Código Fonte Exibir último código fonte gerado da aplicação que
está sendo editada.
Filtrar Usuários – Todos os usuários Serão exibidas todas as aplicações desenvolvidas
pelo grupo.
Filtrar Usuários – Apenas admin Serão exibidas somente as aplicações desenvolvidas
pelo usuário.
Filtrar Pastas – Pastas clássicas Serão exibidos seus conteúdos quando forem
selecionadas.
Filtrar Pastas - Exibir abertas As pastas serão exibidas com seus conteúdos visíveis.
Dados em Sessão Serão exibidas todas as variáveis de sessão do
ScriptCase, bem como, as das aplicações executadas.
46
2012
Projeto
Propriedades Exibe as propriedades do projeto.
Valores Padrões Exibe a lista dos valores padrões para o projeto corrente.
Histórico de Versões Exibe as versões do projeto.
Incrementar Versão Incrementa a versão do projeto corrente.
Gerar Código Fonte Gera o fonte de todas as aplicações do projeto atual.
Publicar Abre o wizard de publicação do projeto corrente.
Exportar aplicações Gera um arquivo de exportação do projeto corrente.
Importar aplicações Importa um arquivo de backup no projeto corrente.
Excluir Elimina o projeto corrente.
Relatórios- Lista de Aplicações Exibe as aplicações do projeto.
Relatórios - Resumo por Exibe aplicações totalizadas pelo desenvolvedor.
Desenvolvedores
Exibir Diagrama Exibe o diagrama do projeto.
Busca em Aplicações Permite buscar por texto nas aplicações do projeto.
Conexões
Nova Conexão Cria uma nova conexão no projeto atual.
Editar Conexão Permite editar as conexões do projeto atual.
Aplicação
Salvar Salvar Aplicação.
Gerar Gerar o fonte da Aplicação.
Executar Executar a aplicação.
Ferramentas
SQL Builder Ferramenta para criação rápida de comandos
SQL.
Dicionário de Dados Permite ao usuário definir padrões para as
tabelas (nomes, e tipos de campos, etc.).
Edição expressa Abre uma janela para editar várias aplicações ao
mesmo tempo.
Criar WebHelp Ferramenta para criar documentação.
Bibliotecas Permite a criação de rotinas padrões que serão
utilizadas em muitas aplicações.
Regionalidade Idiomas Edição das mensagens.
Regionalidade Configurações regionais Personalização das configurações regionais.
Conversor Conversor (V4 -> V5).
Visualização- Temas Edição de Esquemas.
Visualização- Botões Gerenciamento de botões.
47
2012
Visualização - Templates Edição de templates.
Configuração
Administração Acesso a todas as configurações da parte de
administração do ScriptCase.
Meu ScriptCase Configurações personalizadas no nível do
usuário.
Trocar Senha Acesso a alteração senha.
Criar base de exemplos Abre um wizard para a criação das bases dos
sistemas de exemplos.
Ajuda
WebHelp Manual do ScriptCase.
Suporte Acessa o suporte on-line do ScriptCase.
Diagnosis Exibe configurações do ambiente / Servidor
onde está instalado o ScriptCase.
Verificar Versão Acessa o site do ScriptCase a procura de
atualizações.
Dicas Importantes Dicas do ScriptCase.
Sobre Informações sobre o ScriptCase.
4.1.4.2. Barra de Ferramentas
Novo Projeto Cria um novo projeto.
Abrir Projeto Lista os projetos que o usuário possui permissão.
Fechar Projeto Fecha o projeto corrente.
Nova Conexão Cria uma nova conexão no projeto atual.
Editar Conexão Permite editar as conexões do projeto atual.
Novo Criar aplicações através do recurso wizard.
Criação Expressa Criar aplicações de forma expressa.
Salvar Salva a aplicação editada. (*)
Gerar Fonte Gera o código-fonte da aplicação editada.(*)
48
2012
Executar Salva a aplicação, gera o programa-fonte e o executa. (*)
SQL Builder Executa ferramenta para construção de comandos SQL.
Menu Principal. Retorna ao Menu Principal do SriptCase

Documentação on-line do ScriptCase. De todas as
Web Help
funcionalidades.
Logout Saída do ScriptCase.
(*) As opções Salvar, Gerar Fonte e Executar só serão habilitadas quando uma
aplicação está sendo editada.
Demais atributos da Barra de Ferramentas:
a) Usuário - Mostra o nome do usuário ativo.

b) Projeto e versão - Mostra o projeto / versão corrente selecionado pelo usuário.
4.1.4.3. Barra de Tarefas

A barra de tarefas mostra as aplicações que foram abertas, permitindo a navegação entre elas.
4.1.4.4. Projeto Explorer

Projeto Explorer ocupa a parte central do SC, ficando logo abaixo da Barra de Tarefas. Figura abaixo
demonstra nosso projeto exemplo (treinamento).
49
2012
À direita teremos todas as Pastas criadas para administração do projeto. Estas pastas não fazem parte do
Sistema, elas são repositórios das aplicações e suas criações servem apenas para melhor administrar as
ações que estão sendo desenvolvidas no projeto.
Por exemplo: Como todo sistema terá algumas aplicações relativas à segurança é aconselhável que criemos
uma pasta Segurança e nela depositaremos todas as aplicações referentes à segurança do sistema.
Click no botão
Defina um nome para a pasta (Seguranca). Este nome não poderá conter espaços nem caracteres especiais.
50
2012
Click no botão
Você deverá criar tantas pastas quantas forem necessárias para uma boa administração do seu sistema.
Atenção! Entenda que estas pastas não farão parte do Sistema.
Utilize os botões para renomear e excluir (respectivamente) as pastas do seu projeto.
As pastas criadas sempre serão dispostas em ordem alfabética. Se você desejar estabelecer uma ordem
cronológica utilize algarismos numéricos no início do nome das pastas (ex. 1_Tabelas, 2_Cadastros,
3_Consultas, etc).
Não é propósito deste curso descrever detalhadamente as funcionalidades do ScriptCase, para isso você
deverá baixar o Manual do Scriptcase no site
http://downloads.scriptcase.net/downloads/v5/manual/pt_br/pdfhelp_pt_br.pdf, ele é bastante completo e
detalhado.
51
2012
4.1.5. Montando a Segurança do Nosso Sistema.
Como foi dito anteriormente, nosso sistema precisa de algumas funcionalidades que estabeleçam segurança.
Isso já foi discutido no Capítulo – Segurança. Com base na nossa modelagem vamos implementar nosso
esquema de segurança iniciando pelo cadastro de usuários.
Click na pasta Segurança para que as aplicações a serem criadas fiquem depositadas nesta pasta.
A seguir click no botão (Nova Aplicação) localizado na barra de Ferramentas.
Defina:
a) Tipo – Único registro;

b) Conexão – conn_mysql;
c) Tabela – usuarios;
d) Nome – form_usuarios;
e) Click no botão
Criada a aplicação, execute-a clicando no botão (Executar) localizado na barra de tarefas e teremos a
seguinte tela.
52
2012
Pela tela apresentada pode-se notar que nossa tabela de usuários já está populada com os dados do
Administrador do Sistema – todo esquema de segurança precisa ser populado com pelo menos um usuário, o
administrador, e isso foi feito durante a Modelagem do nosso Banco de Dados.
53
2012
Todos os campos desta tabela (apresentados na figura anterior) foram descritos no capítulo Segurança, em
caso de dúvida reveja-o.
Faremos agora uma personalização desta aplicação.
O primeiro passo da nossa personalização será criar um banco de idiomas.
Criando o Banco de Idiomas.

O SC cria aplicações em vários idiomas (a nossa será disponibilizada em três: português, inglês e espanhol)
isso só é possível porque é criado um banco de idiomas que conterá todas as variáveis que necessitem de
labels para serem apresentados pelo sistema.
O conjunto de labels mais importante é o nome dos campos das nossas tabelas, e para criarmos este banco
utilizaremos dois passos:
Passo 1 – Criação do Dicionário de Dicionário de Dados.
Click no item Ferramentas do menu principal e escola a opção Dicionário de Dados.
Defina:
a) O nome do dicionário (treinamento). Este nome não poderá conter espaços nem caracteres
especiais;
b) Descreva o dicionário;
c) A conexão (conn_mysql);
d) Click no botão
54
2012
A seguir o SC disponibilizará uma tela contendo todas as tabelas referentes ao nosso banco de dados
(treinamento).
Selecione todas as tabelas clicando no botão e a seguir click no botão .
55
2012
Deixe marcada apenas a opção Gerar índices nos arquivos de idiomas com os labels dos campos da tabela.
Se você marcar também a o opção Sobrescrever índices existentes nos arquivos de idioma, tudo que já
estiver sido criado no banco de idiomas será apagado (para as tabelas selecionadas).
A seguir click no botão
Criado o Dicionário de dados, faremos agora a atualização da tabela de idiomas (tabela interna do nosso
projeto, gerado pelo (SC).
Passo 2 – Atualização da tabela de idiomas.
Click no item Ferramentas do menu principal e escola a opção Reginalidade -> Idiomas.
Começaremos atualizando a tabela usuários. Selecione tbe_usuarios.
56
2012
57
2012
Atualize os labels dos campos.
58
2012
Click no botão .
Esta tarefa terá que ser repetida para todos os idiomas e todas as tabelas do sistema.
Se você executar as aplicações já geradas (menu, form_clientes, grid_clientes e form_usuarios) observará

que os labels dos campos não sofreram qualquer alteração, isso porque o banco de idiomas foi gerado após
as aplicações terem sido criadas.
Para que seus labels sejam atualizados com menos esforço possível, basta que deletemos as aplicações
criadas e as criemos novamente. Isso nem sempre é conveniente, mais adiante veremos o motivo.
Caso desejemos alterar algum label, de alguma aplicação já criada, basta alterarmos no banco de idiomas e
re-gerar a aplicação. Isso porque o banco foi criado antes da aplicação.
Vamos agora apagar todas as aplicações criadas e a seguir recriá-las de forma que os labels criados no banco
de idiomas sejam incorporados automaticamente.
Marque todas as aplicações e click na opção DELETAR, conforme mostrado na figura acima.
Agora crie a nova aplicação, tipo formulário, para a tabela usuários, conforme foi mostrado no tópico - Nova
Aplicação. Execute-a e teremos a seguinte tela.
59
2012
60
2012
Como você pode observar os labels já estão iguais aos criados no banco de idiomas. Se você gerar as outras
aplicações poderá notar que os labels estão todos perfeitos.
Nota Importante:
Sempre que for criar uma nova aplicação observe se o banco de idiomas para a
tabela já está criado. Isso gerará uma boa economia de tempo no desenvolvimento.
4.1.6. Criando a Aplicação Login

Agora que já foi visto como criar uma nova aplicação e como criar o banco de idiomas, criaremos a aplicação
login, que é uma aplicação do tipo Controle.
As aplicações do tipo Controle são semelhantes às aplicações tipo Formulário (porque também é uma
aplicação de entrada de dados), com pequenas diferenças, as mais importantes são:
a) Sua criação não está associada a nenhuma tabela, desta forma não aceita algumas funcionalidades
(Mestre/Detalhes, Dependências, Relacionamentos, etc);
b) Os Eventos relacionados a este tipo de aplicação são diferentes da aplicação Formulário;
Crie uma nova aplicação tipo Controle, conforme figura abaixo.
61
2012
Feito isso teremos a seguinte tela:
O próximo passo agora é criarmos os campos login e senha, uma vez que esta aplicação não está
relacionada a qualquer tabela.
Click na opção Campos, a seguir Novo Campo.
Defina a criação de 2 (dois) campos.
62
2012
Informe os nomes dos campos. Esses nomes não poderão conter espaços nem caracteres especiais. E click no
botão
Criados os campos vamos personalizá-los.
Personalizando os Campos
Click no campo login para definirmos um label para ele.
63
2012
No nosso banco de idiomas, na tabela usuários, já existem os labels criados para os campos login e senha
(daquela tabela), utilizaremos estes dois labels.
Click na opção Ferramentas -> Regionalidade -> Idiomas do Menu Principal
A seguir Click na tabela usuários (tble_usuarios) cole o índice lang_usuarios_fild_login e copie para o label
do campo login da aplicação login.
64
2012
Não se esqueça de colocar as chaves ({ }), antes e depois do label, para que o PHP assuma que é uma
variável local.
Agora click no campo senha para as devidas personalizações.
Este campo precisará de três alterações:
a) O label – Proceda como no exemplo anterior;

b) Campo tipo senha – Para que não apareçam os caracteres que serão digitados neste campo;
c) Os tipos de caracteres que poderão ser digitados.
65
2012
Agora definiremos as funcionalidades desta aplicação. Isso será feito através dos Eventos.
Criando Eventos
Eventos são rotinas criadas pelo desenvolvedor para definirmos uma determinada ação. São semelhantes às
Trigers dos bancos de dados. Ou seja, sempre que acontecer isso, faça aquilo.
Click na opção Eventos
Os Eventos disponíveis para esse tipo de aplicação (Controle) são:
a) onApplicationInit – Ocorre uma vez quando o aplicativo é carregado (primeira vez);
b) onScriptinit – Ocorre sempre que a aplicação e carregada ;
c) onLoad – Ocorre na carga do formulário;

66
2012
d) onRefresh – Ocorre quando um campo força a recarga do formulário;
e) onValidate – Ocorre durante a validação de dados, após clicar no botão ;
f) onValidateFailure – Ocorre quando existe erro de validação;
g) onValidateSucess – Ocorre quando não existe erro de validação.
Não há necessidade de decorar onde ocorre determinado evento. Se você clicar e qualquer um deles, será
aberta uma tela para criação do evento e o SC lhe informará em que situação ele será executado.
Em toda aplicação login o evento a ser criado será to tipo onValidate, ou seja no momento que o usuário
clicar no botão .
A primeira coisa que faremos é limpar da sessão o perfil do ultimo usuário logado neste browser (Acesso).
Isso será feito com a função sc_reset_apl_status().
67
2012
Agora vamos limpar da sessão o perfil do ultimo usuário logado neste browser (Direitos). Isso será feito
com a função sc_reset_apl_ conf ().
Como as senhas armazenadas no banco estarão criptografadas, teremos que criptografar a senha informada
para compararmos com as que estão armazenadas.
Agora vamos proteger a aplicação de invasões do tipo SQL Injection, para isso utilizaremos a função
sc_sql_injection() sobre a variável {login}.
68
2012
Agora vamos buscar as informações no banco. Para isso montamos o seguinte comando SELECT. O SC
disponibiliza a função sc_lookup(data,$query) que armazenará na matriz (array) data o resultado da
pesquisa $query.
A seguir verificaremos:
a) Se usuário e senha não existem;

b) Se usuário está Inativo;
c) Se o Grupo de Acesso a que ele pertence está bloqueado (md5(Bloqueado) =
9d5ed678fe57bcca610140957afab571) ou não.
69
2012
d) Se é o primeiro acesso e se tem senha padrão;

e) Caso não seja o primeiro acesso, se o período de expiração da senha foi excedido.
Estando tudo correto verificaremos os atributos que o usuário tem dentro do sistema.
70
2012
Definidos os atributos, criaremos variáveis globais que serão acessadas pelas demais aplicações do sistema.
71
2012
A seguir registraremos o acesso na tabela de Logs e redirecionaremos para o menu do nosso sistema.
Para gravarmos o registro no arquivo de logs, criaremos uma função chamada de RegLogMysql() e
adicionaremos esta função à nossa biblioteca de funções, uma vez que ela será executada por todas as
aplicações do sistema.
Acrescentando uma Função (PHP) à nossa Biblioteca Pública.

Click na opção Ferramentas -> Bibliotecas do Menu Principal
72
2012
A seguir defina como uma biblioteca Pública.
Click no botão
73
2012
Digite o código abaixo.
Observações:
a) O nome da função deve estar declarado dentro da função;

b) É necessário a inclusão das tags <?php e ?> no início e no final da função (se a função for escrita
em PHP).
Ao final click no botão
Criada a função é necessário que a mesma seja incluída na aplicação login. Para tanto click na opção
Programação -> Bibliotecas -> Bibliotecas Públicas e marque a rotina criada (RegLogMysql()).
74
2012
Agora vamos executar a aplicação clicando no botão Executar localizado na Barra de Ferramentas.
Ao clicarmos no botão Executar todas as alterações executadas na aplicação serão salvas e o código
fonte é gerado automaticamente.
Esta é a tela padrão de uma aplicação tipo Controle. Está evidente que não estamos executando nenhuma
atualização, portanto vamos alterar este layout para que seja uma aplicação de login.
Personalizando o LayOut
Click na opção Layout -> Visualização e defina o Modelo Cabeçalho como sendo Elegant2 (apenas como
exemplo).
Crie agora dois novos labels (sistema e versao) no banco de idiomas (na pasta Geral), conforme exemplo
abaixo:
75
2012
Ao clicar no botão são criados os labels (lang_sistema e lang_versao).
Retorne para a aplicação login e click na opção Layout -> Cabeçalho e Rodapé, a seguir defina o título com
o novo label criado ({lang_sistema}), não se esquecendo das chaves ({}).
Agora defina um novo rodapé, conforme o exemplo abaixo:
76
2012
Execute a aplicação clicando no botão
Neste ponto a aplicação já está com layout apropriado.
O SC tem incorporado duas funcionalidades muito interessantes:
a) Mudança de Idioma;
b) Mudança de Layout.
Ambas podem ser alteradas em tempo de execução. Vamos implementá-las nesta aplicação.
Selecione a opção Barra de Ferramentas, marque os itens Idiomas e Esquemas e transfira-os para a coluna
da direita usando a .
77
2012
Por ora está pronta, mais adiante acrescentaremos mais uma funcionalidade a esta aplicação: Esqueceu a
Senha?
Agora veremos um novo tipo de aplicação – Menu.
4.1.7. Criando uma Aplicação Tipo Menu.

O SC permite a criação de dois tipos de Menus:
78
2012
a) Menu (Horizontal);
b) Menu Árvore (Vertical)
A Operacionalização de ambos é idêntica e, mesmo após criado, é possível transformar um tipo no outro e
vice-versa.
A criação de um Menu já foi discutida no tópico Nova Aplicação. Nosso foco agora será a personalização
deste tipo de aplicação.
Click no botão (Nova Aplicação) localizado na barra de Ferramentas e escolha o tipo de aplicação Menu
Click no botão
79
2012
Teremos agora que editar a aplicação menu, de forma tal que ela possa executar as aplicações geradas e sair
do sistema. Vamos lá.
Até o presente momento só temos duas aplicações criadas:
a) Cadastro de Usuários;
b) Login;
Dessa forma criaremos apenas duas opções no Menu: a) Cadastro de Usuários e b) Sair do Sistema.
Inicialmente criaremos três labels no banco de idiomas na pasta Geral (usuários, sair e logado), conforme
exemplo abaixo:
80
2012
Ao clicar no botão são criados os labels (lang_usuarios, lang_sair e Lang_logado).
Agora vamos inserir os itens no menu.
81
2012
Vamos personalizar nosso Menu.
Personalizando a Aplicação Menu

Na opção Layout marque a Exibição do cabeçalho e coloque o label {Lang_sistema} (criado anteriormente)
no título.
82
2012
Marque a Exibição do Rodapé e acrescente na Linha 1/Coluna 1 (ROD_LIN1_COL1) a string: {lang_logado}
[sm_global_nome] - [sm_global_dtlog] ** {lang_versao} - {lang_usuarios_fild_usuarios_count} - [sm_global_contador].
Esta string é composta das seguintes variáveis:
a) {lang_logado} – Label criado recentemente;

b) [sm_global_nome] – Variável global criada no evento onValidate da aplicação login e representa o
nome do usuário que está logado;
c) [sm_global_dtlog] – Variável global criada no evento onValidate da aplicação login e representa a
data em que o usuário se conectou;
d) {lang_versao} – Label criado durante a criação da aplicação login;
e) {lang_usuarios_fild_usuarios_count} – Label da tabela de usuarios e representa um contador de
acessos;
f) [sm_global_contador] – Variável global criada no evento onValidate da aplicação login e
representa a quantidade total de acessos ao sistema;
Agora iremos executar a aplicação login e a partir dela acessar o nosso menu. Se tentarmos acessar
diretamente a aplicação menu surgirão alguns erros, uma vez que algumas variáveis foram criadas na
aplicação login e não foram repassadas para o menu.
Click na pasta Home e Execute a aplicação Login, conforme mostrado na figura abaixo.
Como já foi mencionado anteriormente, a tabela de usuários já está populada com o usuário
administrador e a senha 123456 (senha padrão de todos os novos usuários).
83
2012
Veja que nossa aplicação já está tomando um aspecto mais profissional, mas vamos melhorar.
Colocaremos no Menu as funcionalidades de escolha de Idiomas e LayOut.
Na opção Configuração da aplicação Menu, marque Selecionar Idioma e Selecione Tema.

84
2012
O próximo passo é acrescentar alguns ícones nos itens do Menu.
Click na opção Itens do Menu, selecione o item usuários e click no botão para selecionar um ícone.
Click na opção Público.
85
2012
Escolha o ícone.
Click no botão localizado no final da página.
A seguir click no botão e em seguida salve as alterações clicando no botão

(localizado na Barra de Ferramentas do SC).
86
2012
Escolha um ícone para o item {sair}, repetindo o processo acima. Salve as alterações clicando no botão
(localizado na Barra de Ferramentas do SC), gere a aplicação clicando no botão e execute a aplicação
Login.
Após se logar no sistema teremos o nosso menu semelhante à figura abaixo.
87
2012
88
2012
Terminado o Layout, a próxima alteração que faremos na aplicação menu é criar um evento que registre os
acessos no arquivo de LOGs. Ou seja, sempre que um usuário acessar uma aplicação través do menu, esse
acesso será gravado na tabela logs.
Uma aplicação do tipo Menu possui apenas três tipos de eventos:
a) onApplicationInit – Ocorre uma vez quando o aplicativo é carregado (primeira vez);
b) onExecute – Ocorre quando um item de menu é selecionado;
c) onLoad – Ocorre quando o menu é carregado;
Criaremos o seguinte evento onExecute:
Comentários a respeito deste evento:
a) Linha 1 – Incluiremos a rotina RegLogMysql (criada durante a aplicação login) ao escopo da

aplicação menu. Isto porque esse tipo de aplicação não disponibiliza a biblioteca de rotinas geradas
pelo desenvolvedor.
b) Linha 2 – Atribuímos à variável local $apl o valor da variável {sc_script_name}. A variável
{sc_script_name} só é disponibilizada nas aplicações do tipo menu.
c) Linha 3 – Gravar o registro na tabela logs, através da função RegLogMysql.
Pronto, agora concluímos esta aplicação.
Se desejarmos transformar nossa aplicação em uma aplicação tipo Menu Árvore, selecione a opção
Aplicação, click em Converter Tipo de Menu e a seguir click no botão .
89
2012
Eventualmente quando se altera o tipo de menu a conexão com o banco de dados pode ser perdida,
precisamos restaurá-la. Veja abaixo como fazê-la.
Feito isso, salve as alterações clicando no botão (localizado na Barra de Ferramentas do SC), gere a
aplicação clicando no botão .
Execute a aplicação Login.
Após se logar no sistema teremos o nosso menu semelhante à figura abaixo.
90
2012
Escolha a que melhor lhe convier. Para o nosso treinamento utilizaremos o tipo tradicional (horizontal).
Daremos prosseguimento ao nosso curso criando as demais aplicações que comporão nosso esquema total
de segurança.
Durante a criação da aplicação login, no evento onValidate, fizemos menção a funcionalidade Esqueceu a
Senha?. Pois bem, criaremos agora esta aplicação que possui um recurso bastante interessante
disponibilizado pelo SC – Envio de Email.
4.1.8. Funcionalidade Esqueceu a Senha?
Sempre que o botão Esqueceu a Senha? Da aplicação login for clicado, o sistema executará as seguintes
tarefas:
a) Alterará a senha atual do usuário (esquecida) pela senha padrão (123456);
b) Enviará ao usuário (por email) a confirmação da alteração da senha (para padrão);
c) Enviará para o administrador do sistema um email, informando que o usuário fulano-de-tal solicitou
mudança de senha através do botão Esqueceu a Senha?
Essa nova aplicação será do tipo Controle, semelhante ao login.
Iniciaremos criando dois novos labels no banco de idiomas (mensagem e mens_esqueceu_senha).
O Label mensagem será:
a) Em português -> Você receberá sua<b> Nova Senha </b>no email indicado.
91
2012
b) Em espanhol -> Usted recibirá su contraseña<br>en email indicada.
c) Em inglês -> You will receive your password<br>in email indicated.
Ao clicar no botão são criados os labels (lang_mensagem e

lang_mens_esqueceu_senha).
Agora criaremos a aplicação tipo Controle -> esqueceu_senha.
92
2012
Essa aplicação solicitará o login do usuário, seu nome completo e o seu email, a seguir comparará com o
banco de usuários se as informações estão corretas. Caso estejam, enviará emails para o usuário e o
administrador do sistema. Para tanto criaremos quatro campos (uma vez que a aplicação tipo controle não
possui campos por não está associada a nenhuma tabela do nosso banco de dados).
Três campos serão do tipo Texto (usuários_login, usuários_nome, usuários_email) e um do tipo Label
(mensagem). Veja a figura abaixo.
93
2012
Click no botão .
Agora faremos a personalização dos campos, conforme figuras abaixo.
94
2012
Agora personalizaremos o layout desta aplicação, conforme a figura abaixo.
95
2012
E por fim criaremos um evento OnValidate que executará as funções descritas no escopo deste tópico. Veja
abaixo.
Na figura acima será verificado se o usuário e o seu email conferem com o banco de dados. Em caso positivo
o sistema ajustará a senha deste usuário para a padrão (123456) e enviará email para ele informando-o
deste procedimento.
96
2012
A função do SC que enviará o email é – sc_mail_send.
Suas propriedades poderão ser analisadas no manual do SC, cabe apenas a seguinte observação – para que o
PHP proceda o envio deste email é necessário que as extensões php_openssl.dll e php_snmp.dll estejam
habilitadas no arquivo php.ini (arquivo de configuração do PHP). Por padrão, estas extensões estão
desabilitadas.
97
2012
A seguir será verificado qual o email do administrador e o enviará um email informando que usuário fulano-
de-tal solicitou mudança de senha.
Finalmente, se tudo ocorreu sem problema o usuário receberá um email informando que o email foi enviado
com sucesso ou que ocorreu um erro.
98
2012
Salve as alterações clicando no botão (localizado na Barra de Ferramentas do SC) e gere a aplicação
clicando no botão .
O próximo passo é acrescentarmos um botão (Esqueceu a Senha?) na aplicação login.
Crie um label (lang_esqueceu_senha) para esse botão, a seguir edit a aplicação login, criando um Novo
Botão.
Este botão será do tipo PHP – será apenas uma rotina PHP de redirecionamento para a aplicação
esqueceu_senha. Click no botão .
99
2012
Defina o label do botão e click na opção CODIGO PHP para acrescentarmos o redirecionamento.
Feito isso, o SC disponibilizará um novo botão (esqueceu_senha) na barra de ferramentas da aplicação.
100
2012
Salve as alterações clicando no botão (localizado na Barra de Ferramentas do SC), gere a aplicação
clicando no botão e execute-a.
Essa é a aplicação pronta. Clique no botão .
Se tudo estiver correto o usuário verá a seguinte mensagem:
101
2012
E receberá um email, conforme modelo abaixo.
Agora que já temos a aplicação login bem definida, retornaremos a aplicação de cadastro de usuários
(form_usuarios) para personalizá-la.
Antes de iniciarmos a personalização desta aplicação, utilizaremos um recurso do SC para definirmos valores
padrões (cabeçalhos, rodapés, bibliotecas, etc) para as aplicações criadas.
102
2012
4.1.9. Valores Padrões.
No menu principal click na opção Projetos -> Valores Padrões.
Todos os valores atribuídos nesta sessão serão utilizados nas novas aplicações a serem criadas, por esse
motivo esse é um dos passos iniciais para construção de um projeto.
Nós estabeleceremos modelos para:
a) Quantidade de registros na paginação (padrão = 15) – alterar para 20;

b) Campos obrigatórios – Exibir mensagem (padrão = Sim) – alterar para Não;
c) Templates (Formulários, Consulta e Filtro)
 Cabeçalho - Line;
 Rodapé – Elegant
Linha 1 / Coluna 1 -> {lang_logado} [sm_global_nome] - [sm_global_dtlog] **
{lang_versao} - {lang_usuarios_fild_usuarios_count} - [sm_global_contador]
Linha 1 / Coluna 2 -> sys__NM__br.png
d) Bibliotecas – Ativar RegLogMysql.php
e) Alinhamento dos campos na consulta – Datas (meio)
103
2012
104
2012
4.1.10. Personalizando uma Aplicação do tipo Formulário.

A personalização de uma aplicação é algo muito pessoal, neste tópico abordaremos uma personalização
onde possamos aplicar o maior número possível de funcionalidades do SC, para esse tipo de aplicação.
Na construção da nossa aplicação form_usuarios obtivemos a seguinte tela (figura abaixo).
105
2012
A intenção é deixá-la com os seguintes aspectos:
106
2012
107
2012
108
2012
LayOut
Iniciaremos elaborando um novo layout, para tanto criaremos 5 novos blocos (endereço, documentação,
acesso, observação e usuarios_x_grupos) mas antes criaremos 3 labels (lang_documentacao, lang_acesso e
lang_grupo_usuario). O processo de criação dos labels já foi amplamente discutido anteriormente.
Veja figura abaixo:
109
2012
110
2012
Agora habilitaremos a exibição do Rodapé (por padrão o SC não habilta esta exibição).
Feito isso, iremos distribuir os campos pelos blocos recém criados, de acordo com as telas do formulário
mostradas anteriormente.
Posicionamento dos campos.

Click na opção Posicionamento dos campos.
E teremos a tela.
111
2012
A caixa da esquerda mostra os campos que não farão parte do formulário e a direita os que serão exibidos
no formulário.
Retiraremos os campos:
a) usuarios_id – Campo auto-incrementável pelo DB;

b) usuarios_senha – Todos os usuários recém criados receberão uma senha padrão (123456);
c) usuarios_ultima_troca – Data da última troca da senha, para os novos usuários será a data de
cadastro;
d) usuarios_dtcad – Data e hora do momento do cadastro.
Agora distribuiremos os campos nos blocos:
112
2012
113
2012
O bloco usuarios_x_grupos será preenchido oportunamente uma vez que o seu conteúdo não será um
campo, e sim um relacionamento do tipo N para N.
Agora, seguindo uma cronologia, atribuiremos valores aos campos que não fazem parte do formulário,
conforme figura abaixo.
Obrigatórios
Agora definiremos os campos obrigatórios.
Com base no esquema de segurança fazem-se obrigatórios os seguintes campos:
a) usuarios_id;
b) usuarios_login;
c) usuarios_nome;
d) usuarios_cpf;
e) usuarios_situacao;
f) grupo_acesso;
g) perfil_acesso;
h) perfil_acesso_agenda;
i) usuarios_periodo;
j) usuarios_ultima_troca;
k) usuarios_senhapadrao;
l) usuarios_dtcad;
m) usuarios_senha;
n) usuarios_email;
o) prop_reg;
p) prop_agd;
114
2012
Chave única
Por definição usuários_id é a chave primária, conseqüentemente única, desta forma acrescentaremos os
campos usuários_login e usuários_cpf ao rol.
115
2012
Campos
O próximo passo será definir as características dos campos.
Campo Tipo Características

usuarios _id Texto
usuarios_situacao Select Ativo / Inativo
clientes_id Select Tabela de clientes
usuarios_cep Texto Máscara - ##.###-###
usuarios_endereco Texto
usuarios_compl Texto
usuarios_bairro Texto
usuarios_municipio Texto
usuarios_uf Texto
usuarios_pais Texto BR
usuarios_cpf CPF
usuarios_rg Texto
usuarios_celular Texto Máscara – (##) ####.####
usuarios_fone Texto Máscara – (##) ####.####
usuarios_email Email
usuarios_login Senha Caracteres permitidos – letras, números e
ponto
grupo_acesso_id Select Tabela grupo_acesso
perfil_acesso_id Select Tabela perfil_acesso
prop_reg Select Tabela grupo_acesso
prop_agd Select Tabela grupo_acesso_agenda
perfil_acesso_agenda Select Tabela perfil_acesso_agenda
usuarios_count Número 0
usuarios_periodo Radio Nunca – 999999999
30 dias – 30
60 dias – 60
90 dias – 90
120 dias – 120
usuarios_senhapadrao Radio Sim – 0
Não – 1
116
2012
usuarios_observ Editor HTML Altura - 400
Faremos uma abordagem apenas dos campos que apresentem uma forma diferenciada de configuração.
usuarios_situacao – Tipo Select (Manual) – Ativo / Inativo
Observa-se que o label do campo foi adicionado automaticamante.
117
2012
É importante usar o Título/Navegação nos campos tipo Select, isso forçará o usuário excolher uma opção ao
invés de selecionar a primeira opção do select (que nem sempre será a opção desejada).
clientes_id – Tipo Select (Automático) – Tabela de Clientes
118
2012
Selecione a opção Automático e click no link Construção do Select.
Escolha a tabela clientes.
119
2012
Selecione o campo clientes_sigla como Campo Exibição e click no botão
Feito isso você terá a seguinte tela.
Preciso agora incluir uma cláusula WHERE, utilizando a função PermiteAcesso discutida no capítulo
Segurança, para definir quais clientes o usuário terá acesso para efetuar a sua escolha.
120
2012
A variável global [sm_global_login] foi criada durante na aplicação login. Toda variável global no SC vem
sempre entre cochetes ([]). Por se tratar de uma variável do tipo texto deverá estar entre aspas simples (‘
‘).
O parâmetro prop_reg refere-se ao proprietário do registro na tabela clientes.
usuarios_cep – Tipo Texto ou CEP.
O SC possui uma funcionalidade para tratamento de campos específicos (CPF, CNPJ, CEP, etc). Esta
funcionalidade será oferecida na escolha do tipo de campo. Para determinação de campos do Tipo – CEP o
SC utiliza uma base de dados oficial que é atualizada periodicamente (anualmente). Na grande maioria das
vezes – posso afirmar que mais de 90% - esta base de dados é corrompida durante a transmissão (plana)
para o ambiente de produção e existem duas maneiras para solucionar este problema :
a) Compactando esta base antes da transmissão, enviando-a e descompactando-a no destino

(produção). Os arquivos compactados são fornecidos em anexo, no material deste treinamento.
b) Para fazer a descompactação no ambiente de produção é necessário que se tenha uma conta de
acesso à pasta de produção e nem sempre isso é possível (por questões de segurança). Desta forma,
para resolver este problema, nós importamos esta base de dados para o nosso banco de dados
(tabela - cep) e solucionamos definitivamente a questão.
Veremos como proceder nas duas formas.
a) Utilizando o Tipo – CEP nativo do SC.
121
2012
A seguir defina os campos da sua tabela de usuários que correspondem aos parâmetros que serão passados
da base de dados do SC.
No nosso caso teremos algo assim:
122
2012
b) Utilizando o Tipo – Texto (desenvolvido por nós).
Alteraremos a Máscara de Exibição - ##.###-###
E criaremos um Evento Ajax.
O evento Ajax ocorre sempre que alguma ação é feita sobre um campo numa aplicação do tipo
formulário/controle. Os seguintes eventos estão disponíveis com o ScriptCase.
onChange - Este evento ocorre quando o campo tem o foco e o valor do campo é mudado e o foco é
direcionado para outro objeto.
onClick - Este evento ocorre quando o campo é clicado.
123
2012
onBlur - Este evento ocorre quando o campo tem o foco, o valor do campo não é alterado e o foco é
direcionado para outro objeto.
onFocus - Este evento ocorre quando o campo tem o foco.
Defina o campo usuarios_cep para criação do evento
Escolha o tipo de evento onChange e click no botão . Este evento será executado sempre
que o campo for atualizado.
124
2012
Acrescente o código abaixo.
usuarios_cpf – Tipo - CPF
Outro tipo de campo especial disponibilizado pelo SC (CPF ou CPF e CNPJ).
125
2012
Este campo também merece uma atenção especial. Nós não desejamos que dois CPFs iguais sejam incluídos
no nosso cadastro de usuários, comprometendo nosso esquema de segurança. Desta forma criaremos mais
um evento Ajax que verificará a existência de outro CPF, igual ao que está sendo digitado, em nossa base.
Crie o evento e acrescente o código abaixo.
126
2012
usuarios_login – Tipo – Texto
Determine os tipos de caracteres que poderão ser digitados.
Também não desejamos que dois logins iguais sejam incluídos no nosso cadastro de usuários,
comprometendo nosso esquema de segurança. Desta forma criaremos mais um evento Ajax que verificará a
existência de outro login, igual ao que está sendo digitado, em nossa base. Esse tipo de checagem pode ser
feita diretamente no banco de dados, criando uma chave única para este campo, porém nossa intenção é
criarmos uma situação que não haja necessidade de digitarmos o último campo para identificarmos esta
duplicidade.
127
2012
128
2012
usuarios_email – Tipo Email.
Outro tipo de campo especial disponibilizado pelo SC (Email). O ser digitado este campo o SC verifica se a
nomenclatura corresponde a um endereço de email. Ele não verificará se o email é válido.
grupo_acesso_id – Tipo Select (Automático) – Tabela de Grupos de Acesso
Este campo definirá qual grupo de acesso o novo usuário pertencerá, este assunto já foi discutido no capítulo
segurança. Seu processamento é idêntico ao campo, alterando-se apenas a construção do select de consulta.
Veja abaixo.
129
2012
usuarios_periodo – Tipo Rádio (Manual) – Nunca (999999999), 30 dias (30)
130
2012
usuarios_senhapadrao – Tipo Rádio (Manual) – Sim (0), Não (0)
131
2012
Aqui também precisaremos de um tratamento especial. Veja, as aplicações do tipo Formulário são utilizadas
tanto para cadastrar um novo registro, como para alterar registros existentes. Neste campo especialmente,
durante a alteração de um registro, precisamos setar a senha para a condição de padrão (123456) ou não e
lembre-se que nossas senhas são criptografadas. Assim sendo, criaremos novo evento Ajax para checarmos
esta condição e criptografar a senha padrão.
usuarios_observ – Tipo – Editor HTML
Outro tipo de campo especial disponibilizado pelo SC (Editor HTML).
132
2012
Eventos
Antes de definirmos alguns eventos discutiremos algumas funcionalidades do formulário form_usuarios.
a) Após inclusão/alteração do registro criptografar a senha padrão;

b) Após a inclusão criar um grupo de acesso a agenda para o novo usuário;
c) Após a inclusão definir o perfil de acesso a agenda do usuário;
d) Incluir o administrador no perfil de acesso a agenda do administrador o perfil do novo usuário. Esta
ação é opcional se você desejar que o administrador do sistema tenha acesso a todos os perfis de
agenda;
e) Registrar os logs das ações executadas (inclusão,alteração ou exclusão).
Os Eventos disponíveis para esse tipo de aplicação (Formulário) são:
OnInit - Este evento é executado ao carregar a aplicação;
OnRefresh - Este evento é executado ao recarregar a pagina da aplicação;
Onvalidate - Este evento e executado ao clicar nos botões de validação (OK,Alterar, incluir, Excluir, Filtrar)
dependendo da aplicação utilizada. No caso de Formulário os V botões são: Incluir, Alterar e Excluir;
OnBeforeInsert - Este evento é executado antes da inserção do registro;
OnAfterInSert - Este evento e executado após a inserção do registro; `
OnBeforeUpdate - Este evento e executado antes da atualização do registro;
OnAfterUpdate - Este evento e executado após a atualização do registro;
OnBeforeDelete - Este evento é executado antes da exclusão do registro;
OnAfterDelete - Este evento é executado após a exclusão do registro;
133
2012
OnLoad - Este evento ocorre quando a pagina é carregada. EX.: ao navegar de um registro para outro; ao
clicar nos botões ( novo, inserir, anterior etc.), ao recarregar a página, etc.
Assim sendo, por ordem cronológica, criaremos os seguintes eventos.
onValidate
O evento onValidate ocorrerá sempre que o formulário for submetido (inclusão, alteração ou exclusão), no
caso específico ele verificará se o botão foi clicado. Se for clicado não altere a senha do usuário
(para que não haja criptografia da senha que já está criptografada), se não será responsável pela criptografia
da senha.
Click na opção Eventos, a seguir onValidate.
A seguir digite o código abaixo.
134
2012
onBeforeInsert
O evento onBeforeInsert ocorrerá antes da inclusão de novo registro e será responsável pela criptografia da
senha senha padrão (123456), uma vez que todo novo usuário sempre receberá a senha padrão (123456).
Click na opção Eventos, a seguir onBeforeInsert.
135
2012
onAfterInsert
O evento onAfterInsert ocorrerá após a inclusão de novo registro e será responsável por:
a) Criar um grupo de acesso a agenda para o novo usuário;

b) Definir o perfil de acesso a agenda do usuário;
c) Incluir o administrador no perfil de acesso a agenda do administrador o perfil do novo usuário. Esta
ação é opcional se você desejar que o administrador do sistema tenha acesso a todos os perfis de
agenda;
d) Registrar os logs das ações executadas (inclusão,alteração ou exclusão).
Click na opção Eventos, a seguir onAfterInsert.
136
2012
Comentários:
No capítulo segurança definimos que o campo prop_agd é responsável pela determinação de quem é o
proprietário do registro na tabela de agenda – esse campo aparecerá nas tabelas dos usuários e da agenda.
Para todo novo usuário cadastrado o sistema criará um perfil de acesso a agenda para esse usuário que é
correspondente ao seu nome de login.
Ao se criar o novo perfil o sistema gerará automaticamente (uma vez que o campo perfil_acesso_agenda_id
é auto incrementável nesta tabela) e este novo id só será conhecido após a inclusão do registro então, após a
inclusão faremos a leitura deste registro para identificar o respectivo id, que corresponderá ao prop_agd
deste usuário.
O código acima representa estas tarefas.
137
2012
Comentários:
Para todo novo usuário cadastrado o sistema criará um grupo de acesso a agenda para esse usuário que é
correspondente ao seu nome de login.
Ao se criar o novo grupo o sistema gerará automaticamente (uma vez que o campo
grupo_acesso_agenda_id é auto incrementável nesta tabela) e este novo id só será conhecido após a
inclusão do registro então, após a inclusão faremos a leitura deste registro para identificar o respectivo id,
que será lançado no perfil de grupo deste usuário.
Obtido este valor lança-se um novo perfil de grupo de agenda deste usuário, contendo o seu grupo e perfil
de acesso a agenda
O código acima representa estas tarefas.
Caso você deseje que o administrador do sistema tenha acesso a agenda dos novos usuários então digite o
código abaixo.
138
2012
Comentários:
O código acima é responsável pela gravação dos logs da nova inclusão.
onBeforeUpdate
O evento onBeforeUpdate ocorrerá antes da alteração de um registro e será responsável pela consulta ao
registro antes da alteração. O resultado desta consulta será armazenado em um array que será comparado
às alterações efetuadas.
Click na opção Eventos, a seguir onBeforeUpdate.
139
2012
onAfterUpdate
O evento onAfterUpdate ocorrerá após da alteração de um registro e será responsável pela comparação da
consulta ao registro antes da alteração e após a alteração. O resultado desta comparação será registrado no
arquivo de logs.
Click na opção Eventos, a seguir onAfterUpdate.
140
2012
onBeforeDelete
O evento onBeforeDelete ocorrerá antes da exclusão de um registro e será responsável pelo registro no
arquivo de logs deste cadastro excluído.
Click na opção Eventos, a seguir onBeforeDelete.
141
2012
N-N Relations
O relacionamento n <-> n é necessário para definirmos quais os grupos de usuários que o usuário pertence
(ex: Cadastradores, Acesso Restrito, etc).
Essa é uma parte bastante especial, a tela abaixo mostrará o resultado deste relacionamento.
142
2012
Para que haja um relacionamento n <-> n entre duas tabelas é necessário que haja uma terceira tabela que
servirá de junção entre ambas. No caso específico desejaremos fazer o relaciomento n <-> n entre as tabelas
de usuarios e grupos, para isso utilizaremos a tabela usuario_grupos como junção.
Veja o modelo abaixo.
Click na opção N-N Relations, a seguir Nova Atualização.
143
2012
Identifique o campo (usuarios_x_grupos), esta identificação não poderá conter espaços nem caracteres
especiais. A seguir click no botão
A seguir você informará a tabela onde será montado select de consulta. Veja, iremos consultar quais os
grupos disponíveis para informar qual(is) dele(s) o usuário pode participar.
144
2012
O SC então montará o select necessário.
Você agora definirá o objeto de exibição, no nosso caso Duplo Select.
145
2012
A seguir definiremos qual a tabela de ligação, ou seja a tabela que receberá os novos registros –
usuario_grupos.
Agora informaremos qual o campo chave na tabela de ligação entre a tabela de junção (usuario_grupos) e a
tabela do formulário (usuarios) – no nosso caso usuarios_id.
146
2012
O próximo passo é informar a chave estrangeira da tabela de relacionamento que será atualizada com o
valor do lookup (grupos_id).
Defina o atributo de de ligação da tabela de relacionamento (prop_reg).
147
2012
Para as demais opções (Filtro, Configuração da Visualização e Configuração da Ajuda) basta clicar no botão
e por fim
Pronto agora a aplicação está totalmente configurada.
Veremos a seguira personalização de uma aplicação do tipo Consulta
4.1.11. Personalizando uma Aplicação do tipo Consulta.

As aplicações do tipo Consulta têm duas funções básicas na estrutura dos sistemas gerados pelo SC:
a) Relatórios;
b) Filtros para as aplicações do tipo Formulário.
Criaremos agora uma aplicação do tipo Consulta para a tabela usuário. Para tanto click no botão (Nova
Aplicação) localizado na barra de Ferramentas.
Defina a tabela (usuarios).
148
2012
utilizar o nome padrão utilizado pelo SC (grid_usuarios).
Considerações:
O SC disponibiliza um query que contém os campos que poderão ser exibidos na consulta. Antes de criar a
aplicação faremos uma personalização nesta query para que nos sejam disponibilizados apenas os campos
que nos interessam e os respectivos relacionamentos com outras tabelas (ex: clientes_id, grupo_acesso_id,
etc).
Exemplo:
Os campos que me interessam nesta consulta são: id, login, nome, CPF, celular, email, situação, sigla do
cliente, grupo de acesso, perfil de acesso, período de troca de senha, data da última troca da senha, se a
senha padrão está setada e quem é o proprietário do registro. A escolha destes campos obedeceu a critérios
técnicos (sob o prisma do administrador do sistema). Desta forma, nossa query seria conforme a figura
abaixo.
149
2012
SELECT
u.usuarios_id,
u.usuarios_login,
u.usuarios_nome,
u.usuarios_cpf,
u.usuarios_celular,
u.usuarios_email,
u.usuarios_situacao,
c.clientes_sigla,
ga.grupo_acesso_descricao,
pa.perfil_acesso_descricao,
u.usuarios_periodo,
u.usuarios_ultima_troca,
u.usuarios_senhapadrao,
u.prop_reg
FROM
usuarios as u,
clientes as c,
grupo_acesso as ga,
perfil_acesso as pa
WHERE
c.clientes_id = u.clientes_id AND
u.grupo_acesso_id = ga.grupo_acesso_id AND
u.perfil_acesso_id = pa.perfil_acesso_id AND
PermiteAcesso('[sm_global_login]',u.prop_reg) = 'Sim'
ORDER BY
u.usuarios_nome
Substitua esta query pela sugerida pelo SC
150
2012
Como nós desejamos que o usuário visualize apenas os registros permitidos pelo seu grupo de acesso,
incluiremos na cláusula where a função PermiteAcesso (já discutida no capítulo segurança)
Click no botão
Posicione todos os campos para serem exibidos na consulta.
151
2012
Agora na opção Exportação habilite as opções PDF Configurável e Resolução do PDF. Isto porque se você
desejar exportar para um arquivo PDF e a quantidade de colunas escolhidas exceder o tamanho do papel (ex:
A4), poderá configurar o relatório em tempo de execução.
Na opção Ordenação, click no botão
152
2012
Se isso não for feito, os campos que não constavam do relatório, antes de efetuarmos o Posicionamento dos
Campos, não poderão ser submetidos à ordenação na grid.
Na opção Campos altere o tipo do campo usuarios_cpf de Texto para CPF
Altere a Máscara de Exibição do campo usuarios_celular para (##) ####.####
153
2012
Altere o tipo do campo usuarios_email de Texto para E-mail
Na opção Layout -> Cabeçalho & Rodapé habilite a exibição do rodapé e acrescente o label
{Lang_tble_usuarios} ao título do cabeçalho.
154
2012
Na opção Detalhes -> Cabeçalho acrescente o label {Lang_tble_usuarios} ao título do cabeçalho e altere as
variáveis do cabeçalho conforme a figura abaixo.
Na opção Aplicação -> Navegação defina a URL de Saída como sendo a aplicação menu e habilite a opção
Fechar Janela, conforme a figura abaixo.
155
2012
Agora criaremos uma ligação do tipo Aplicação com a aplicação form_usuarios, veja as figuras seguintes.
156
2012
157
2012
Existe outra forma de efetuar ligações entre aplicações, logo mais adiante veremos outra forma. Por ora está
pronta nossa aplicação de Consulta.
Iremos agora gerar todas as aplicações criadas e verificar o resultado. Proceda como as figuras abaixo.
158
2012
Se tudo ocorreu sem problemas você verá a seguinte tela.
Agora execute a aplicação login e veja se está tudo ok. O usuário inicial é administrador e a senha é 123456.
Personalizando a Ligação
Se você acessar o cadastro de usuários verá a seguinte tela:
159
2012
160
2012
Pois bem, a tela esta perfeita e é funcional, mas podemos melhorá-la.
O SC utiliza os ícones para linkar com uma tela de detalhes e com a aplicação form_usuarios
(alterações). Muitos usuários não entendem muito bem esses dois ícones, principalmente o lápis ( ) que
indica alteração do registro.
Também o botão não é uma forma muito amigável de comunicação com o usuário (digitador), até por
que em alguns casos não é algo NOVO que se quer adicionar e sim algo NOVA (questão de semântica).
Faremos uma personalização desta consulta, substituindo os ícones e o botão por algo mais
sensitivo.
Vamos lá, edite a aplicação grid_usuarios.
Iniciaremos excluindo a ligação.
Criaremos um novo botão para adicionar um novo usuário (novo_usuario). Esse botão será do Tipo – PHP, ou
seja será uma rotina php para direcionamento à aplicação form_usuarios.
Criaremos agora uma aplicação do tipo Menu para o nosso sistema. Para tanto click no botão
Altere o modo de exibição deste botão para Imagem, associe um ícone a esta imagem e click no link CODIGO
PHP para escrever a rotina de redirecionamento.
161
2012
Agora escreva o código.
Criado o botão, acesse a opção Barra de Ferramentas e posicione o botão (novo_usuario) na posição
adequada e retire o Botões do Formulário da exibição da consulta.
162
2012
Agora acrescentaremos um botão ao lado de cada registro pra efetuar a alteração dos mesmos.
Crie um novo campo do tipo – Imagem HTML (alterar_usuario).
Altere o Label (Alterar), associe uma imagem, posicione o Alinhamento Horizontal – Centralizado,
Alinhamento Horizontal – Meio e click no botão
163
2012
Marque a aplicação form_usuarios e click no botão
Ajuste os parâmetros que serão passados para a aplicação form_usuarios, click no botão ea
seguir no botão
164
2012
Na opção Posicionamento dos Campos coloque o novo botão (alterar_usuario) para o início da consulta e
click no botão
A seguir gere todas as aplicações e execute a aplicação login.
Agora você tem uma tela mais amigável.
165
2012
166
2012
Faremos agora uma nova personalização nesta consulta. Efetuaremos uma quebra por Clientes (Sigla), você
pode observar que existem usuários para dois clientes diferentes (Oops e JCM).
Edite a aplicação grid_usuarios e selecione a opção Quebras -> Posicionamento dos Campos, marque o
campo clientes_sigla.
:
Agora na opção Quebras -> Posicionamento dos Campos, altere o Separador do valor para ( )
A seguir gere a aplicação e execute a aplicação login.
Sua consulta agora está assim.
167
2012
168
2012
Pronto! Encerramos esta sessão.
4.1.12. Construindo/Alterando um Template

O processo de construção ou alteração de um template é exatamente o mesmo, uma vez que o SC trará
sempre um modelo pré-existente para que seja alterado (mesmo quando solicitado a criação de um novo) e
esse procedimento nos ajudará muito.
Nosso exemplo será a construção de uma tela de login, nada muito complicado.
Na tela atual é assim.
A deixaremos assim.
Construir um template é lento e empírico, serão necessárias algumas horas de trabalho para ajustar todos os
campos, cores, etc e uma boa dose de criatividade. Comece sempre criando sua tela, para tanto utilize um
editor gráfico de sua preferência (nós utilizamos o Corel Draw). A nossa ficou assim.
169
2012
Comentários:
a) Nossa tela foi construída inteira, 100% da tela do navegador;

b) Não coloque os campos (login, senha, etc) o SC fará isso.
A seguir acesse a opção Ferramentas -> Visualização -> Temas do menu principal do SC
Escolha um esquema que seja igual ao do seu projeto (nosso exemplo: ScriptCase5_Green) e a seguir click no
botão
170
2012
A aplicação login é uma aplicação do tipo Controle que é, como já foi mencionado no início desta apostila,
uma aplicação do tipo Formulário com características especiais (não está associada a nenhuma tabela, etc),
desta forma faremos alteração na opção Formulário do nsso novo template.
Depois de muitas tentativas e erros estabelecemos os valores que passaremos através das telas seguintes,
para cada opção do Formulário.
171
2012
172
2012
173
2012
174
2012
175
2012
176
2012
177
2012
178
2012
Feitas as alterações click no botão o SC solicitará o Local e o Nome do tema.
Agora edite a aplicação login.
Na opção Configuração faça os ajustes conforme tela abaixo. Os valores obtidos foram alcançados através
do método de tentativas e erros e aplica-se apenas ao nosso exemplo. Na construção da sua tela esses
valores certamente não serão os mesmos.
179
2012
Na opção Layout -> Blocos ajuste a quantidade de Campos/Colunas para 2.
Na opção Layout -> Visualização ajuste o Esquema para Tela_De_Login.
Na opção Layout -> Cabeçalho & Rodapé desabilite a exibição do cabeçalho e do rodapé.
180
2012
A seguir gere a aplicação e execute a aplicação login.
Sua tela de login agora está assim.
Tudo Ok?
Os exemplos acima lhe deram uma boa orientação no procedimento de técnicas avançadas do SC, existem
outras que veremos a seguir. Para exemplificá-las faremos a importação de um projeto pronto que servirá de
subsídio para os próximos passos.
181
2012
Para exportar um projeto proceda da seguinte maneira.
Saia da aplicação clicando no botão localizado na Barra de Ferramentas do SC
Selecione a opção Arquivos -> Importar Projeto no menu principal do SC.
Selecione o arquivo (compactado) a importar e click no botão
182
2012
O SC informa o nome do projeto, que você poderá alterá-lo caso já exista um projeto com o mesmo nome. A
seguir click no botão
Pronto! Agora abra o projeto (Treinamento) e gere o código fonte todas as aplicações.
Execute a aplicação login.
Execute diversos testes para entender o funcionamento da estrutura de segurança.
4.1.13. Criando/Personalizando uma Aplicação Calendário

Como vocês puderam observar a aplicação calendário (agenda) já está criada. Seu processo de criação é
muito simples, necessitando apenas que na sua tabela possua os seguintes campos: id, título, data de início,
hora de início, data final, hora final, recorrência e período. O SC fará toda montagem sem qualquer
dificuldade.
183
2012
O que nós faremos agora é:
a) Ajustarmos nosso esquema de segurança de forma tal que esta possa ser compartilhada
corporativamente;
b) Criarmos a funcionalidade de geração de múltiplas ocorrências para o mesmo evento;
c) Criarmos os logs.
Edite a aplicação agenda.
Por padrão todos os eventos gerados serão visualizados por toso os usuários do sistema e isso nem sempre é
conveniente. Utilizando a função PermiteAcessoAgenda, discutida no capítulo Segurança, a tornaremos
pessoal ou corporativa.
Na opção SQL, inclua na cláusula Where a função
PermiteAcessoAgenda(‘[sm_global_login]’, prop_agd) = ‘Sim’
184
2012
Criaremos o campo nr_recor que determinará quantas vezes este evento será replicado.
Criaremos o campo grupo_acesso para informar ao usuário quem está compartilhando aquele evento. Este
campo será do tipo Select.
185
2012
Eventos da Agenda
Crie o evento onBeforeInsert (antes da inclusão). Esto este evento informará que o usuário logado estou este
evento.
186
2012
Crie os eventos onAfterInsert (após a inclusão). Este evento fará as devidas replicações caso o número de
ocorrências seja superior a 1 e, ao final, registrará os logs.
// Lançamento das Ocorrências...
if({nr_recor} > 1)
{
if({agenda_periodo} == 'D')
{
$w=1;
$z={nr_recor}-1;
for($x = 0; $x < $z; $x++ ) {
$nova_dtinicio = sc_date_conv({agenda_dtinicio},"db_format","dd/mm/aaaa");
$nova_dtinicio = SomarData($nova_dtinicio, $w, 0, 0);
$nova_dtfim = sc_date_conv({agenda_dtfim},"db_format","dd/mm/aaaa");
$nova_dtfim = SomarData($nova_dtfim, $w, 0, 0);
$w++;
$insert_sql = "INSERT INTO agenda
(
agenda_titulo,
agenda_dtinicio,
agenda_hrinicio,
agenda_dtfim,
agenda_hrfim,
agenda_recorrente,
agenda_periodo,
agenda_descricao,
agenda_alerta,
usuarios_login,
agenda_dtcad,
prop_reg,
prop_agd
)
VALUES
(
'{agenda_titulo}',
187
2012
'$nova_dtinicio',
'{agenda_hrinicio}',
'$nova_dtfim',
'{agenda_hrfim}',
'{agenda_recorrente}',
'{agenda_periodo}',
'{agenda_descricao}',
'{agenda_alerta}',
'[sm_global_login]',
current_timestamp,
[sm_global_acesso],
{prop_agd}
)";
sc_exec_sql($insert_sql);
}
}
elseif({agenda_periodo} == 'W')
{
$w=7;
$z={nr_recor}-1;
for($x = 0; $x < $z; $x++ ) {
$nova_dtinicio = SomarData($nova_dtinicio, $w, 0, 0);
$nova_dtfim = SomarData($nova_dtfim, $w, 0, 0);
$w = $w+7;
(
agenda_titulo,
agenda_dtinicio,
agenda_hrinicio,
agenda_dtfim,
agenda_hrfim,
agenda_recorrente,
agenda_periodo,
agenda_descricao,
agenda_alerta,
usuarios_login,
agenda_dtcad,
prop_reg,
prop_agd
)
VALUES
(
'{agenda_titulo}',
'$nova_dtinicio',
'$nova_dtfim',
'{agenda_hrfim}',
'{agenda_periodo}',
188
2012
'{agenda_alerta}',
current_timestamp,
[sm_global_acesso],
{prop_agd}
)";
}
}
elseif({agenda_periodo} == 'M')
{
$w=1;
$z={nr_recor}-1;
for($x = 0; $x < $z; $x++ ) {
$nova_dtinicio = SomarData($nova_dtinicio, 0, $w, 0);
$nova_dtfim = SomarData($nova_dtfim, 0, $w, 0);
$w++;
(
agenda_titulo,
agenda_dtinicio,
agenda_hrinicio,
agenda_dtfim,
agenda_hrfim,
agenda_recorrente,
agenda_periodo,
agenda_descricao,
agenda_alerta,
usuarios_login,
agenda_dtcad,
prop_reg,
prop_agd
)
VALUES
(
'{agenda_titulo}',
'$nova_dtinicio',
'$nova_dtfim',
'{agenda_hrfim}',
'{agenda_periodo}',
'{agenda_alerta}',
current_timestamp,
[sm_global_acesso],
{prop_agd}
189
2012
)";
}
}
elseif({agenda_periodo} == 'A')
{
$w=1;
$z={nr_recor}-1;
for($x = 0; $x < $z; $x++ ) {
$nova_dtinicio = SomarData($nova_dtinicio, 0, 0, $w);
$nova_dtfim = SomarData($nova_dtfim, 0, 0, $w);
$w++;
(
agenda_titulo,
agenda_dtinicio,
agenda_hrinicio,
agenda_dtfim,
agenda_hrfim,
agenda_recorrente,
agenda_periodo,
agenda_descricao,
agenda_alerta,
usuarios_login,
agenda_dtcad,
prop_reg,
prop_agd
)
VALUES
(
'{agenda_titulo}',
'$nova_dtinicio',
'$nova_dtfim',
'{agenda_hrfim}',
'{agenda_periodo}',
'{agenda_alerta}',
current_timestamp,
[sm_global_acesso],
{prop_agd}
)";
}
}
}
190
2012
$apl = 'agenda';
$mess_executada = 'Incluir - '.{lang_tble_agenda};
$mess_realizada='<table border=1 style="padding: 0px; border-spacing: 0px; border-width:
0px;">
<tr class="scGridLabel">
<td class="scGridLabelFont">Campo
<td class="scGridLabelFont">Valor';
$i=0;
foreach ($this->nm_new_label as $campo=>$display)
{
$display=$this->Ini->Nm_lang[substr($display,1,-1)];
$mess_realizada.="<tr><td class=scGridFieldOddFont>$display<td
class=scGridFieldOddFont>".$this->$campo;
$i++;
}
$mess_realizada.='</table>';
RegLogMysql($apl,$mess_executada,$mess_realizada);
Crie os eventos onBeforeUpdate (antes da alteração). Este evento será responsável pela consulta ao registro
antes da alteração. O resultado desta consulta será armazenado em um array que será comparado às
alterações efetuadas.
Crie os eventos onAfterUpdate (após a alteração). Este evento será responsável pela comparação da
consulta ao registro antes da alteração e após a alteração. O resultado desta comparação será registrado no
arquivo de logs.
191
2012
Crie os eventos onBeforeDelete (antes da exclusão). Este evento será responsável pelo registro no arquivo
de logs deste evento excluído.
4.1.14. Registro de Logs/Acessos

Toda aplicação do tipo Formulário terá sempre quatro eventos para o registro de logs:
a) onAfterInsert.
$apl = 'aplicação';
$mess_executada = 'Incluir - '.{lang_tble_tabela};
$mess_realizada='<table border=1 style="padding: 0px; border-spacing: 0px; border-width: 0px;">
$i=0;
{
$mess_realizada.="<tr><td class=scGridFieldOddFont>$display<td class=scGridFieldOddFont>".$this->$campo;
$i++;
}
b) onBeforeUpdate;
sc_lookup(dataset,"SELECT * FROM tabela WHERE tabela_id = { tabela_id}");

$dataset_anterior={dataset[0]};
192
2012
c) onAfterUpdate;
$mess_executada = 'Alterar - '.{lang_tble_tabela};
$mess_realizada='<table border=1 style="padding: 0px; border-spasgservng: 0px; border-width: 0px;">
<td class="scGridLabelFont">Anterior
<td class="scGridLabelFont">Atual';
sc_lookup(ver_campos,"SHOW columns FROM tabela");
sc_lookup(dataset,"SELECT * FROM tabela WHERE tabela_id = { tabela_id}");
$dataset_atual = {dataset[0]};
foreach({ver_campos} as $chave => $valor )
{
if((!($dataset_anterior[$chave]==$dataset_atual[$chave])) or ($chave < 1))
{
$mess_realizada.="<tr><td class=scGridFieldOddFont>".
$this->Ini->Nm_lang['lang_tabela_fild_'.$valor[0]].
"<td class=scGridFieldOddFont>".$dataset_anterior[$chave].
"<td class=scGridFieldOddFont>".$dataset_atual[$chave];
}
}
d) onBeforeDelete.
$mess_executada = 'Excluir - '.{lang_tble_tabela};
$mess_realizada='<table border=1 style="padding: 0px; border-spacing: 0px; border-width: 0px;">
$i=0;
{
$mess_realizada.="<tr><td class=scGridFieldOddFont>$display<td class=scGridFieldOddFont>".$this->$campo;
$i++;
}
4.1.15. Segurança nas Aplicações

Um ponto forte do SC é que ele efetua o controle de sessões no php para evitar que usuários não
autorizados acessem as aplicações fora do sistema ou seja sem ter efetuado o login.
Isso é feito ativando-se o módulo de segurança em cada aplicação.
193
2012
Você poderá fazer essa ativação automaticamente em todas as aplicações utilizando um recurso bastante
interessante do SC – Edição Expressa. Vejamos
Click no item Ferramentas do menu principal e escola a opção Edição Expressa.
Você poderá escolher Todas ou selecionar as desejadas.
194
2012
Escolha a opção desejada para a edição expressa.
A seguir defina sua escolha e click no botão
195
2012
A seguir serão apresentadas as aplicações que sofreram alteração.
Atenção.
Você não poderá ativar a segurança de duas aplicações, sem as quais será
impossível acessar o sistema:
a) Login
b) Esqueceu a Senha.
Se você escolheu ativar todas as aplicações terá que editar estas duas aplicações e
desativar a segurança (em ambas). Por isso, dentro do nosso projeto, estas duas
aplicações estão na pasta Segurança -> Sem_Segurança.
196
2012
Sempre uma nova aplicação for gerada no sistema haverá a necessidade de pelo menos o administrador ter
acesso a mesma. Para tanto desenvolvemos a aplicação grid_aplicacoes que, além de ser uma consulta à
tabela aplicações, ela verificará quais aplicações foram recém criadas e dará acesso total (Inclusão,
Alteração, Exclusão e Consulta) ao administrador. Edite esta aplicação.
No evento onScriptInit poderá ser vista a rotina que fará a verificação descrita acima.
197
2012
Com essas informações vocês poderão analisar todas as demais aplicações.
4.1.16. Outras Aplicações do Nosso Sistema

Criaremos agora outras aplicações para ilustrar mais técnicas avançadas do SC.
Daremos prosseguimento ao nosso exercício 1, criando as tabelas abaixo em nosso DB. É parte integrante de
nosso treinamento um arquivo que contem script de criação de todas as tabelas do sistema (MySQL).
a) Colaboradores;
b) Fotos dos Colaboradores;
c) Funções;
d) Cargos (CBO - Classificação Brasileira de Ocupações);
e) Estado Civil;
f) Formação Acadêmica;
g) Graus de Instrução;
h) Lotação;
i) Dependentes;
j) Habilidades;
k) Habilidades dos Colaboradores.
198
2012
Após criação das novas tabelas, deveremos atualizar o nosso banco de dicionários e idiomas.
Click no item Ferramentas do menu principal e escola a opção Dicionário de Dados.
Click no dicionário já existente.
Selecione as tabelas da base de dados (aquelas que ainda não fazem parte do dicionário), marque todas e
click no botão
199
2012
Deixe marcada apenas a opção Gerar índices nos arquivos de idiomas com os labels dos campos da tabela.
Se você marcar também a o opção Sobrescrever índices existentes nos arquivos de idioma, tudo que já
estiver sido criado no banco de idiomas será apagado (para as tabelas selecionadas).
Criado o Dicionário de dados, faremos agora a atualização da tabela de idiomas (tabela interna do nosso
projeto, gerado pelo (SC).
Agora atualizaremos a tabela de idiomas.
Click no item Ferramentas do menu principal e escola a opção Reginalidade -> Idiomas.
200
2012
Atualize o banco de idiomas.
201

Idioma

Exemplo de Utiliza o para Ebook

Enviado por

Dados do documento

Título original

Direitos autorais

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Exemplo de Utiliza o para Ebook

Título original:

Enviado por

Direitos autorais:

Scriptcase – Técnicas Avançadas

Pensando nisto, a NetMake desenvolveu o ScriptCase, um ambiente de desenvolvimento de aplicações WEB

2. B anco de Dados (uma visão genérica)

No processo de desenvolvimento de qualquer sistema, a regra de negócio visa detalhar as

d) Montagem/Modelagem do Banco de dados.

g) Mantê-la em funcionamento (em produção).

Imaginemos o seguinte cenário:

Um hospital está nos contratando para desenvolver uma aplicação

Cliente: Hospital Nossa Senhora de Arapiraca

Recepcionista – Gisele Budchen, 2º grau completo, bons conhecimentos em informática, horário de

Montem uma estrutura de dados que se adapte aos nossos objetivos.

a) Tornar a sua operação mais simples possível;

Tipos de Formas Normais

a) Primeira forma normal (1NF);

Inicialmente veremos a 1NF, no decorrer do curso, havendo necessidade, veremos outras.

Para colocar na 1FN:

FUNCIONÁRIOS = {CODFUNC + NOME + CARGO}

FUNC_PROJ = {CODFUNC + PROJETO + DATAINI + DATAFIM}

OBS: A chave primária de FUNCIONÁRIOS vai ser a chave estrangeira de FUNC_PROJ.

PESSOAS = {ID + NOME + ENDERECO + TELEFONES}

PESSOAS = {ID + NOME + ENDERECO}

TELEFONES = {PESSOA_ID + TELEFONE}

PEDIDOS = {PEDIDO + CLIENTE + VENDEDOR + ATENDENTE + PRODUTO + QUANT + VALOR}

PEDIDO CLIENTE VENDEDOR ATENDENTE PRODUTO QUANT VALOR

Voltando ao nosso exercício, criaremos a seguinte estrutura de dados:

Tabela: Estado Civil

Tabela: Atendimentos (horários)

Tabela: Graus de Parentesco

Se você imaginou menos que 12 tabelas, deveremos rever alguns conceitos.

a) Obter o máximo de informação possível para a elaboração do DB;

Adotando ainda o cenário anterior, elaborem um esquema de segurança

A segurança poderá e deverá ser feita em três camadas:

a) No banco de dados – Todo DB relacional possui um forte esquema de segurança;

As boas práticas de segurança estabelecem os seguintes níveis mínimos.

Visto isso, precisaremos das seguintes tabelas:

Tabela: Grupos de Acesso (No Registro)

Tabela: Grupos (Na aplicação)

Tabela: Grupos de Aplicações (Na aplicação)

Tabela: Perfil de Acesso (No registro)

Tabela: Perfil de Grupo (Na aplicação)

a) Na tabela de usuários, acrescentaremos um campo que forçasse a troca de senha temporariamente.

Veja, foram medidas simples que ampliaram nossa margem de segurança.

Nosso banco está assim agora.

Tabela: Grupos de Acesso (No registro)

Tabela: Grupos (Na aplicação)

Tabela: Grupos de Aplicações (Na aplicação)

Tabela: Perfil de Acesso (No registro)

Tabela: Perfil de Grupo (Na aplicação)

Tabela: Grupo de Usuários (Na aplicação)

O SC oferece um utilitário muito interessante chamado de calendário (agendamento de compromissos). Esse

Tabela: perfil de Acesso da Agenda (No registro)

Tabela: Grupo Acesso da Agenda (No registro)

Tabela: Perfil de Grupo Agenda (No registro).

a) Degeneram a performance do banco;

Comentários sobre o esquema de segurança

Segurança do Registro (Acesso)

No esquema abaixo podemos observar que:

a) Cliente A tem controle sobre os registros do Cliente B, C e D;

A tabela grupo_acesso definirá cada cliente (empresa) do sistema.

A forma correta de chamar esta função é:

PermiteAcesso(‘usuario’, prop_reg) = ‘Sim’

Esta função estará sempre presente em cláusulas WHERE das querys

Por padrão nosso esquema criou dois grupos básicos:

a) Cadastradores –Acesso total às aplicações do tipo Formulário;