Dezembro 2008 - Posts
Este iniovador uso do Deep Zoom usa imagens de sítios que usam as solucões de software ViaTecla’s para formar uma imagem do Pai Natal.
[Cross-Posted de http://www.arquitecturadesoftware.org/blogs/paulomorgado/]
Não sei o que se passa com o meu sistema XP (Alem do facto de ainda o estar a usar) mas não consegui instalar a paltaforma .NET 3.5 sem remover a 2.0 e agora não consegui aplicar o SP1 sem remover a 3.5.
Felizmente, fui salvo pela .NET Framework cleanup Tool do Aaron Stebner – ambas as vezes.
Kudos Aaron!
[Cross-Posted de http://www.arquitecturadesoftware.org/blogs/paulomorgado/]
Os Callbacks foram introduzidos no ASP.NET 2.0 e são um mecanismo simples de chamar funcionalidade de uma page ou controlo se ter de gerar a página e sem que o utilizador se aperceba.
Para que uma página possa receber callbacks, tudo o que é necessário é implementar a interface ICallbackEventHandler.
Quando o cliente chama funcionalidade de uma página ou controlo no servidor, o estado inicial dos controlos é enviado para o servidor junto com o controlo cuja funcionalidade está a ser chamada no campo __CALLBACKID e o parâmetro da chamada no campo __CALLBACKPARAM.
É um procedimento bastante simples.
Mas, e se for necessário fazer a mesma chamada do lado do servidor?
Para que um pedido seja identificado como um callback (IsCallback), o pedido tem de ser um postback (IsPostback) e os campos acima mencionados têm de fazer parte dos dados do pedido (post data). Por outro lado, para que um pedido seja considerado um postback, o nível de chamadas do lado do servidor (Transfer ou Execute) tem de ser 0 (o que quer dizer que não foi feita nenhuma chamada a Transfer ou Execute) ou o tipo da página é o mesmo do Handler do pedido corrente e o método HTTP é POST.
Modificar o método HTTP (tnato quanto sei) é impossível. Portanto, se o pedido não for já um POST, não há qualquer forma de efectuar um callback.
Inicializar os dados do pedido é mais fácil. É apenas necessário reimplementar o método DeterminePostBackMode da página (ou de um page adapter) e retornar os dados previamente guardados no contexto. Algo assim:
protected override NameValueCollection DeterminePostBackMode()
{
NameValueCollection postBackMode = Context.Items["callbackPostData"] as NameValueCollection;
return (postBackMode != null) ? postBackMode : base.DeterminePostBackMode();
}
E fazer uma chamada será algo assim:
IHttpHandler handler = this.Context.Handler;
try
{
NameValueCollection postData = new NameValueCollection();
postData.Add("__CALLBACKID", sender);
postData.Add("__CALLBACKPARAM", this.argument.Text);
Context.Items["callbackPostData"] = postData;
Page calledPage = (Page)PageParser.GetCompiledPageInstance("~/Callback1.aspx", this.Server.MapPath("~/Callback1.aspx"), this.Context);
this.Context.Handler = calledPage;
StringWriter writer = new StringWriter();
Server.Execute(calledPage, writer, false);
this.response.Text = writer.ToString();
}
finally
{
this.Context.Handler = handler;
}
Aqui está uma implementação deste conceito.
[Cross-Posted de http://www.arquitecturadesoftware.org/blogs/paulomorgado/]
Lendo o blogue The Typemock Insider, deparei-me com esta entrada do Gil Zilberfeld.
Eu tendo muito a caír na prática do Gil’s ("binary search" debugging), mas não acho que o Kent Beck tenha encontrado a solução.
A sugestão do Gil para usar o Isolator é tentadora (eu não perco uma oportunidade de o usar), mas não é a minha favorita.
Eu prefiro usar debug assertions (asserções de depuração). As asserções de depuração podem ser usadas quando se corre uma versão de depuração da aplicação para que nos seja mostrada uma janela com as mensagens de asserção ou, quando se correm testes unitários, para os fazer falhar.
Para se poderem usar asserções de depuração em testes unitários é necessário um trace listener “especial” que faça o teste falhar quando o seu método Fail é chamado.
public class UnitTestTraceListener : global::System.Diagnostics.DefaultTraceListener
{
public UnitTestTraceListener() : base()
{
this.Name = "UnitTest";
this.AssertUiEnabled = false;
}
public override void Fail(string message, string detailMessage)
{
Microsoft.VisualStudio.TestTools.UnitTesting.Assert.Fail("Debug.Assert Failed: " + message + " " + detailMessage);
}
}
Agora basta registá-lo.
O registo do trace listener ser feito em código:
System.Diagnostics.Trace.Listeners.Remove("Default");
System.Diagnostics.Trace.Listeners.Add(new UnitTestTraceListener());
ou por configuração:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.diagnostics>
<assert assertuienabled="false"/>
<trace>
<listeners>
<clear/>
<add name="UnitTest" type="UnitTestTraceListener"/>
</listeners>
</trace>
</system.diagnostics>
</configuration>
E, se estiver a ser usado o Isolator, há que ter em conta os acesso feitos nas chamadas ao método Assert. Mais diversão para mim.
[Cross-Posted de http://www.arquitecturadesoftware.org/blogs/paulomorgado/]
Se puderam assistir a esta sessão no PDC ou Tech-Ed EMEA Developers, foram presenteados com uma brilhante apresentação sobre o futuro do C#, apresentada, respectivamente por Anders Hejlsberg e Mads Torgersen.
No futuro próximo (.NET 4.0), o C# terá:
-
Objectos dynamicamente tipados
-
Parâmetros opcionais e com nome
-
Interoperabilidade melhorada com COM
-
Co- e Contra-variância
Foi apresentada uma antevisão do compilador como um serviço, mas não será para o Visual Studio 2010 / .NET 4.0. Muito provavelmente, nem para a próxima.
A partir da .NET 4.0, o C# e Visual Basic convergirão em termos de funcionalidades e, de futuro, seguirão um caminho de co-evolução.
Não! Isso não quer diser que o C# terá XML Literals num futuro previsível. Isso quer dizer que a lista acima também se aplica ao Visual Basic.
Falando da evolução do Visual Basic, o caracter de continuação de linha (_) foi reformado. Se alguém tem alguma utilidade para o caracter underscore, é favor dirigir-se a http://www.unemployedunderscores.com/.
Recursos:
[Cross-Posted de http://www.arquitecturadesoftware.org/blogs/paulomorgado/]
(Pode parecer um pouco tarde para isto, mas, ultimamente, tenho tido muito em que pensar. Portanto, aqui vai.)
Este foi o meu primeiro PDC. E foi tal e qual como me tinham dito.
Para quem não sabe, o PDC é todo acerca do futuro. O futuro próximo (.NET 4.0 e Windows 7) e o futuro distante (Windows Azure, “Oslo”, “Dublin”, “Geneva”).
O PDC do próximo ano (Sim! Aparentemente, vai haver um no próximo ano) terá lugar em Los Angeles de 17 a 20 de Novembro, e (suspeito) vai ser o lançamento comercial da Azure Services Platform e uma história mais bem contada acerca do “Oslo”.
O Tech-ED EMEA Developers, por outro lado, é mais acerca do presente e do futuro próximo. Mas, este ano, os participantes puderam espreitar o que tinha sido mostrado no PDC.
O Tech-ED EMEA Developers do próximo ano terá lugar em Berlim de 2 a 6 de Novembro. Provavelmente, tal como aconteceu em 2006, será o lançamento da .NET 4.0 e do Visual Studio 2010.
E eu pretendo assistir a ambos.
[Cross-Posted de http://www.arquitecturadesoftware.org/blogs/paulomorgado/]