Formulários: diretrizes gerais e práticas recomendadas
Publicado: julho de 2016
Aplicável a: System Center 2012 SP1 - Service Manager, System Center 2012 R2 Service Manager, System Center 2012 - Service Manager
É possível ampliar os recursos do System Center 2012 - Service Manager adicionando ou modificando formulários. Esse tópico descreve algumas práticas recomendadas para criar e usar formulários do Service Manager usando várias ferramentas definições de formulários de script diretamente.
Este tópico se destina, principalmente, a parceiros e clientes com experiência na criação de seus próprios formulários personalizados usando o WPF (Windows Presentation Foundation) e o Microsoft Visual Studio Team System ou o Microsoft Expression Blend.
As diretrizes gerais para a criação de um novo formulário são as seguintes.
Use controles padrão.
Siga as diretrizes de design de forma geral.
Evite o code-behind.
Inclua tratamento de exceção.
Considere a possibilidade de personalização e atualizações de formulários.
Nomeie todos os controles personalizáveis.
Associe o formulário a Fontes de Dados.
Use as regras de validação de infraestrutura de formulários, conversores de valores e modelos de erros do Service Manager .
Use os comandos de infraestrutura de formulários e eventos.
Para obter informações sobre essas diretrizes, consulte as seções a seguir.
Usar controles padrão
Controles que são usados em um formulário podem ser:
Controles padrão. Isso inclui controles da biblioteca .NET, como caixa de combinação e caixa de listagem.
Controles personalizados. Isso inclui controles adicionais que são criados pelo autor do formulário ou por terceiros.
.jpeg "System_CAPS_ICON_tip.jpg") Dica |
|---|
|
Seguir as diretrizes de Design do formulário geral
Quando um formulário for planejado, as diretrizes de design públicas deverão ser usadas para assegurar que o formulário seja de fácil utilização e se una aos paradigmas de interação de usuários comuns.
Para mais informações sobre o design geral do Windows, acesse Windows User Experience Interaction Guidelines (Diretrizes de interação de experiência do usuário do Windows).
Além disso:
Divida as informações entre várias guias para tornar o formulário mais simples e fácil de ler. Inclua as informações usadas mais comuns na primeira guia e informações de menor importância nas guias subsequentes.
Use painéis de layout para dispor controles no formulário. Isso garante que o formulário funcione corretamente quando ele for redimensionado e localizado.
Evite configurar propriedades visuais de controle individual e use os estilos. Assim é possível mudar a aparência de todos os controles por uma série de formulários ao modificar o estilo, e promover uma aparência consistente pelos formulários relacionados.
Evitar o code-behind
Code-behind é um termo que descreve o código unido a objetos definidos com marcação quando uma página XAML é compilada com marcação. Limite o uso do code-behind em um formulário tanto quanto possível. É preferível que o código seja inserido para um formulário no controle em si, porque depois é mais fácil mudar esse código. Ao invés disso, use as capacidades declarativas que são apoiadas pela infraestrutura de formulários do Service Manager para definir as versões de valores e regras de validação no formulário.
Como uma diretriz geral, o uso do code-behind deve ser limitado a situações em que não seja possível providenciar a funcionalidade necessária ao usar as capacidades declarativas de XAML, com classes definidas no WPF e na biblioteca de infraestrutura de formulários. Mesmo então, considere mover a funcionalidade que está implementada no code-behind em uma biblioteca de ajuda e a confirme do XAML.
Incluir tratamento de exceção
Assegure que o código no formulário contenha tratamento de exceção para que o formulário possa ser carregado tanto durante a fase de design no Ferramenta de Criação como no Service Manager Console em tempo de execução.
Considere a possibilidade de personalizaço e atualizações dos formulários
Quando você estiver criando um novo formulário, você deve considerar as personalizações futuras e atualizações para esse formulário. Para assegurar que seja possível a personalização e atualização de um formulário enquanto a personalização é preservada, siga as diretrizes e dicas que são fornecidas previamente nessa seção, juntamente com as seguintes diretrizes:
Considere atualizações e personalizações futuras no início, enquanto estiver criando o formulário. Os formulários são mais prováveis de envolver versões futuras e é importante considerar como os usuários serão capazes de atualizar para novas versões do formulário enquanto preservam as particularidades do formulário original. Por exemplo, é preciso fornecer um formulário de atualização após os usuários já tiverem feito grande investimento em personalizar o seu formulário original. Os usuários esperam que suas personalizações sobrevivam à atualização de versão.
Providencie um nome único para cada controle no formulário, para que seja possível que personalizações sejam aplicadas aos controles. Personalizações de formulários são armazenadas como um conjunto de ações que são destinadas a um controle específico ou a um conjunto de controles. O controle de destino é referenciado por nome, que é o motivo da importância em preservar nos nomes de controle nas versões do formulário. Se um controle não possui um nome, o Editor de personalização de formulários gera um nome, mas o nome gerado não é preservado em diferentes versões do formulário.
Assegure de que nomes de controle permaneçam imutáveis entre diferentes versões do formulário. Isso assegura que as personalizações para um dado controle em uma versão anterior pode ser aplicada ao mesmo controle em uma nova versão do formulário.
Se possível, evite mover os controles para um local diferente na mesma guia quando atualizar um formulário. Uma personalização do usuário comum é mover os controles no formulário para um local diferente. Se o local for mudado de um controle em uma nova versão do formulário, há o risco de que o local do novo controle possa sobrepor-se ao controle que o usuário realocou.
Se possível, evite mover controles entre as guias durante a criação de uma atualização a um formulário existente. Controles são identificados pelo nome e pela guia em que se encontram. Mover um controle de uma guia para outra em uma nova versão do formulário pode danificar as personalizações que o usuário fez para aquele controle, porque a personalização irá falhar em identificar o controle de destino.
Quando a atualização de um formulário inclui novos controles, considere adicionar os novos controles a uma nova guia. essa é a forma mais segura de evitar inferência com qualquer personalização de usuário para as guias e controles existentes.
Lembre-se de como os controles são limitados. Controles somente leitura devem usar somente a associação unidirecional.
Nomeie todos os controles personalizáveis
Assegure que todos os nomes de controle descrevem a qual dado o controle está limitado, ou descreva qual a função do controle.
Associe o formulário a fontes de dados
A principal função de um formulário é visualizar um único objeto da base de dados do Service Manager . Esse objeto é chamado de um target instance, que é sempre especificado pelas propriedades de DataContext de um formulário (que é herdado da classe FrameworkElement ).
.jpeg "System_CAPS_ICON_important.jpg") Importante |
|---|
|
No modelo de dados do Service Manager , uma instância de destino é representada como um objeto de BindableDataItem . Essa classe agrega o objeto do kit de desenvolvimento de software sublinhado (SDK) e expõe suas propriedades por um indexador, que toma um nome apropriado como parâmetro.
A classe BindableDataItem também implementa ICustomTypeDescriptor, o que possibilita usar a classe BindableDataItem como fonte de dados para a associação do WPF. A seguir está um exemplo de associação de uma instância de destino para a propriedade de Text de um controle de TextBox :
<TextBox Name="textBoxDescription" Text="{Binding Path=Summary}"/>
Não é necessário especificar a Source da associação porque a instância de destino é configurada como DataContext do formulário, que serve como padrão de Source para todos os controles no formulário.
Controles no formulário podem estar limitados a outras fontes de dados que não seja a instância de destino, e a biblioteca de infraestrutura de formulários contém um número de controle que desempenham a associação implicitamente. Por exemplo, o controle seletor de instância está limitado à fonte de dados, que fornece a coleção de instâncias de escolha. Também é possível definir fontes de dados adicionais declarativamente usando as classes de ObjectDataProvider e de XmlDataProvider .
A infraestrutura de formulários considera a instância de destino como a única fonte de dados de leitura/gravação no formulário. Então, a implementação do comando de Submit armazenará as mudanças que são feitas para a instância de destino. Outras fontes de dados para o formulário são tratadas como somente leitura.
Regras de validação de infraestrutura de formulários do gerenciador de serviços de uso, conversores de valor e modelos de erro
Recomendamos que as regras de validação de infraestrutura de formulários de uso sejam usadas em formulários para designar a inserção de dados que não são válidos. A validação de suporte de infraestrutura de associação do WPF para propriedade de controle que estão limitadas a fonte de dados com suas associações de uma via ou duas vias. O objeto de associação possui uma coleção de ValidationRules que pode conter qualquer número de objetos de ValidationRule . Sempre que dados forem retirados do controle para a fonte de dados, os objetos de ValidationRule são chamados para validar os valores.
A biblioteca de infraestrutura de formulários contém um número de regras de validação que tratam os casos mais comuns. A infraestrutura de formulários toma vantagem das regras de validação sempre que os conteúdos de formulário podem ser enviados para armazenagem. Por exemplo, o botão Enviar do formulário pode ser desabilitado se houver um controle que possui um erro de validação no formulário.
Recomendamos que você use o modelo de erro personalizado que é fornecido com a biblioteca de infraestrutura de formulários. Se um controle tiver um erro de validação, ele será exibido por padrão com uma borda vermelha ao redor dele. O WPF torna possível definir um indicador de erro personalizado pela propriedade do Validation.ErrorTemplate , que pode ser configurado em qualquer controle. A biblioteca de infraestrutura de formulário do Service Manager contém um modelo de erro personalizado, que exibe um ícone de erro ao invés da borda vermelha do WPF. Além disso, quando o mouse aponta para o ícone de erro, uma dica de ferramenta surge com uma mensagem de erro. A mensagem de erro deve indicar o motivo pela qual os dados no controle falharam na validação.
O exemplo a seguir mostra como referenciar o modelo de erro em XAML:
<TextBox Text="{Binding SomeProperty}"
scwpf:Validation.ValueRequired="True"
Validation.ErrorTemplate="{DynamicResource {ComponentResourceKey {x:Type scwpf:Validation}, InvalidDataErrorTemplate}}"/>
Se as regras de validação de inclusão não fornecerem a lógica de validação necessária, recomendamos que regras de validação personalizadas sejam criadas para representar essa lógica. Isso tornará possível para a lógica de validação personalizada coexistir com os mecanismos de manuseio de validação comum.
Se o mecanismo de regras de validação não está adequado para um cenário particular, você deve identificar o FormEvents.PreviewSubmitEvent e executar a validação desse ponto.
O seguinte exemplo de código fornece um exemplo do padrão que pode ser usado para executar a validação personalizada:
void MyForm_Loaded(object sender, RoutedEventArgs e)
{
// hook to handle form events
this.AddHandler(
FormEvents.PreviewSubmitEvent,
new EventHandler<PreviewFormCommandEventArgs>(this.OnPreviewSubmit));
}
private void OnPreviewSubmit(object sender, PreviewFormCommandEventArgs e)
{
string errorMessage;
bool result = this.DoVerify(out errorMessage);
if (!result)
{
// cancel Submit operation
e.Cancel = true;
// display error message
MessageBox.Show(errorMessage);
}
}
internal bool DoVerify(out string errorMessage)
{
// Do custom verification and return true to indicate that
// validation check has passed; otherwise return false and
// populate errorMessage argument
}
Usar comandos de infraestrutura do formulário e eventos
A infraestrutura de formulário expõe um número de comandos que podem ser executados em um formulário. Esses comandos incluem:
FormsCommand.Submit, que salva a instância de destino do formulário.
FormsCommand.SubmitAndClose, que salva a instância de destino do formulário e fecha o formulário.
FormsCommand.Refresh, que repete a consulta para a instância de destino do formulário.
FormCommands.Cancel, que descarta todas as alterações e fecha o formulário.
Cada um desses comandos é agrupado por eventos que são disparados antes e após o comando ser executado.
Antes do comando, os seguintes eventos são gerados:
O evento de FormEvents.PreviewSubmit é gerado antes do comando de FormCommand.Submit , e o evento de FormEvents.Submitted é gerado após o comando de FormCommand.Submit .
O evento de FormEvents.PreviewRefresh é gerado antes do comando de FormCommands.Refresh , e o evento de FormCommand.Refreshed é gerado após o comando de FormCommand.Submit .
O evento de FormEvents.PreviewCancel é gerado antes do comando de FormCommands.Cancel , e o evento de FormCommand.Canceled é gerado após o comando de FormCommand.Cancel .
Os eventos anteriores transmitem um objeto de PreviewFormCommandEventArgs . O objeto contém uma propriedade mutável Cancel que irá prevenir o comando correspondente de ser executado quando a propriedade estiver configurada para true.
Os eventos pós-comando transmitem um objeto de FormCommandExecutedEventArgs . Esse objeto contém propriedades de Result que indica se a execução do comando foi bem sucedida, cancelada ou causou um erro. No caso de erro, a propriedade de Error do objeto de FormCommandExecutedEventArgs refere-se à exceção que fornece informação sobre o erro.
É possível habilitar, desabilitar e executar comandos de formulário de forma programática e declarativa.
Para habilitar os comandos de formulários programáticos, estabeleça um CommandBinding entre o formulário e o comando relacionado.
No seguinte exemplo, um comando associado está estabelecido entre o formulário e um comando de Refresh , e dois manipuladores são definidos para esse comando. O primeiro manipulador retorna se ou não o comando de Refresh pode ser executado, e o segundo manipulador contém a implementação do comando de Refresh :
public class MyForm : UserControl
{
public MyForm()
{
// do standard initialization
// establish CommandBinding for Refresh command
this.CommandBindings.Add(
new CommandBinding(FormCommands.Refresh, this.ExecuteRefresh, this.CanExecuteRefresh));
}
private void CanExecuteRefresh(
object sender,
CanExecuteRoutedEventArgs e)
{
// put your logic that determines whether Refresh
// can be executed here
bool canExecute = true;
BindableDataItem dataItem = this.DataContext as BindableDataItem;
if (dataItem)
{
canExecute = dataItem["Status"] != "New";
}
e.CanExecute = canExecute;
}
private void ExecuteRefresh(
object sender,
ExecutedRoutedEventArgs e)
{
// here is placeholder for the code that has do be
// executed upon running Refresh command
}
}
Também é possível definir manipuladores de comandos de formulário declarativamente. Isso é possível empregando um objeto de Regra que usa um RoutedCommandTrigger. O exemplo de código a seguir mostra como definir manipuladores declarativamente:
<scwpf:BusinessLogic.Rules>
<scwpf:RuleCollection>
<scwpf:Rule>
<scwpf:Rule.Triggers>
<scwpf:RoutedCommandTrigger
RoutedCommand="{x:Static scwpf:FormCommands.Refresh}"/>
</scwpf:Rule.Triggers>
<scwpf:Rule.Conditions>
<scwpf:PropertyMatchCondition
Binding="{Binding Status}"
Value="New"
Operation="NotEquals" />
</scwpf:Rule.Conditions>
<!-- Use RuleAction objects to define the logic that executed
upon running Refresh command; this can be left empty -->
</scwpf:Rule>
</scwpf:RuleCollection>
</scwpf:BusinessLogic.Rules>
Consulte também
Site do Windows Presentation Foundation (WPF) (WindowsClient.NET)
Formulários: Personalizando e criando