itemList.dataProvider.lenght

Onde itemList é o ID da sua mx:List. Isso é muito util quando você precisa que um determinado campo ou botão não permaneça desabilidado quando o usuário selecionar o último item da sua lista. Supondo que o controle que precisamos desabilitar seja um mx:Button, basta colocar o seguinte na sua propriedade enabled

{(itemList.selectedIndex < (itemList.dataProvider.length-1))}

Isso se torna possível graças a facilidade provida pelo excelente sistema de DataBindind proporcionado pelo Flex. A lógica é simples: Retornará TRUE caso o indice do item selecionado na lista seja menor que a quantidade de itens menos um. Lembrando que o calculo do length – 1 é obrigatório, já que o indice de itens começa em zero, e a contagem de itens começará sempre com 1 (lógico). Simples, fácil e rápido!

Fatal error: Uncaught exception 'Exception' with message
'Your GD installation does not support JPG image types'
in '(...)\phpthumb\ThumbBase.inc.php:165 Stack trace:
#0 (...)\phpthumb\GdThumb.inc.php(1081): ThumbBase->triggerError('Your GD install...')
#1 (...)\phpthumb\GdThumb.inc.php(101): GdThumb->verifyFormatCompatiblity()
#2 (...)\phpthumb\ThumbLib.inc.php(127): GdThumb->__construct('D:/xampp/htdocs...', Array)
#3 (...)\phpthumb\ThumbBase.inc.php on line 165

A solução é mais simples do que você pode imaginar. Se você tem certeza que sua biblioteca GD está instalada corretamente, tente o seguinte:

No arquivo GdThumb.lib.php, procure por volta da linha 1060 pelo método verifyFormatCompatiblity(). Substitua as linhas:

case 'JPG':
case 'PNG':
$isCompatible = $gdInfo[$this->format . ' Support'];
break;

Pelo código abaixo:

case 'JPG':
$isCompatible = (isset($gdInfo['JPG Support'])) ? $gdInfo['JPG Support'] : $gdInfo['JPEG Support'];
break;
case 'PNG':
$isCompatible = $gdInfo['PNG Support'];
break;

O método completo deverá ficar assim:

	protected function verifyFormatCompatiblity ()
	{
		$isCompatible 	= true;
		$gdInfo			= gd_info();

		switch ($this->format)
		{

			case 'GIF':
				$isCompatible = $gdInfo['GIF Create Support'];
				break;
      case 'JPG':
        $isCompatible = (isset($gdInfo['JPG Support'])) ? $gdInfo['JPG Support'] : $gdInfo['JPEG Support'];
        break;
      case 'PNG':
        $isCompatible = $gdInfo['PNG Support'];
        break;
      default:
				$isCompatible = false;
		}

		if (!$isCompatible)
		{
			$this->triggerError('Your GD installation does not support ' . $this->format . ' image types');
		}
	}

Salve o arquivo e teste.

O problema acontece que, ao pressional o atalho AltGR+W, nada aparece. Isso porque o Eclipse tem, por padrão, um atalho associal ao comando CTRL + ALT + W. Se você testar no bloco de notas a combinação CTRL + ALT + W, verá que o resultado é o mesmo que AltGR + W. Quando pressionamos essa sequencia de teclas dentro do Eclipse, ele simplesmente irá entender que estamos tentando acionar o atalho, e ignora a impressão do caractere gráfico na tela.

Para resolver esse problema, abra o Eclipse (ou o IDE baseado nele), vá no menu “Window”, “Preferences”. No grupo “General”, pocure pela seção “Keys”. Altere o atalho associado a opção “Show Properties” para qualquer outro, ou simplesmente apague ele. Aplique as modificações e pronto! Problema resolvido.

O ASP.NET, conforme mencionamos em artigos anteriores, realiza por conta própria muitas tarefas que antes tinhamos que programar manualmente.

Uma destas tarefas é o controle de login. No ASP tradicional são necessários os seguintes passos para realizar o controle de login :

1) Escolher o nome de uma variável de sessão e os valores que ela conterá (1 se o usuário estiver logado, por exemplo)
2) Criar uma página para validar o login do usuário
3) Se o login for válido, atribuir um para a variável de sessão escolhida
4) Em todas as páginas, testar o valor da variável de sessão. Se o valor for diferente de 1 redirecionar o usuário para a página de login
5) Ao redirecionar para a página de login deve transmitir a url da página que o usuário tentou acessar
6) Após o login a página de login deverá verificar se recebeu alguma url por parâmetro e, se sim, se desviar para ela, permitindo assim que o usuário chame diretamente uma página, logue-se e acesse esta página

Por exemplo, se o usuário chamar o endereço : http://site/paginatexto.asp desvia-se o usuário para o endereço http://site/login.asp?url=/paginatexto.asp

Desta forma o usuário verá a tela de login onde poderá ser validado. Após a validação a página de login poderá utilizar o parâmetro que recebeu para desviar o usuário de volta exatamente para a página que ele havia originalmente chamado.

No ASP.NET a estrutura de funcionamento continua a mesma, afinal, a web não foi mudada. O que mudou é que não precisamos nós mesmos implementar todos os passos, pois o ASP.NET realiza esses passos para nós.

Para que o ASP.NET possa realizar o processo de autenticação para nós é primeiramente devemos informar a ele que desejamos realizar esse processo de autenticação. Essa informação é dada ao ASP.NET através de um arquivo chamado web.config. Esse arquivo é escrito em formato XML e pode ser inserido em qualquer diretório da aplicação. Ele contém configurações a nível de site que serão válidas a partir do diretório em que ele se encontra e em todos os sub-diretórios. Por isso é comum que um web.config seja sempre inserido na raiz do site.

Através do web.config vamos fornecer as seguintes informações :

- Que tipo de autenticação iremos realizar, no caso, baseada em formulário. É possível também utilizar outros tipos de autenticação, tal como a autenticação integrada com o sistema operacional, normalmente utilizada em ambientes de intranet.

- Qual formulário iremos utilizar para realizar a autenticação

- Quais usuários poderão acessar as páginas. No caso utilizaremos um simbolo para indicarmos que apenas usuários autenticados poderão acessar as páginas.

- O nome da variável que será utilizada para identificar o usuário logado. Aqui valem duas observações : o ASP.NET não utiliza variáveis de sessão para isso, mas sim cookies; o nome indicado não é realmente o nome, mas um sufixo para o nome.

Com o que mencionei até agora você já deve ter percebido o que irá ocorrer : O ASP.NET controlará o processo de autenticação automaticamente. A partir do momento que configuramos o web.config para realizar a autenticação via formulário o ASP.NET passa a verificar em todos os acessos a página se o usuário está logado ou não, verificando se o cookie de autenticação existe. Se não existir ele desviará a execução para o formulário de login que houvermos informado no web.config, transmitindo via GET a página que o usuário tentou acessar. Isso nos economiza grande trabalho de desenvolvimento.

Você deve ter observado que, já que está sendo utilizado um cookie ao invés de uma variável de sessão este cookie poderia ficar gravado na máquina do usuário entre uma visita e outra. A questão é : Realmente pode, se você quiser. Existem cookies temporários e cookies permanentes, os temporários são destruidos quando o browser é fechado, os permanentes são gravados em disco. O ASP.NET permite que você determine se deseja que o cookie de autenticação seja permanente ou temporário.

Isso é util para que você possa fornecer ao usuário a opção de lembrar suas informações de login, assim quando o usuário retorna ao site o cookie de login já encontra-se lá e consequentemente ele pode acessar as páginas sem redigitar suas informações de login. Muito cômodo e, sendo apresentado como uma opção para o usuário, ele assume os riscos.

No VB.NET ao criarmos um projeto o web.config já é criado para nós, precisaremos apenas alterar algumas das tags que ele possui, veja :

Com o elemento authentication estamos determinando o tipo de autenticação que iremos utilizar (forms) e a url do formulário de autenticação e o nome do cookie de autenticação.

Já como o elemento authorization determinamos quais usuários podem acessar a aplicação. A ? utilizada no elemento Deny indica que deve ser negado acesso a usuário não identificados, ou seja, não logados.

O próximo passo é a montagem da tela de login. A tela de login precisará ter, além das caixas de usuário e senha, uma checkbox perguntando ao usuário se deseja gravar sua identificação em um cookie permanente para facilitar seu retorno ao site. Claro que implementar essa checkbox é opcional, mas é muito simples de fazer e é um conforto útil para o usuário.

Veja como fica a programação do botão Ok da tela de login ficaria assim :

Private Sub cmdLogin_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles cmdLogin.Click
If txtLogin.Text = “DENNES” AndAlso txtSenha.Text = “SENHA” Then
FormsAuthentication.RedirectFromLoginPage(txtLogin.Text, chkLembrar.Checked)
End If
End Sub

Claro que nesse ponto seria feita uma busca em um banco de dados para validar o login do usuário, mas isto é apenas um exemplo da autenticação. O importante aqui é observar o funcionamento do método RedirectFromLogin page do objeto FormsAuthentication. Esse método gera o cookie identificando que o usuário encontra-se logado e redireciona o usuário para a página que ele solicitou.

Observe o 2o parâmetro, que determina se o cookie será permanente ou temporário. Neste exemplo estamos configurando este 2o parâmetro com o checked da checkbox inserida na tela de login. Desta forma o usuário pode optar por manter seu login registrado em cookie ou não. Se não tivessemos criado a checkbox na tela deveriamos utilizar false como default.

Para testar podemos criar uma ou mais páginas dentro desta aplicação e tentar chama-las diretamente. Você verá que será automaticamente desviado para a tela de login e só conseguirá fazer o acesso às demais páginas após se logar.

Caso você deseje que algumas páginas sejam acessíveis mesmo que o usuário não esteja logado pode criar um sub-diretório e criar um web.config separado para este sub-diretório, sem criar a exigência de autenticação.

Com isso, os 6 passos necessários para a montagem de uma autentiação em ASP foram reduzidos pelo ASP.NET a apenas 2 passos : A configuração do web.config e a montagem de uma tela de login.

Dennes Torres
MCSD,MCSE,MCDBA

Há umas semanas atrás, fui visitar um cliente ao qual presto consultoria, e ele me mostrou um sistema que ele havia adquirido. Era um sistema de controle escolar para desktops, onde ele poderia lançar notas de alunos, registrar todo o movimento financeiro, entre muitas outras funções. Até aí nada de mais. O que me interessou foi quando ele me mostrou que tudo aquilo ainda poderia ser disponibilizado via internet. Resolvi investigar o sistema, e descobri que ele foi programado usando essa tecnologia .net. Muito interessante!

Pesquisei mais afundo, e então vi que a idéia da Microsoft de “frameworkar” o desenvolvimento desktop e web parece funcionar muito bem! O uso do .Net tira uma grande carga do ombro do programador, e torna a progamação tanto desktop, quanto web muito mais versátil!

Eu analisei os prós e contras, e para alguns projetos que pretendo tocar, acredito que a solução .Net vai me ajudar bastante, já que um deles é justamente um projeto de integração entre software desktop e interface web. Eu estava pensando em utilizar Delphi para o Desktop e PHP com o framework Code Igniter para a a interface Web. Até agora, nada decidido ainda. Estou buscando agora saber mais sobre o .net, e estudando o C#. Já até consegui fazer uma lista de tarefas em C# seguindo um tutotial no site Asp.net.

Para me aprofundar mais, vou lançar daqui algumas semanas um projeto que já há tempos eu tenho idealizado. Será uma boa oportunidade de colocar em prática os conhecimentos adquiridos com o C# e o .net!

<form id=”form1″ name=”form1″ method=”post” action=”cadastrar.php”>

<label for=”nome”>Nome:</label><br />

<input id=”nome” name=”nome” type=”text” value=”<?php if(isset($nome)){ print($nome); } ?>” />

<label for=”nome”>Idade:</label><br />

<input id=”idade” name=”idade” type=”text” value=”<?php if(isset($nome)){ print($idade); } ?>” />

</form>

Perceberam a lógica do formulário acima? Caso exista a variável $nome, ele irá predefinir o valor do input com a variável $nome. Isso pode ser muito útil para se fazer formulários que devem editar dados já existentes.

É duro quando as vezes descobrimos soluções simples, que facilitam bastante  a nossa vida, e então pensamos “uau! como eu não pensei nisso antes??”.

No PHP existe um operador que, por muito é esquecido pela maioria dos programadores. Trata-se to @.

O que ele faz de tão importante? Simples: Ele apenas diz pro interpretador do PHP “calar a boca”, ou em termos mais polidos, ele indica ao interpretador que, mesmo que o comando que precede a ele retorne um erro (não importa qual o grau do erro), ele não deverá ser exibido ao usuário. Já vi muito esse operador aplicado em conjunto com funções de acesso a banco de dados

$conn=@mysql_connect($hostname, $username, $pass);

Com isso, se a função mysql_connect() retornar algum erro, esse não será exibido, graças ao @ que precede o comando.

Desde o inicio, eu sempre conheci esse operador, mas nunca me emprenhei a procurar uma maneira mais útil de empregá-lo nos meus projetos. Esta semana, enquanto estudava um método de utilizar Ajax para validar meus formulários, vi uma maneira bastante criativa de utilizar o @ para verificar a existência de uma variável.

Se eu utilizasse, em vez da maneira tradicional, a seguinte forma:

<input id=”idade” name=”idade” type=”text” value=”<?= $idade;  ?>” />

Isso me daria, sem sombra de dúvidas, um código muito mais limpo e facil de compreender. Mas traria um problema: Caso a variável $idade não tenha sido definida, ele iria preencher o valor do campo com um erro de “variable is not set”. Qual seria a solução? Usar o metodo de validação de variável como fiz acima? Ou talvez criar um código que setasse a variável $idade com um valor em branco no inicio do formulário?

Não. Existe uma forma muuuuito mais simples: Utilize o operador @!

<input id=”idade” name=”idade” type=”text” value=”<?= @$idade;  ?>” />

Caso a variável $idade estiver setada, o seu valor será impresso. Caso contrário, o operador @ irá se encarregar de ocultar a mensagem de erro gerada, nada será impresso, e seu código ficará muito mais limpo!

Fácil ou não?

O Code Igniter é uma verdadeira mão na roda para aqueles que não gostam de perder tempo “reinventando a roda”. Trata-se de um framework que trabalha com conceitos Model-View-C ontroller (MVC).

Model-view-controller (MVC) é um padrão de arquitetura de software. Isso significa que ele separa o processamento dos dados da aplicação/website do layout. Desta forma, alterações feitas no layout não afetam a manipulação dos dados, e estes poderão ser reorganizados sem alterar o layout.

Em resumo, para se ter uma simples página que mostre os registros guardados numa tabela mySQL, vc precisaria de três arquivos, que trabalhando em conjunto, resultariam na saída para o usuário.

Talvez possa parecer um tanto assustador no inicio, como foi para mim, mas logo esse conceito de programação MVC é digerido e tudo se torna muito claro.

O CodeIgniter é um framework que vale a pena ser estudado. Diferente de outros frameworks, ele é capaz de facilitar a vida do programador, sem forçá-lo a aprender e seguir novas regras de programação (caso muito comum em muitos frameworks existentes).

Para ajudar:

Manual do CodeIgniter (em Português)
Página do CodeIgniter em Português
Página oficial do CodeIgniter (em Inglês)
Assinar a lista de discussão do CodeIgniter (Português)