Bá! fiquei algum tempo sem escrever no Blog, problemas de tempo, sabem como é, estudar (Faculdade) e trabalhar ao mesmo tempo é algo que necessita de uma gerência de tempo extrema e como ultimamente venho tentando ter mais qualidade de vida ficou meio impossivel eu conseguir fazer muita coisa junto, mas vamos ao assunto.

O MVP como eu já falei para vocês em outro post(link) em php tem umas particularidades, após eu trabalhar um tempo com aquele meu modelo eu e meu colega Jefferson chegamos a uma ideia em comum, a aplicação do MVP ficou ótima, estou tendo grandes resultados com esse Pattern, mas em questão estrutural (FS i.e. FileSystem) não ficou muito boa pois foi visto que as vezes existem N view para um unico presenter, assim deixando o mesmo perdindo em um mundo de arquivos. Então o Jefferson propos uma estrutura levemente diferente (na qual achei muito boa).

(Estrutura).

Outra alteração é na estrutura de execução, em vez de termos um método na View loadViewDocument(), teremos um executeViewDocument().
P: Porque assim?
R: Pois se formos pensar em termos de estrutura de execução, o método irá não apenas carregar o Documento de Visualização da View e sim Executar ela, pois pode ser um Include de um arquivo PHP que tem codigo a ser executado, pode ser outra classe de transformação etc…

Outra alteração foi o start do PageExecution que foi mudado para run, essa alteração fica caracterizada já que a view vai ser rodada e nao iniciada, assim definindo melhor o modelo de funcionamento da página.

(Diagrama de Execução do MVP com o Page Execution).

Dessa vez eu colocarei exemplos, ajustados do modelo antigo pelo Jefferson.
Clique aqui para baixar o Exemplo.

Como vocês leram no outro post, usar o pattern do mvp em si não é possivel com php temos que ter um mecanismo a mais, que seria a classe PageExecution que eu criei, ele funciona como um engine automatizando a tarefa de executar as views e criar uma estrutura padronizada, isso em um sistema de grande porte é fundamental, pois funções que iriam ficar duplicadas não irão ocorrer.

A Ideia da Classe é criar um mecanismo de execução orientado a objeto simplicando a logica de execução da página e criando uma separação entre as camadas de interface e negocio. ( Mais para frente irei comentar sobre sistemas PHP totalmente orientados a objetos ).

UML da Classe:
 

Codigo:

/**
 * Classe Singleton de Execução das Paginas no Modelo MVP
 *
 * @author Iuri Andreazza
 * @since 12/2007
 * @version 0.0.1
 */
class PageExecution{

	/**
	 * @type iView
	 */
	private $_view;

	/**
	 * @type string
	 */
	private $method;

	/**
	 * @type PageExecution
	 */
	static $instance = null;

	/**
	 * @type iView
	 */
	static public $view;

	/**
	 * Retorna a Instancia do PageExecution.
	 *
	 * @return PageExecution
	 */
	static public function getInstance(){
		if(is_null(PageExecution::$instance)){
			self::$instance = new PageExecution();
			return self::$instance;
		}else{
			return self::$instance;
		}
	}

	/**
	 * Construtor
	 *
	 * @return void
	 */
	private function __construct(){

	}

	/**
	 * Inicia a Execução da Página
	 *
	 * @return void
	 * @param $viewName string
	 */
	static public function start($viewName){
		if(is_null(self::$instance)){
			self::getInstance();
		}

		self::$instance->_view = new $viewName();
		self::$instance->method = $_REQUEST[$viewName]['method'];
		self::$instance->beforPageLoad();
		self::$instance->pageLoad();
		self::$instance->afterPageLoad();
		self::$instance->executeMethod(array($_POST,$_GET,$_REQUEST, $_FILES));
		self::$instance->endPageLoad();
		self::$view = self::$instance->_view;
		self::$instance->loadViewDocument();
	}

	/**
	 * Função de Carga da Página.
	 *
	 *
	 * @return void
	 */
	public function pageLoad(){
		$this->_view->pageLoad();
	}

	/**
	 * Função de Execução antes do PageLoad()
	 *
	 * @return void
	 */
	public function beforPageLoad(){
		if(method_exists($this->_view, 'beforPageLoad')){
			$this->_view->beforPageLoad();
		}
	}

	/**
	 * Função de Execução Posterior ao PageLoad
	 *
	 * @return  void
	 */
	public function afterPageLoad(){
		if(method_exists($this->_view, 'afterPageLoad')){
			$this->_view->afterPageLoad();
		}
	}

	/**
	 * Função Executada Após Todo o Processo de Execução da view
	 *
	 * @return void
	 */
	public function endPageLoad(){
		if(method_exists($this->_view, 'endPageLoad')){
			$this->_view->endPageLoad();
		}
	}

	/**
	 * Executa o Método na View
	 *
	 * @return void
	 * @param $params array
	 */
	public function executeMethod($params){
		$method = $this->method;
		if(method_exists($this->_view, $method) && $method != ''){
			$this->_view->$method($params);
		}
	}

	/**
	 * Carrega o Documento (na Questao XML ou HTML da View).
	 *
	 * @return void
	 */
	public function loadViewDocument(){
		$this->_view->loadViewDocument();
	}
}

Outra vez um amigo meu fez um post sobre MVP com C# com .net (parte 1 e parte 2) eu quando li o post dele fiquei pensando como seria em PHP, eu mesmo como estou no processo de aprendizagem do C# e ASP.Net li o post e fiz os exemplos entendi como funciona a logica por trás do Design Pattern na qual eu gostei bastante e fiquei pensando sobre como poderia ser feito em PHP, muitos dos Features que existem no ASP.Net da Microsoft não existem nessa linguagem entao como eu poderia simplificar todo o processo de aplicação do pattern, não sabia na hora, então no meio do mar de trabalho e estudos que eu tive esses ultimos meses fiquei com a ideia na cabeça, até que um dia no meu trabalho tive a oportunidade de colocar em pratica minha ideia.

Vamos ao Cenário.
Eu trabalho em uma empresa de desenvolvimento de sistemas para ser mais preciso na area da Web, e nos ultimos meses nós viemos desenvolvendo todo um framework para atualizar os sistemas existentes e proporcionar melhor qualidade aos novos projetos que estão para vir.
Nosso framework não é dos mais robustos, ele não sobreu muitas iterações para seu aperfeiçoamento, enquanto isso nós começamos 1 migração de um sistema para modulos da nova estrutura iniciando uma nova geração de sistemas, entretanto nós continuamos a desenvolver em um modelo inconsistente, no qual não tinhamos uma separação concreta da interface com o Dominio do modulo (podemos dizer que estamos usando armas novas (para Resolver um problema) com táticas antigas), Hoje temos uma separação fisica do PHP e do visual utilizando XML e XSL, o PHP gera o XML e o XSL transforma o XML em xHTML (Explicarei como fazer isso em outro post), enquanto os modulos cresciam mais ruim ficava a separação entre a logica da aplicação e a logica da interface (ao menos uma parte dela).
Um Exemplo de como é usado hoje em dia a construção dos arquivos PHPs, como podem ver geralmente é tudo unido, em alguma vezes alguns usam um outro php com HTML e fazem include nele, já uma pratica um pouco melhor mas não pode ser considerara para uso a longo prazo em sistemas corporativos.

Como podem ter visto estivemos um periodo fora do ar, infelismente não é para melhorias mas sim com problemas em nosso host. (e ainda estamos em parte), outro motivo também é que eu não estou tendo muito tempo para ficar postando no meu blog, é final do semestre na faculdade as cadeiras na qual enrolamos estudamos o semestre inteiro temos que dar uma atenção especial a elas, esses ultimos meses foram fora do comum mas agora está tudo quase acabando logo logo estarei com tempo para ficar postando aqui para todos.

Atenciosamente
Iuri Andreazza

Após algum tempo com o blog praticamente desligado, voltamos a ativa.

Comentando sobre a Produção visual de Marta Dahlig.

Wrath

symbolism:
The colour theme - the colours red, orange, black remind me of fire -> destruction
Lightning (in the frame and background)- something destructive, rapid, uncontrollable
The hairstyle - another reference to fire
The make-up - a reference to battle marks (you know, face painting etc)
The feathers - (I tried to make them look "sharp" rather than soft and fluffy); to me, in this form they bare a resemblance to tribes -> Wrath seen as something wild and primal.
The whip she is holidng - a symbol of power
The shattered earth - the influence Wrath has on the world

Vanity or Pride - Mother of all sins
symbolism
- As you can read up, vanity is linked with the color violet, so here you go the color theme.
- Peacocks remind me of vanity as well, therefore I have used a peacock feather as an inspiration for the "frame".
- You can see the background being desertish (plus the dead tree)… Vain people usually never see any beauty in the world, but only in themselves… That is why everything around them, sooner or later, dies - and that is what I have tried to depicture.

Envy

"Envy is the desire for others’ traits, status, abilities, or
situation"

Personally I think envy means much more than just a wish to have something
someone else has. To me, it means also ACTING AGAINST that person,
"revenging" in a way, trying to take the "object of our desire" away from
them, or backstabbing them in some way etc.
That is why myself I consider envy the "heaviest" sin of all seven.

Padrões necessáriamente não são soluções completas,  eles são mais como esboços das soluções gerais que necessitam de ajustes ao problema em que o programador está tentando aplicar o pattern.

Patterns são bons, mas não para serem aplicados a todo momento, eles tem horas certas a serem usados, se forem no momento errado você corre risco de estar criando uma solução complexa para um problema simples e como dizemos aonde trabalho “Usando uma Espingarda Calibre 12 para matar moscas.”, então cuide saiba avaliar o problema antes de sair aplicando os patterns, uma coisa comum de cada pessoa que aprende patterns é a vontade de sair aplicando todos eles, isso ocorreu comigo e ocorre-rá certamente com você.

A dica aqui é realmente saber dimensionar e enxergar o problema para conseguir ver qual padrao se encaixa na solução, se você começa a dar voltas para tentar encaixar o padrao no problema então quer dizer que o padrão que você escolheu não é o indicado para a resolução, as vezes nenhum padrao se encaixa bem para a resolução entao você parte para a velha implementação simples e direta que a gente sempre fez.

Bom chega de falar e vamos direto ao assunto:

Adapter:
Primeiramente devemos aprender como é a teoria do adapter.
O Padrão de design adapter significa que é uma adaptação de uma interface para uma classe com qual o cliente consiga trabalhar. O Adaptar permite classes trabalharem em conjunto aonde normalmente nao poderiam pois tem interfaces incompatíveis. Isso é possivel com o adapter pois ele cria uma interface em volta das classes que são incompatíveis possibilitanto ao cliente usar essa classe nova para trabalhar com uma unica interface.

Bom, material temos ao montes espalhados pela internet, pretendo fazer uma série específica sobre Padrões, mostrando a aplicação de cada um com PHP e C#, cada linguagem tem seus recursos com vantagens e desvantagens, então tem que se ter em mente que nem tudo que dá para fazer em C# dará pra repetir em PHP e algumas vantagens que PHP nos fornece não estarão disponiveis em C#.

Patterns:
Adapter
Bridge
Singleton
Template Method
Abstract Factory
Factory Method
Iterator
Observer
Chain of Responsibility
Strategy
Proxy
Facade
Mediator
Interpreter
Prototype
Flyweight
Visitor
Decorator
Builder
Composite
Command
Memento
State

Os Patterns (Padrões) serão abordados na ordem ai apresentados.

Bom vamos lá:
Foi pedido para fazer uma avaliação do GIMP para substituir o Photohosp na Empresa em que eu trabalho, pois bem eis alguns detalhes sobre o programa nos testes que eu executei com ele.
(GIMP)
Pontos Fortes:
1) Biblioteca de efeitos relativamente boa, com possibilidade de o proprio usuario programar e expandir ela.
2) Free.

Pontos Fracos:
1) Interface pobre e de dificil utilização.
2) Efeitos variam de qualidade e perfomance não permitindo que um trabalho se mantenha em um padrão de alto nivel.
3) Ferramentas de Manipulação de Imagem fora de padroes do mercado e seus funcinamentos variam de estabilidade e qualidade, falta de altalhos e facilidade de acessa-los.

Sobre o Photoshop:
Pontos Fracos:
1) Pago
2) Não Permite uma criação de plugin sem o seu SDK que tb nao é gratuito.

Pontos Fortes:
1) Interface relativamente facil de manipular, grande gama de atalhos.
2) Altamente Configuravel, desde agrupamentos de imagem e camadas, até mesmo controle de versao das figuras.
3) Grande Biblioteca de Efeitos, que mantém a qualidade e desenpenho a niveis altissimos.

Bom esses são somente alguns argumentos sobre os 2 softwares, ao utilizar o GIMP enfrentei alguns problemas com a utilização, achei ele desajeitado e com uma interface muito confusa, com o photoshop tenho mais tempo de experiencia e tenho mais performance em realizar tarefas de criação de icones, e detalhes para as interfaces, ou mesmo o design de interfaces web.

Citação de um post comparando o Photoshop e o GIMP
“Serious users will focus on Photoshop. It isn’t cheap, but in its intended market a computer and the software is a necessary tool for getting work done” (Steve Crandall)
Digo e faço das palavras dele as minhas, se for para trabalho sério e com objetivos e prazos deve ser utilizado o photoshop, se é para usar em casa use o GIMP, é uma ferramenta muito boa para passar o tempo e alterar algumas imagens so por diversão.

Bom pela segunda vez inicio meu blog. Aqui pretendo escrever com regularidade, em geral sobre tecnologia, e ir colocando aquilo que venho aprendendo, desde de Design Patterns, até métodologias de programaçõa, além claro de colocar assuntos relevantes a minhas cadeiras da faculdade, manterei separado por pages aonde q serão postados em seus principais topicos.