Presentation Designer

O modelo de apresentação é construído com o Presentation Designer (PRD) e permite definir a camada de apresentação, ou seja, desenhar as views, de um módulo.

Conceitos Principais

Os conceitos principais do modelo são os seguintes:

Module Reference

Permite identificar uma referência para os módulos necessária para o funcionamento do módulo atual. Deve existir sempre pelo menos uma referência o módulo atual (que deverá ser marcado como principal).

View (Editor)

Corresponde a um “layout” de apresentação de uma view.

O desenho da view é bastante linear e basicamente permite definir uma estrutura com uma ou mais rows (linhas horizontais) permitindo estas uma ou mais colunas. As colunas por seu lado permitem apenas adicionar campos a partir do ResourceModel.

RowContainer

Um container que organiza o layout horizontalmente.

ColumnContainer

Um container que organiza o layout verticalmente e agrega um conjunto de campos (ServiceViewFields) em views de serviço.

ServiceViewField

Um field corresponde a um campo apresentado numa view de serviço. Pode estar incluído num ColumnContainer ou num ServiceViewField do tipo detalhe.

ReferencedView

Identifica uma ServiceView relacionada com uma determinada ServiceView ‘pai’.

Estas ServiceViews podem ser referenciadas como Content de um RowContainer ou num ServiceViewField com ActionType ‘ShowModal’ na ServiceView ‘Pai’.

Uma ReferencedView é em si mesmo uma ServiceView igualmente construída à custa de uma ResourceModel que não o MainResourceModel de um serviço.

View (Report)

Corresponde a um “layout” específico para impressão de uma entidade. Uma determinada entidade pode ter tantas reportsViews quantas as desejadas.

Uma ReportView pode estar associada a várias Operations.

ReportSection

Um container que agrega um conjunto de ReportRowContainers ou de outras ReportSections em views de reporting.

As ReportSections são geridas automaticamente dependendo do tipo de Report.

ReportRowContainer

Um container que organiza o layout horizontalmente. Um RowContainer agrega um conjunto de ReportColumnContainers.

ReportColumnContainer

Um container que organiza o layout verticalmente e agrega um conjunto de campos (ReportViewFields) em views de reporting.

ReportViewField

Um reportViewfield corresponde a um campo incluído na view de report. Pode estar incluído num ReportColumnContainer ou num ReportViewField do tipo detalhe.

São suportados os seguintes tipos de fields:

• Normal – associado a um atributo da entidade.
• Custom – define um campo completamente definido pelo programador em custom code.

View (List)

Define um “layout “específico de uma lista. Herdando da definição da ListServiceOperation, permite definir visibilidade, ordem de parâmetros e colunas, bem como critérios de ordenação e agrupamento.

Uma ListView é composta por uma coleção de ListParameterReferences e outras de ListColumnReferences.

Esta lista necessita de estar sempre sincronizada com o listoperation do modelo de serviços.

ListParameterReference

Corresponde a um parâmetro da lista previamente definida na ListServiceperation

ListColumnReference

Corresponde a uma coluna da lista previamente definida na ListServiceperation

View (Dashboard)

Corresponde a um “layout” de apresentação para uma operação do tipo Dashboard.

À semelhança das ServiceViews, uma DashboardView terá sempre um RowContainer e este por sua vez um ColumnContainer.

View (Item Template)

Identifica um tipo especial de View, usada para apresentar em formulário o item de uma entidade detail.

Estas views apenas podem ser utilizadas como FormTemplate de uma grelha cujo ContextDisplay seja do tipo “Form”.

Uma ItemTemplateView é também ela construída a partir de um ResourceModel.

View (Custom)

Corresponde a um “layout” de apresentação personalizado, o qual só pode estar ligado a uma operação do tipo custom.

Operation (Editor)

Uma operação passível de ser incluída no Menu. Está sempre associada a uma EditorView e a uma ServiceOperation do modelo de serviços.

Permite adicionar Main Actions (ação principal disponível no contexto de uma service operation), Secondary Actions (ação secundária disponível no contexto de uma operation) e Context Actions (ação de contecto disponível no contexto de uma operation).

OperationMainAction

Corresponde a uma ação principal disponível no contexto de uma service operation. Estas ações principais serão representadas da mesma forma que as ações principais disponibilizadas automaticamente pela framework.

Cada service operation pode definir mais do que uma ação deste tipo.

Estas ações permitem definir ações aninhadas mas apenas é suportado um nível. É possível definir ações cujo pai seja a ação principal da service operation.

OperationSecondaryAction

Corresponde a uma ação secundária disponível no contexto de uma operation.

Estas ações secundárias serão representadas sobre a forma de links, à esquerda das ações principais.

Cada service operation pode definir mais do que uma ação deste tipo. Estas ações permitem definir ações aninhadas mas apenas é suportado um nível.

OperationContextAction

Corresponde a uma ação de contexto disponível no contexto de uma Operation.

Estas ações de contexto serão representadas sobre a forma de links, à direita da view.

Cada service operation pode definir mais do que uma ação deste tipo. Estas ações permitem definir ações aninhadas mas apenas é suportado um nível.

Operation (Report)

Uma operação passível de ser incluída no Menu. Está sempre associada a uma ReportView e a uma EditorView, usada para disponibilizar um report Custom que necessite de parâmetros.

Operation (List)

A ListOperation faz o mapeamento para o serviço, define o título da lista (prop. Caption) e, através das CreateActions e ViewServiceOperation define quais as ações de criação e edição associadas aos elementos da lista e qual é a listview utilizada para mostrar a lista.

Podem existir várias ListOperations sobre a mesma ListServiceOperation.

São suportados os seguintes tipos de listOperation:

• EntityManagement – Permite efetuar a gestão da entidade. Garante interface que permite evocar operações de create ou edit. Garante listagem dos campos id, naturalkey e do campo mascado como entityDescription. Só pode estar associado a uma ListServiceOperation do tipo ServiceEntityList.
• Custom – Permite apresentar, sobre a forma de uma lista, o resultado de uma custom list operation modelada no modelo de serviços. Este tipo de lista terá uma interação limitada consoante o tipo de source utilizada.

ListOperationCreateAction

Corresponde a uma ação que permite navegar para a operação de create para entidades presentes na ListOperation.

Operation (Dashboard)

Uma operação passível de ser incluída no Menu. Está sempre associada a uma DashboardView.

Operation (Extention)

Corresponde a uma operação sobre uma entidade que estende outra (uma extensão).

Uma vez que não corresponde a uma operação sobre a entidade principal esta operação não permite definir operações nem pode ser adicionada ao menu.

Tal como uma Operation, está sempre associada a uma ServiceView e a uma ServiceOperation do modelo de serviços.

Este tipo de operation não permite definir operation actions nem associações para ContextPages.

Operation (Custom)

Permite definir uma operação custom no modelo de apresentação que irá representar um estado personalizado na Shell do produto.

Este tipo de operação deverá estar associada a uma custom view.

Widget

Corresponde a um componente passível de ser incluído numa DashboardView.

Estes widgets podem ser referenciados em várias DashboardViews e\ou ContextPages e correspondem a uma implementação específica, ou seja, não necessitam de configuração adicional.

Os widgets permitem definir parâmetros mas isso não influencia a aparência ou a natureza dos dados apresentados. O exemplo mais coum será servirem apenas como um filtro para os mesmos.

WidgetViewField

Um WidgetView field corresponde a um componente apresentado numa dashboardview e instancia um Widget.

Pode apenas estar incluído num ColumnContainer.

Context Page

Corresponde a uma página de um dashboard de contexto de uma operação e agrega um conjunto de widgets. Uma contextpage pode estar associada a mais do que uma Operation.

GridSystem

O desenho do layout de uma EditorView acenta neste conceito. Por convenção, é assumido que o espaço de um container se encontra organizado em 12 colunas.

As dimensões indicadas nos controlos “filhos” serão sempre em relação a estas colunas do “pai”.

Cada controlo filho adicionado, poderá:

• Indicar o tamanho que ocupa em colunas (até ao máximo de 12).
• Definir um offset (número de colunas que deseja manter em branco) sendo que o offset, somado ao seu tamanho, não deverá somar mais do que as 12 colunas).

Esta regra é transversal à árvore de containers ou seja, cada container (mesmo que seja já ele um container “filho”) terá disponíveis 12 colunas para serem usadas pelos seu controlos “filhos” de forma idêntica.

Exemplo:

Outputs Principais

A partir desse modelo é gerada 100% da camada de UI do módulo, incluindo as views HTML5 e os respetivos controllers JavaScript.

Assim, neste modelo é efetuada:

• A modelação de views para apresentação
• A modelação de views para impressão
• A modelação de listas
• A modelação de dashboards