Dicas Técnicas BufaloInfo

ASP.NET : Desabilitar seleção de fins de semana no calendário

O webControl Calender, há algumas versões do .NET, ganhou o evento DayRender que pode ser utilizado para controlar a renderização de cada dia do calendario, criando efeitos muito interessantes.

Algo simples de se fazer com o dayRender é impedir que o usuário selecione fins de semana no calendário. Veja como fica o código :

Protected Sub Calendar1_DayRender(ByVal sender As Object, ByVal e As System.Web.UI.WebControls.DayRenderEventArgs) Handles Calendar1.DayRender
If e.Day.IsWeekend Then
e.Day.IsSelectable = False
End If
End Sub

Veja o mesmo código em C# :

protected void Calendar1_DayRender(object sender, DayRenderEventArgs e)
{
if (e.Day.IsWeekend)
{
e.Day.IsSelectable = false;
}
}

No evento DayRender você também tem acesso a célula da tabela que representa o dia, podendo fazer vários outros truques, como incluir anotações nos dias do calendário.

ASP.NET : Compartilhando a chave de criptografia de arquivos .CONFIG

No artigo em http://www.bufaloinfo.com.br/artigos/coluna31.asp expliquei como criptografar chaves de uma arquivo .config. O problema é se as chaves criptografadas do .Config precisarem ser utilizadas em múltiplas máquinas, vamos resolver isso :

Primeiramente, precisamos criar um container com um par de chaves :

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis -pc "YourCustomKey" -exp

Observe o -exp, que torna as chaves privadas exportáveis

Em seguida precisamos indicar o container que será utilizado em nosso artigo .config :

<configProtectedData>

<providers>

<add keyContainerName="YourCustomKey" useMachineContainer="true" description="Uses RsaCryptoServiceProvider to encrypt and decrypt" name="YourCustomKey" type="System.Configuration.RsaProtectedConfigurationProvider,System._

_Configuration, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />

</providers>

</configProtectedData>

Criptografar o arquivo. Observe a chave -prov :

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis -pef connectionStrings c:\inetpub\wwwroot -prov YourCustomKey

Exportar a chave - incluindo a privada - para poder ser utilizada em outras máquinas :

aspnet_regiis -px "YourCustomKey" "C:\temp\CustomKeys.xml" -pri

Importar as chaves em outra máquina :

C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0>aspnet_regiis.exe -pi
"YourCustomKey" "c:\temp\CustomKeys.xml" -exp

O restante segue conforme o artigo que apresentei no inicio

ASP.NET : Dynamic Data e campos auto-numeração com Entity Framework

O Dynamic Data é um poderoso recurso do ASP.NET que se tornou versão final junto com o SP 1 do framework .NET.

Podemos utilizar o Dynamic Data com LinqToSQL ou com Entity Framework. O Dynamic Data identifica diversas características do modelo de entidades para poder gerar automaticamente as páginas de cadastro.

Uma característica, porém, é mais complexa : campos auto-numeração. Os campos auto-numeração não podem ser abertos para edição/inserção.

Com o LinqToSQL tudo funciona bem, pois os metadados do linqToSQL identificam o campo auto-numeração. Porém com o Entity Framework não é tão simples.

Uma solução é utilizar o atributo scaffoldcolumn para marcar um atributo que não desejamos que seja gerado pelo dynamic data. Aplicar um atributo em elementos do Entity Framework não é tão simples, mas possível. Para isso utiliza-se o atributo metadatatype que explicamos anteriormente em http://www.bufaloinfo.com.br/dicas.aspx?cod=1027

Veja como fica :

1: Namespace BancoVideosModel
2:
3: <MetadataType(GetType(Formato_MD))> _
4: Class Formato
5:
6: End Class
7:
8: Class Formato_MD
9: <ScaffoldColumn(False)> _
10: Public Property idFormato() As Integer
11: Get
12:
13: End Get
14: Set(ByVal value As Integer)
15:
16: End Set
17: End Property
18: End Class
19: End Namespace

O atributo ScaffoldColumn, no exemplo acima, faz com que o atributo idFormato não seja lido pelo Dynamic Data.

ASP.NET : Validação com Entity Framework e Dynamic Data

Mais uma questão importante quando trabalhamos com uma geração dinâmica da interface são as validações.

Se a interface e os campos serão gerados automaticamente, como gerar a validação ?

Um erro seria levar estas validações para camadas de negócio ou camadas de dados. Validações simples devem ser implementadas na interface, para evitar a comunicação entre camadas até que uma simples validação ocorra.

O Entity Framework nos permite atribuir metadados para as classes para chegarmos aos objetivos que desejamos e isso inclui metadados de validação. Os atributos para isso encontram-se no namespace System.ComponentModel.DataAnnotations :

StringLengthAttribute : Define o tamanho de máximo de string aceito em um campo

RequiredAttribute : Define se um campo é ou não requerido

RangeAttribute : Define a região de valores aceitos por um campo

RegularExpressionAttribute : Define uma validação baseada em expressões regulares para um campo

Para aplicar estes atributos nos campos do Entity Framework precisaremos mais uma fez utilizar a técnica do MetaDataType que mostramos na dica em http://www.bufaloinfo.com.br/dicas.aspx?cod=1027

Namespace BancoVideosModel

<MetadataType(GetType(Videos_MD))> _
<DisplayName("Filmes")> _
Class Videos

End Class

Public Class Videos_MD

<DisplayName("Ano de Produção")> _
<Range(1920, 2200, errormessage:="Por favor,informe um ano válido")>
Public Property Ano() As Integer
Get

End Get
Set(ByVal value As Integer)

End Set
End Property

<DisplayName("Duração do filme")> _
<Range(50, 500, errormessage:="Informe uma duranção válida")> _
Public Property Duracao() As Integer
Get

End Get
Set(ByVal value As Integer)

End Set
End Property
End Class
End Namespace

ASP.NET : Personalizando Nomes de Campo com Dynamic Data e Entity Framework

Mesmo com o uso de um modelo de objetos, o nome interno que damos aos campos não é exatamente o nome que desejaremos que apareça em uma tela de cadastro.

Quando fazemos a montagem manualmente, alteramos também manualmente, sem problemas. Mas hoje temos recursos para fazer a montagem das páginas de forma automatizada - tal como o Dynamic Data - então o dilema permanece : Como informar com que nome desejamos que os campos sejam realmente exibidos ?

A solução é utilizarmos o atributo displayName do namespace System.ComponentModel para indicarmos com que nome desejamos que o campo seja exibido.

Da mesma forma que em outros casos, a técnica do MetaDataType, que explicamos na dica em http://www.bufaloinfo.com.br/dicas.aspx?cod=1027, precisa ser utilizada para aplicar este atributo.

Veja como fica :

Imports Microsoft.VisualBasic
Imports System.ComponentModel.DataAnnotations
Imports System.ComponentModel

Namespace BancoVideosModel

<MetadataType(GetType(Formato_MD))> _
Class Formato

End Class

Class Formato_MD
<DisplayName("Formato do Filme")> _
Public Property Formato1() As String
Get

End Get
Set(ByVal value As String)

End Set
End Property
End Class
End Namespace

ASP.NET : Resolvendo o Problema do www e Aumentando o PageRank

Para conseguir sucesso na web nossos sites precisam ser localizaveis através das ferramentas de busca.

Para conseguirmos isso nosso site depende do cálculo de pagerank que é realizado pelas ferramentas de busca. O pagerank é atribuido para nosso site e cada uma de suas páginas de acordo com os links que recebermos de outros sites.

Porém pequenos problemas de nomenclatura do site, chamados de problemas de canonicalização, podem fazer com que o pagerank do site seja dividido, reduzindo o ranking do seu site.

O caso clássico é do uso "www". Nosso site frequentemente pode ser acessado com ou sem "www" : http://www.nossosite.com.br ou http://nossosite.com.br

Pegando o caso do "www" como exemplo, podemos corrigir isso em aplicações ASP.NET utilizando o Global.Asax

Para isso podemos programar o evento Application_BeginRequest e, se a URL contiver o "www", podemos redirecionar para a URL sem "www", porém fazendo isso com o cuidado de avisar ao client (que pode ser uma ferramenta de busca) que ocorreu uma mudança permanente de endereço.

Feito isso, a ferramenta de busca saberá que referências ao nosso site com e sem o "www" significam a mesma coisa.

Veja como fica o código no global.asax :

protected void Application_BeginRequest(Object sender, EventArgs e)

{

if (HttpContext.Current.Request.Url.ToString.ToLower().Contains("http://www.mysite.com"))

{
HttpContext.Current.Response.Status="301 Moved Permanently";

HttpContext.Current.Response.AddHeader("Location",Request.Url.ToString.ToLower().Replace("http://www.mysite.com","http://mysite.com"));

}
}

Observe o uso do status 301 e do Header "Location" para indicar o endereço correto do site

ASP.NET : Configurando o page_error centralizado com Nested Master pages

Em uma dica anterior (http://www.bufaloinfo.com.br/dicas.asp?cod=1009 ) mostrei como fazer um tratamento geral de erros para o site utilizando master pages. Porém nada é tão simples.

Quando utilizamos nested master pages o problema se complica, pois a solução que apresentei na dica anterior apenas fará com que a 2a master page tenha também o tratamento de erro da primeira, mas o page_Error da página não estará executando o tratamento de erro.

A opção perfeita seria se na nested master page fosse possível pegarmos o endereço da rotina ligada ao seu page_Error e atribuirmos esse endereço ao page_error da página que usará a nested master page. Porém isso exigiria um volume de uso de reflection muito grande e como os provedores normalmente trabalham com medium trust, não funcionaria.

A solução para o problema é que a rotina que faz o tratamento do page_Error na master page seja definida como public e desta forma a nested master page poderá vincular esta rotina com o evento page_Error da página que virá a usar a nested master page -> a content page

Realmente esta solução cria um certo acoplamento entre as master pages, mas evita o reflection em excesso que exigiria full trust para o site.

Na nested master page, o código fica assim :

Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load
AddHandler Page.Error, AddressOf DirectCast(Me.Master, Bufalo).Page_Error
End Sub

Observe a necessidade do directCast em Me.Master para que a rotina Page_Error fique acessível.

Então temos :

A master page principal define o page_error como público

No load da master page principal o page_Error é atribuido ao page_error de quem usar esta master page

A nested master page utiliza a master page principal (e consequentemente ganha o page_error)

A nested master page, em seu load, liga o page_error da master page principal com o page_error da content page

A content page se aproveita de toda a sequencia

ASP.NET : Referência a WebControls no Código JavaScript

Frequentemente precisamos utilizar no javascript o nome dos nossos webControls, porém nem sempre isso é uma tarefa fácil : Quando nossos webControls encontram-se dentro de containers, tal como quando usamos master pages, login view ou outros casos semelhantes, o id do webControl se altera no client.

Talvez vocês já tenham ouvido falar que os webControls possuem uma propriedade chamada clientid, que contém o nome que o controle irá realmente ter quando estiver no client, mas como inserir este clientID no meio de um trecho de javascript como esse :

<script language="javascript">
alert($get("aqui entra o nome do objeto").value);
</script>

A solução inicial pode parecer simples, veja :

<script language="javascript">
alert($get("<%# obternome() %>").value);
</script>

no code-behind criamos a função obternome :

Protected Function obternome() As String
Return (Button1.ClientID)
End Function

Mas ocorre um problema : Expressões utilizando o "#" apenas são processadas quando é solicitado um databind() no objeto dentro do qual elas encontram-se. Neste exemplo a expressão acima nunca seria processada.

Mas poderiamos resolver da seguinte forma :

<div id="divteste" runat="server">
<script language="javascript">
alert($get("<%# obternome() %>").value);
</script>
</div>

E no codeBehind :

Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load

divteste.DataBind()

End Sub

Desta forma forçamos o databind em uma "div" que na verdade não contém absolutamente nada além do javascript e geramos o nome client do nosso objeto naquela posição.

Uma dúvida comum : Por que não usar diretamente o page.databind() ? Simples : Porque além de ser muito mais pesado o page.databind() pode executar o vinculo de dados de algum objeto que não desejamos executar naquele momento, por isso o uso de page.databind não é aconselhavel.

Outra observação importante : como isso é para resolver problemas justamente causados por containers, esta dica http://www.bufaloinfo.com.br/dicas.asp?cod=810 sobre o findcontrol pode ser importante.

ASP.NET : Tratando o page_error com master pages

O evento Page_error é sem dúvida uma boa forma de tratar erros inesperados. Enquanto desejaremos dar um tratamento comum a todo erro inesperado, utilizar o application_error do global.asax é por demais custoso.

No Visual Studio 2003 criávamos uma classe base e faziamos todas as páginas do site herdarem desta classe base. No Visual Studio 2005, porém, surgiram as master pages. Parecia a solução definitiva para algumas centralizações - tal como o tratamento de erro centralizado.

Mas infelizmente não foi bem assim. O page_error quando programado na master page simplesmente não é executado e o programador fica chupando dedo sem saber o que está acontecendo.

Qual o segredo ?

Simples : O page_error trata o erro da página em que ele está, no caso a master page. Se algum erro ocorrer dentro da execução da master page o page_error tratará isso sem problema algum.

Porém se algum erro ocorrer na content page o page_Error da master page não é considerado - não estão na mesma página.

A consequencia disso seria terrível, nos obrigaria a repetir o tratamento de erros em todas as págins. Então, como resolver ?

A solução para isso é simples : No load da master page podemos vincular o tratador qe já existe nas master page com o evento page_error da content page

Veja como fica :

Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load
AddHandler Page.Error, AddressOf Page_Error
End Sub

Com isso o tratamento de erro será o mesmo para todas as páginas e não teremos o peso típico que o application error do global.asax nos causaria.

ASP.NET : Utilizando multiplos mapas de site na aplicação

Comentamos sobre técnicas para manipular o mapa de site nas dicas em ... e ... mas eventualmente mesmo estas duas técnicas podem não ser suficientes.

Quando precisarmos realmente criar áreas de navegação separadas em nosso site podemos manipular os providers de sitemap. Isso mesmo : Os mapas de site também são baseados em providers.

Normalmente quando adicionamos um arquivo de mapa de site este já é adicionado com o nome default de web.sitemap. Porém isso não é obrigatório, podemos adicionar arquivos de mapas de site adicionais, definindo nomes personalizados para cada arquivo de mapa de site.

Então vem a questão principal : Como fazer com que o sitemapDataSource reconheça os diferentes arquivos de mapa de site que adicionarmos ?

Para isso devemos incluir no nosso web.config configurações do provider de sitemap para cada arquivo de mapa de site inserido.

Veja como fica :

<siteMap>
<providers>
<add siteMapFile="web.sitemap" name="MeuProvider1" type="System.Web.XmlSiteMapProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>

<add siteMapFile="Mapa2.sitemap" name="MeuProvider2" type="System.Web.XmlSiteMapProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>
</providers>
</siteMap>

Criamos 2 providers de mapa de site no web.config, cada provider com um nome diferenciado.

Ao utilizar o siteMapDataSource podemos inserir 2 siteMapDataSources na nossa aplicação e configurar a propriedade siteMapProvider com o nome do provider que desejamos que seja utilizado.

Desta forma, podemos ter 2 mapas de site diferenciados em uma mesma aplicação.