Web Dynpro - Aula 02

Desenvolvimento Pessoal
Agenda
Contexto
Exercícios e recapitulação.
Web Dynpro Controllers.
Contexto
Definindo a interface com o usuário

Web Dynpro
Controllers
Os controladores contém todo o código fonte de uma aplicação Web Dynpro.
They contain all data - stored as controller attributes or as attributes belonging to

context elements.
Possuem também todos os dados, armazenados na forma de atributos ou pertencendo

a elementos do contexto.
Controlam a manipulação de eventos e a navegação.
É de fundamental importância entender como os controladores são definidos e que tipo

de elementos eles fornecem.
Os controladores são o coração de uma aplicação Web Dynpro

Web Dynpro
Controllers
Tipos de controladores (1/3)
Component controller
• Existe somente um por componente Web Dynpro.
• Pode ser visualizado pelos demais controladores, uma vez que é global.
• Não possui elementos de interface visuais.
Custom controllers
•Elementos opcionais em um componente.
•Definidos no projeto do componente, sendo usados para encapsular funções

específicas do controlador do componente
•São instanciados automaticamente pelo framework, sendo a ordem de

instanciação indefinida.
•O código de um controlador customizado não pode ser dependente da existência

de nenhum outro.
Web Dynpro
Controllers
Configuration controllers
• Tipo especial de controlador customizado.
• Somente necessário quando o compoennte possui funções muito específicas de

configuração e personalização.
• Podemos ter somente um controlador de configuração em um cmponente.
• Qualquer controlador pode acessá-lo, mas este não pode acessar nenhum outro
(“somente leitura”).
View controllers
• Cada visão consiste de um layout e de um controlador.
• Gerencia lógicas específicas da camada de visão, tais como validação de entrada dos
usuários e manipulação de ações (“clique no botão”).
Web Dynpro
Controllers
Window controllers
• Cada janela possui somente um controlador.
• Pode conter o código responsável por gerar a passagem de parâmetros.
• Seus métodos podem ser chamados dos métodos de inbound plug da janela.
Web Dynpro
Controllers
Em tempo de execução, todas as instâncias de controladores são únicas em relação a
seus componentes pais -> SINGLETON
Encapsular uma view mais de uma vez em uma view asembly não é então possível.
O contexto e o atributos de cada controlador são privados ao menos que outro

controlador explicitamente o declare em seu contexto.
Um controlador de visão não pode ser declarado em outro. O contexto e os atributos de

uma visão são sempre privados.
Web Dynpro
Controllers
Web Dynpro
Controllers
Aplicações Web Dynpro são do tipo stateful.
O ciclo de vida dos controladores não está limitado ao tempo de processamento do

código do programa ou da interface do usuário.
O ciclo de vida vai variar de acordo com o tipo do controlador:

Component controller
• Dura enquanto o componente estiver ativo.
• Quando iniciados uma aplicação, o controlador do componente é

instanciado.
Custom controllers
• São instanciados no momento que chamamos um método pela primeia vez.
• Não podem ser excluídos explicitamente.
Configuration controllers
• É o primeiro a ser instanciado em um componente.
• Seu ciclo de vida é o mesmo do componente.

Web Dynpro
Controllers
View controllers
• São instanciados somente quando o primeiro método é chamado.
• O ciclo de vida pode ser controlado através das propriedades da visão:

o Se “framework controlled” estiver selecionado, o controlador será
excluído com o componente.
o Se “when visible” estiver selecionado, a instancia será excluída assim que
a visão não fizer mais parte do “view assembly”.
Window controllers
• São instanciados somente quando o primeiro método é chamado.
• Isto ocorre quando:

o iniciamos uma aplicação;
o adicionamos a interface view a um componente pai;
o chamamos uma janela como um popup;
• As instâncias de controladores de janelas não podem ser excluídos

explicitamente.
Web Dynpro
Controllers Elementos comuns a todos os controladores
Existem entidades comuns a todos os controladores
Cada controlador tem seu próprio contexto.
O nó raiz é automaticamente criado. Os demais nós devem ser estaticamente

definidos ou dinâmicamente no código fonte.
Existem métodos standards nos controladores, que são sempre chamados em uma
determinada sequência. Estes são chamados de “hook methods” ( métodos
encadeados).
Para cada tipo de controlador irá existir um conjundo de hook methods.
Entretanto, dois métodos são comuns a todos os controladores:

• wddoinit(): Executado quando a instância é criada.
• wddoexit(): Executado quando a instância é excluído.
Estes métodos são executados somente uma vez durante o ciclo de vida do
controlador
Web Dynpro
Na aba métodos, é possível a inclusão de mais métodos.
Atributos não ligados a nenhum elemento UI devem ser definidos na aba atributos,
sendo visíveis em todos os métodos do controlador.
Existem dois atributos pré-definidos:

• WD_THIS: referência ao controlador.
• WD_CONTEXT: referência ao contexto.
Os métodos dos controladores podem acessar módulos de função, classes, BAPIs, etc.
Web Dynpro
Web Dynpro
Controllers Componente e customizados: entidades especiais
Eventos podem ser definidos nestes dois tipos de controladores.
Posso ter métodos que irão tratar estes eventos em qualquer outro controlador
(visão, janela).
Exemplo: vou chamar um método no controlador de uma visão após o

processamento no controlador do componente acabar. Para tal o método do
controlador da visão é definido para tratar um evento disparado pelo controlador do
componente.
Controlador do componente Controlador do visão
...
... Evento Método x.
Raise X X Message ‘oi’
Fimmétodo.
Web Dynpro
Se dois ou mais métodos forem subscritos a um mesmo evento, a ordem que serão
executados é indefinida.
Os métodos, os elementos de contexto e os eventos podem ser marcados como

“interface”. Esta acção faz com que os mesmos possam ser acessados por outros
componentes, através da interface controller.
IMG CHECKBOX
Web Dynpro
Web Dynpro
Controllers Controladores de visões: entidades especiais
O controlador da visão pode ser encarado com uma entidade do Web Dynpro
desenhada para tratar todos os aspectos dos dados exibidos e da interação com o
usuário.
Navigation Plugs: eventos, com seus respectivos tratadores, criados para permitir a
navegação entre diferentes controladores.
Um evento de navegação é levantado quando um outbound plug é disparado.
Um inbound plug é um handler para estes eventos de navegação.

Web Dynpro
Além dos atributos já apresentados, os controladores de visão possuem o seguinte,

também prédefinido: WD_COMP_CONTROLLER.
WD_COMP_CONTROLLER é uma referência ao controlador do componente, podendo

ser usada para acessar funções do mesmo.
O atributo WD_COMP_CONTROLLER só irá existir se o controlador do componente

estiver declarado em properties.
Web Dynpro
Web Dynpro
Controllers Controladores de janelas: entidades especiais
Muito parecidos com os controladores de visão.
Podem ser entendidos como um controlador de visão sem elementos de interface

com o usuário.
Todas as visões que serão apresentadas em uma aplicação devem estar

incorporadas a janela que será acionada pelo componente.
Possuem também inbound e outbound plugs. Estes podem ser utilizados para
navegações entre componentes (devem estar marcados como interface).
Web Dynpro
Controllers Controladores de janelas: entidades especiais
Contexto
Dados utilizados para controlar os elementos de interface são armazenados no
contexto do controlador.
O contexto é uma estrutura hierárquica, podendo ser definida estaticamente ou

dinâmicamente em tempo de execução.
Um contexto é formado por nós e atributos, arrumados hierarquicamente.
Todo controlador possui um e somente um contexto.
Os dados do contexto de cada controlador respeitam o ciclo de vida do mesmo.

Contexto
Através do context mapping informações contidas no contexto do controlador do
componente, ou até mesmo de controladores customizados, podem ser facilmente
manipuladas.
Esta técnica possibilita que dois ou mais controles possam acessar a informação em
tempo de execução.
Novamente, vale ressaltar que não é possível compartilhar os dados do contexto de uma
visão.
Os nós e atributos são organizados de maneira hierárquica, existindo sempre um nó raiz

(context root node).
O nó raiz é criado automaticamente quando o controlador é inicializado, não podendo ser

excluído.
Contexto
Contexto
Um nó é uma abstração, utilizado pelo mecanismo de runtime do fremework em
tempo de execução.
Os nós podem conter atributos ou outros nós como filhos.
O nome de um nó deve ser único no contexto.
Um atributo do contexto é uma entidade que não possui filhos.
Um atributo sempre está associado a um nó, mesmo que este seja o nó raiz.
Elemento: entidade criada em tempo de execução para representar uma instancia do

nó.
Contexto
Nós e atributos em tempo de execução
Contexto
Propriedades dos nós
Quando projetamos a hierarquia do contexto estamos definindo a estrutura de

memória que será criada em tempo de execução.
Cardinalidade:
Mínima: 0 ou 1
Máxima: 1 ou n
Temos então quatro combinações possíveis:

0..1
0..n
1..1
1..n
Mesmo na cardinalidade máxima de 1, um elemento é criado em tempo de

execução.
Contexto
Contexto
Contexto
Contexto
Seleção conduzida
Uma coleção de elementos de um nó pode seracessada através de um índice.
A seleção conduzida de um nó do contexto aponta ou para :

uma única instância de um elemento de um nó ou;
se nenhum elemento estiver selecionado, para a constante
IF_WD_CONTEXT_NODE=>NO_SELECTION.
A propriedade “Initialize Lead Selection “ habilita a seleção conduzida no

framework.
O primeiro elemento em uma coleção é automaticamente marcado quando uma

seleção é realizada.
Estando a seleção conduzida ativada, podemos acessar os nós por:

Código em métodos do controlador
Relacionando a um elemento de UI (seleção de uma linha de tabela)
Contexto
Seleção conduzida
Contexto
Singleton
Contexto
Singleton
A propriedade singleton afeta o relacionamento entre um nó e seu pai.
Se o N2 possuir a propriedade singleton desmarcada, o que é o padrão, então para

qualquer elemento de N1 haverá uma instância distinta de N2.
Se existitem n elementos em N1, vão existir n instâncias de N2.
Entretanto, se marcarmos a propriedade singleton para N2, não importa quantos

elementos tenham em N1, pois somente uma única instância de N2 será criada.
Contexto
Singleton
Contexto
Supply Function
Contexto
Supply Function
Supply functions são mecanismos para popular os nós filhos e podem ser associadas a
qualquer nó presente no contexto do controlador.
São automaticamente excutadas pelo mecanismo de runtime do framework nas

seguintes situações:
Se o nó estiver vazio;
Se o index do “lead selection” mudar;
Se, através de programação, a coleção do nó for invalidada.
Não podemos utilizar nenhum comando para utilizar uma supply function, somente o
runtime do Web Dynpro pode acessá-las
Contexto
Supply Function
Quando associamos uma supply function, um método adicional no controlador será
criado com a seguinte assinatura:
PARENT_ELEMENT: referência para o nó pai;
NODE: referência para o nó atual.
Lazy data instantiation: O Web Dynpro sgue este princípio, no qual os dados somente
são criados quando são realmente precisos.
Aplicando este princípio ao contexto, significa que o dado em um filho será somente
carregado quando a aplicação precisar dele, do contrário o filho permanecerá vazio.
Os nós dependentes, em si, também só serão criados no momento da necessidade.

Contexto
Lazzy data instantiation
ID ALUNO
1 José
2 Daniela
3 João
4 Fernanda
Matemática 10 Matemática 6
Física 8 Física 5
Química 9 Química 7
Contexto
Context Mapping
Context mapping permite que um controlador (usualmente um controlador de visão)

acesse dados processados por outro controlador, sem a necessidade destes serem
copiados ou movidos (utiliza referência).
Em soluções projetadas de acordo com o MVC, um controlador de visão deve ser

definido de al forma que a geração dos dados não o afete, ficando responsável
somente pela exibição dos mesmos.
É tarefa do controlador do componente (ou um customizado) interagir com o back-end

para a obtenção dos dados.
Para realizar o mapeamento entre dois controladores, o controlador destino deve

declarar o controlador de origem em suas propriedades.
Contexto
Context Mapping
Um nó no contexto de origem pode ser referenciado de duas maneiras:
Para um nó existente no destino
Para um novo nó no destino, caso este ainda não exista.
Se o nó de destino possuir atributos que não estão presentes no nó de origem, estes

serão excluídos no momento do mapeamento.
Os nós de origem e destino podem possuir nomes diferentes.
No momento do mapeamento, todos os elementos de um nó (atributos e filhos) são

mapeados.
Internal mapping: origem e destino dentro da fronteira do mesmo componente.
External mapping: origem e destino pertencem a controladores em diferentes

componentes. Utilizado no caso de reuso. Veremos maiores detalhes quando
discutirmos o reuso de componentes Web Dynpro.
Contexto
Definindo a interface com o
usuário
Um dos pontos fortes do Web Dynpro é a fácil definição da interface com o usuário
(UI).
Ferramenta WYSIWYG.
O layout é gerado em tempo de execução de acordo com os metadados criados.
Definir a UI consiste na definição de quais elementos farão parte do layout (inputs,

tables...), suas propriedades (cor, visibilidade...) e eventuais ligações com os dados
do contexto (data biding).
Podemos definir as propriedades no código do controlador, modificando os

artibutos mapeados, garantindo uma melhor separação entre apresentação e
lógica..
usuário Definindo o layout da visão
Um elemento de UI é qualquer entidade gráfica que ocupa uma posição no layout da
visão.
Existem elementos que não são visíveis, utilizados para organização, tais como:
TransparentContainer
ViewContainerUIElement
InvisibleElement.
A visibilidade é uma propriedade do elemento, que pode ser definida em tempo de

execução, mas que não libera o espaço ocupado pelo elemento.
Nome: Fábio Fábio
Nota: 5,6 Nota: 5,6

Todos os layouts de visões são compostos por uma hierarquia de elementos UI.
RootUIElementContainer:
Nó raiz do tipo TransparentContainer.
Não pode ser alterado, muito menos excluído.
Context_Menus:
Menus definidos em tempo de projeto.
Em tempo de execução estes podem ser instanciados e associados a um UI.
Ficam acessíveis através do clique com o botão direito do mouse.
usuário Containers e Layouts
Containers
São elementos de UI que possuem elementos filhos.
Ocupam uma área retangular de um layout de visão.
Definem como seus elementos filhos serão arrumados através da
propriedade Layout, na qual um gerenciador de layout é associado.
Containers podem ser do tipo:

Group
TransparentContainer
Tray
Todos os filhos de um container herdam as propridades do gerenciador de layout

associado ao container.
A propriedade Layout pode ser dos seguintes tipos:

FlowLayout
RowLayout
MatrixLayout
GridLayout
usuário
FlowLayout
O gerenciador de layout padrão é o FlowLayout.
Todos os filhos são exibidos em uma linha, contanto que o container seja largo o
suficiente.
Se o container for muito estreito os elementos são automaticamente disponibilizados

nas linhas de baixo.
RowLayout
Todos os filhos herdam a propriedade LayoutData.
O elemento que possuir LayoutData = RowHeadData será disponibilizado em uma

nova linha.
O elemento que possuir LayoutData = RowData será disponibilizado na mesma linha,

mesmo que a margem seja excedida.
Não existe alinhamento em colunas, uma vez que elementos em diferentes linhas
não possuem relação.
usuário Flow Layout
usuário RowLayout
usuário
MatrixLayout
Todos os elementos filhos do container herdam a propriedade LayoutData.
Elementos com LayoutData = MatrixHeadData serão exibidos em uma nova linha.
Elementos com LayoutData = MatrixData serão exibidos na mesma linha, mesmo que
a margem direita seja excedida.
Os elementos presentes neste container são arrumados em colunas.
O número de colunas não é definido estaticamente, podendo variar de linha para

linha.
usuário
GridLayout
O número de colunas é definido pela propriedade colCount.
Um elemento não pode definir que será o primeiro da linha.
Ao excluir um elemento dinamicamente, toda a matriz é reorganizada.
Uma solução seria a substituição por um InvisibleElement.
Em geral, recomenda-se a utilização do MatrixLayout.

usuário MatrixLayout
usuário GridLayout
usuário Editor do Layout
usuário Data Binding
Quase todas as propriedades de um elemento UI pode ser atrelada a um nó ou
atributo do contexto.
O Data Biding só pode existir entre UI e contexto de um mesmo controlador de visão.
Através do Data Biding, um controlador pode modificar a aparência e o
comportamento de uma visão, sem precisar acessar os elementos de UI.
Data biding é um relacionamento de duas vias.

1. UI -> Contexto
2. Contexto -> UI
Os dados que são enviados pelo usuário são validados em tempo de execução. Caso
ocorra um conflito com o nó ou atributo do contexto, incluindo casos de domínio fixo,
os dados não são transportados para o contexto e uma mensagem de validação é
exibida.
usuário Controlando o comportamento de elementos UI
Se definirmos este atributo

estaticamente, só poderemos alterá-lo
no método wddomodifyview( ) do
controlador, acessando direto o
elemento.
Isto viola o princípio da separação entre

layout e lógica.
Para possibilitar o controle do comportamento do elemento de UI, devemos criar um
atributo no contexto do controlador, respeitando o mesmo tipo da propriedade que
desejamos controlar.
Modificando este atributo, em qualquermétodo do controlador, estaremos

modificando o comportamento do elemento UI.
Após a criação deste atributo, basta realizar a ligação com a propriedade em questão.
usuário Composite UI
Alguns elementos de UI são utilizados para exibir outros elementos de maneira

agrupada.
Somente exibem a informação necessária através de seus filhos.
O mais utilizado elemento deste tipo é a tabela.

usuário Table UI
O elemento do tipo tabela (Table UI) atua como pai para alguns elementos de coluna
(TableColumn UI), organizando-os em linhas e colunas.
As colunas também são elementos compostos, possuindo um cabeçalho (Caption UI)

e um editor de célula.
Um editor de célula pode ser, por exemplo, dos seguintes tipos: TextView, InputField,
DropDownByKey, Checkbox, Button….
O elemento tabela deve estar associado a um nó no contexto de cardinalidade

máxima n (0..n ou 1..n).
Podemos utilizar um wizard para criar uma tabela.

usuário Table UI
Contexto
TableColumn UI
Um elemento tabela deve conter pelo menos um elemento coluna.
Como vimos, as colunas também são elementos de composição.
O cabeçalho da coluna é criado através do elemento Caption (legenda).
O tipo de interação que a coluna terá com o usuário é determinante para a definição
do elemento de edição da célula.
Apesar do nome, o editor de célula não necessariamente deve alterar o conteúdo

que apresenta.
Exemplos:
TextInput: o dado apresentado poderá ser alterado.
TextView: o dado não é passível de atualização.
Button: o dado é apresentado como texto do botão. Neste caso o usuário não
pode alterar diretamente o dado, mas pode disparar um evento.
usuário
usuário
Quando selecionamos uma linha na tabela, um “round trip” é iniciado.
Podemos entender um “round trip” como uma ida ao mecanismo de runtime do

framework e uma volta à exibição para o usuáirio.
O index do lead selection é então reorganizado, apontando para o elemento do nó em

questão.
O número de elementos de nó é igual ao número de linhas da tabela.

usuário
Ao selecionar a segunda linha, o índice muda de 1 para 2...
usuário
De maneira a permitir a seleção de mais de uma linha na tabela, o nó do contexto ao
qual o elemento de tabela está mapeado deve possuir a propriedade selection
cardinality 0..n ou 1..n.
usuário
Além da configuração anterior, a propriedade selectionMode do elemento deve ser
corretamente configurada.
Valor Min Linhas Max Linhas Aciona Muda o index

selecionadas selecionadas Round (lead selection)
Trip
auto O ou 1* 1 ou n* x x
single 0 ou 1* 1 x x
multi 0 ou 1* 1 ou n* x x
none 0 0 - -
singleNoLead 0 ou 1* 1 x -
multiNoLead 0 ou 1* 1 ou n* x -
* irá depender da cardinalidade definida.
WDR_TEST_UI_ELEMENTS
usuário

Web Dynpro - Aula 02

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Web Dynpro - Aula 02

Enviado por

Direitos autorais:

Formatos disponíveis

Desenvolvimento Pessoal

Web Dynpro Controllers.

Definindo a interface com o usuário

They contain all data - stored as controller attributes or as attributes belonging to

Possuem também todos os dados, armazenados na forma de atributos ou pertencendo

Controlam a manipulação de eventos e a navegação.

É de fundamental importância entender como os controladores são definidos e que tipo

Os controladores são o coração de uma aplicação Web Dynpro

• Não possui elementos de interface visuais.

•Definidos no projeto do componente, sendo usados para encapsular funções

•São instanciados automaticamente pelo framework, sendo a ordem de

•O código de um controlador customizado não pode ser dependente da existência

• Somente necessário quando o compoennte possui funções muito específicas de

• Podemos ter somente um controlador de configuração em um cmponente.

• Pode conter o código responsável por gerar a passagem de parâmetros.

O contexto e o atributos de cada controlador são privados ao menos que outro

Um controlador de visão não pode ser declarado em outro. O contexto e os atributos de

O ciclo de vida dos controladores não está limitado ao tempo de processamento do

O ciclo de vida vai variar de acordo com o tipo do controlador:

• Quando iniciados uma aplicação, o controlador do componente é

• Não podem ser excluídos explicitamente.

• Seu ciclo de vida é o mesmo do componente.

• O ciclo de vida pode ser controlado através das propriedades da visão:

• Isto ocorre quando:

• As instâncias de controladores de janelas não podem ser excluídos

Cada controlador tem seu próprio contexto.

O nó raiz é automaticamente criado. Os demais nós devem ser estaticamente

Para cada tipo de controlador irá existir um conjundo de hook methods.

Entretanto, dois métodos são comuns a todos os controladores:

Na aba métodos, é possível a inclusão de mais métodos.

Existem dois atributos pré-definidos:

Exemplo: vou chamar um método no controlador de uma visão após o

Os métodos, os elementos de contexto e os eventos podem ser marcados como

Um evento de navegação é levantado quando um outbound plug é disparado.

Um inbound plug é um handler para estes eventos de navegação.

Além dos atributos já apresentados, os controladores de visão possuem o seguinte,

WD_COMP_CONTROLLER é uma referência ao controlador do componente, podendo

O atributo WD_COMP_CONTROLLER só irá existir se o controlador do componente

Muito parecidos com os controladores de visão.

Podem ser entendidos como um controlador de visão sem elementos de interface

Todas as visões que serão apresentadas em uma aplicação devem estar

O contexto é uma estrutura hierárquica, podendo ser definida estaticamente ou

Um contexto é formado por nós e atributos, arrumados hierarquicamente.

Todo controlador possui um e somente um contexto.

Os dados do contexto de cada controlador respeitam o ciclo de vida do mesmo.

Os nós e atributos são organizados de maneira hierárquica, existindo sempre um nó raiz

O nó raiz é criado automaticamente quando o controlador é inicializado, não podendo ser

Os nós podem conter atributos ou outros nós como filhos.

O nome de um nó deve ser único no contexto.

Um atributo do contexto é uma entidade que não possui filhos.

Elemento: entidade criada em tempo de execução para representar uma instancia do

Quando projetamos a hierarquia do contexto estamos definindo a estrutura de

Temos então quatro combinações possíveis:

Mesmo na cardinalidade máxima de 1, um elemento é criado em tempo de

Uma coleção de elementos de um nó pode seracessada através de um índice.

A seleção conduzida de um nó do contexto aponta ou para :

A propriedade “Initialize Lead Selection “ habilita a seleção conduzida no

O primeiro elemento em uma coleção é automaticamente marcado quando uma

Estando a seleção conduzida ativada, podemos acessar os nós por:

A propriedade singleton afeta o relacionamento entre um nó e seu pai.

Se o N2 possuir a propriedade singleton desmarcada, o que é o padrão, então para

Se existitem n elementos em N1, vão existir n instâncias de N2.

Entretanto, se marcarmos a propriedade singleton para N2, não importa quantos

São automaticamente excutadas pelo mecanismo de runtime do framework nas