Projeto | Início Anterior Próximo

Definições de Projeto

Este é o local onde são feitas as definições gerais do projeto. Para fazer as definições de qual ou quais banco de dados e servidores (FTP, POP3, etc) serão usados no projeto, no canto esquerdo aparecem os links que levam às definições de Banco de dados e Servidores.
O campo Descrição serve para que o desenvolvedor da aplicação escreva um breve comentário sobre a ação a ser executada pelo componente em questão.
O campo Pacote de classes java do projeto indica em que pacote serão colocadas as classes java do projeto que o WI necessitar gerar. Ex: br.com.empresa faz com que a geração de classe Teste fique em br.com.empresa.Teste.
O campo Modelo para as Páginas indica qual o arquivo que o WI Builder tomará como modelo na hora da criação das páginas. Esse arquivo deverá ficar no diretório template relativo ao repositório de definições projeto. Se esse campo for deixado em branco o WI Builder adotará o seu modelo de página padrão.
No conteúdo da página do modelo o desenvolvedor poderá fazer uso dos identificadores |head.content| ou |body.content| que servirão de referências para o WIzard saber em que parte do modelo deverá ser incluído os conteúdos do HEAD e do BODY, respectivamente, gerados por ele.
O campo Projeto Pai (herança) indica o projeto do qual serão herdados componentes, páginas, etc. (detalhes sobre herança de projeto)
O campo Variáveis Persistentes indica como será o gerenciamento do ciclo de vida de variáveis criadas por projetos do WebIntegrator. Com esta opção marcada o ciclo de vida de variáveis segue as regras abaixo:

| ·

variáveis com prefixo tmp., combo., grid. (variáveis temporárias) são consideradas variáveis de requisição, ou seja, o tempo de vida delas é o tempo de vida de uma requisição;

| ·

variáveis com prefixo pvt. (variáveis privativas) são consideradas variáveis de sessão da aplicação, ou seja, o tempo de vida delas é o mesmo tempo de vida da sessão. Variáveis privativas apenas podem ser criadas ou terem seus valores alterados através de componentes de pré ou pós-página;

| · | variáveis com prefixos diferentes dos citados acima ou sem algum prefixo também são consideradas variáveis de sessão. Ao contrário das variáveis privativas, esse tipo de variável também pode ser criado ou ter seu valor alterado diretamente através dos métodos GET e POST.

Com essa opção desmarcada o ciclo de vida de variáveis segue as regras abaixo:

| ·

variáveis com prefixo app. são consideradas variáveis de contexto da aplicação, ou seja, o tempo de vida delas é o mesmo tempo de vida da aplicação. Esse tipo de variável apenas pode ser criada ou ter seu valor alterado através de componentes de pré ou pós-página;

| · | variáveis com prefixo pvt. são consideradas variáveis de sessão da aplicação, ou seja, o tempo de vida delas é o mesmo tempo de vida da sessão. Assim como as variáveis de contexto da aplicação, essas variáveis apenas podem ser criadas ou terem seus valores alterados através de componentes de pré ou pós-página;

| · | variáveis com prefixos diferentes dos citados acima ou sem algum prefixo são consideradas variáveis de requisição, ou seja, o tempo de vida delas é o tempo de vida da requisição que as gerou.

O campo Diretório de Logs indica aonde devem ser gerados os logs do projeto como webintegrator.log, dbtime.log, builder.log, etc. Se o campo estiver vazio será assumido o WEB-INF/logs do projeto. Ao alterar o valor desse campo será necessário efetuar o restart do projeto ou pelo builder ou pelo manager do tomcat.
O campo Página com lógica comum a todas serve para indicar uma página que terá o seu pré executado antes do pré de qualquer página assim como o pós. Exemplos de uso: autorização de usuários (colocado no pré), validação de WIToken (colocado no pós). Qualquer outra coisa que você quer que seja executada em todas as páginas você coloca nessa página e a indica no projeto. O desenvolvedor pode controlar a execução dos elementos através da condição usando a variável |wi.page.id| para identificar a página que está sendo executada.
O campo JSP com maior compatibilidade faz com que as páginas JSP geradas sejam mais compatíveis com outros ambientes (Ex: WebSphere). Quando essa opção está selecionada não serão incluídas as chamadas JSTL e os parâmetros passados pelos componentes do WI terão o "\r" removido e o "\n" transformado em espaço. Ao alterar essa opção no projeto será necessário regerar todos os arquivos JSP.