Iniciando com Cairngorm – Parte 2

Flex / Cairngorm 1 Comment »

Part 2 - Usando uma ModelLocator para Gerenciar A View

Nota: Tal como acontece com todos os tutoriais que virão nesta série, esta lição tem duas partes. Em primeiro lugar, no artigo você vai aprender a teoria por trás do tema e, em seguida, no vídeo que você vai fazer um verdadeiro ” code-along “. O artigo dará algumas instruções de como configurar o seu projeto de ” code-along “.

No tutorial anterior você aprendeu as vantagens de usar um ModelLocator para manipular os dados dentro de um aplicativo, no entanto, a vantagem do ModelLocator padrão se estende para além da gestão de dados. Pode manipular a “view” de uma aplicação tão bem. Para ver como funciona na gestão Cairngorm, primeiro você precisa criar um novo projeto chamado “ViewManager” e o nome do arquivo principal aplicação “Main.mxml”. Para este projeto, você também vai necessitar adicionar o Cairngorm.swc para construir o seu projeto (como descrito na parte 1). Também será necessário criar duas novas pastas dentro do “src” pasta: view e model. Quando estiver concluído, o projeto deve ser parecido à Figura 1 abaixo.
Cairngorm Project Window
Figure 1 - ViewManager Project

Em seguida, você precisará ter o código do ModelLocator do tutorial anterior e colocá-lo dentro do seu aplicativo. Já publicamos o código abaixo para sua conveniência.

Actionscript:

  1. package model {
  2.     import com.adobe.cairngorm.model.IModelLocator;
  3.     [Bindable]
  4.     public class ViewModelLocator implements IModelLocator {
  5.         // Single Instance of Our ModelLocator
  6.         private static var instance:ViewModelLocator;
  7.         public function ViewModelLocator(enforcer:SingletonEnforcer) {
  8.         if (enforcer == null) {
  9.                 throw new Error( “You Can Only Have One ViewModelLocator” );
  10.             }
  11.         }
  12.         // Returns the Single Instance
  13.         public static function getInstance() : ViewModelLocator {
  14.             if (instance == null) {
  15.                 instance = new ViewModelLocator( new SingletonEnforcer );
  16.             }
  17.             return instance;
  18.         }
  19.         //DEFINE YOUR VARIABLES HERE
  20.     }
  21. }
  22. // Utility Class to Deny Access to Constructor
  23. class SingletonEnforcer {}

Example 1 - The ModelLocator from Part 1

Se precisar de mais informação sobre a ModelLocator, volte a parte 1 do tutorial.
O único item que deve ser mudado na ModelLocator é a declaração “package”. Para este projeto, ser-lhe-á a colocação ModelLocator na pasta “model”, de modo que o caminho do package simplesmente precisa de mim “model” (ele já foi corrigido acima). Também será necessário adicionar uma variável à sua ModelLocator inicialmente. Esta variável será chamado “workflowState” e será do tipo “uint”. A declaração será semelhante a este:

Actionscript:

  1. public var workflowState:uint = 0;

Example 2 – definindo a variável workflowState
Esta variável será utilizada para “controlar” a view da sua aplicação. A forma mais comum de conseguir isto é usar um ViewStack. Se você não estiver familiarizado com um ViewStack, sinta-se livre para ler esta informação. Um ViewStack tem uma propriedade denominada “selectedIndex”. Este valor numérico que define ” child ” é visível no ViewStack. Considere o seguinte código:

mxml:

  1. <mx:ViewStack id=”myViewStack”>
  2.   <mx:HBox id=”box1″>
  3.     <mx:Label text=”I am Box 1″ />
  4.   </mx:HBox>
  5.   <mx:HBox id=”box2″>
  6.     <mx:Label text=”I am Box 2″ />
  7.   </mx:HBox>
  8.   <mx:HBox id=”box3″>
  9.     <mx:Label text=”I am Box 3″ />
  10.   </mx:HBox>
  11. </mx:ViewStack>

Example 3 - A exemplo simples de ViewStack
Inicialmente, o valor de selectedIndex é 0. Com esta configuração “box1″ seria visível. Se você emitir o seguinte comando

Actionscript:

  1. myViewStack.selectedIndex = 1;

Example 4 - Configurando o selectedIndex
Então a caixa denominada “box2″ seria visível. No entanto, se você aplicar o ModelLocator a este conceito, você poderia usar o workflowState varaible para definir a propriedade selectedIndex. Ao vincular a selectedIndex ao valor workflowState, agora você tem controle total sobre o que é apresentado no ViewStack de seu ModelLocator

mxml:

  1. <mx:ViewStack id=”myViewStack” selectedIndex=”{modelLocator.workflowState}”>
  2.   …
  3. </mx:ViewStack>

Example 5 - vinculando o selectedIndex ao workflowState

Definir constantes para melhorar o código

Seria simples para manipular a view utilizando este método, porém, poderia levar o código potencialmente confuso. Por exemplo, suponha que você tem os seguintes:

• Um ViewStack com dois filhos: um login e uma tela Welcome
• O ViewStack’s selectedIndex está vinculado à propriedade workflowState
• Um botão login que executa a ação mostrada no Exemplo 4.

Isto pode parecer como se ele funcionasse corretamente, mas ele não conta para quaisquer alterações. Se outro filho é adicionado à ViewStack, poderia ficar fora da ordem. Tem de haver uma maneira melhor para definir manualmente a propriedade selectedIndex. Para conseguir isso, você só precisa definir constantes dentro da ModelLocator

Actionscript:

  1. //DEFINE YOUR VARIABLES HERE
  2. public var workflowState:uint = 0;
  3. // DEFINE VIEW CONSTANTS
  4. public static const LOGIN_SCREEN = 0;
  5. public static const WELCOME_SCREEN = 1;

Example 6 – Definindo constantes View no ModelLocator.

Ao usar esse método, você só tem que alterar o valor em um único local, se o número de children ou a ordem das children mudarem no ViewStack. Agora, você deve atribuir o botão login as seguintes medidas para o evento clique.

Actionscript:

  1. myViewStack.selectedIndex = ViewModelLocator.WELCOME_SCREEN;

Example 7 – Fixando a View com constantes definidas.

Não só para proteger contra futuras mudanças, você também fez o seu código muito mais lógico. Outro desenvolvedor poderia facilmente analisar o código e entender o processo sem ter de referenciar todas as children no ViewStack.

Tradução do original inglês: http://www.davidtucker.net

Iniciando com Cairngorm – Parte 1

Flex / Cairngorm 2 Comments »

Falei sobre Cairngorm 2,2 no Flex Max Bootcamp no decurso desta semana. Muitas pessoas estavam interessadas em Cairngorm, mas eu tinha apenas cerca de 10 minutos para explicar os conceitos básicos de Cairngorm. Eu acho que a maneira mais fácil de ajudar estas pessoas é fazer uma rápida série sobre os benefícios de Cairngorm no meu blog. Esta série irá combinar artigos com “code-along” vídeos.

Aviso: Não afirmo ser um “expert” na Cairngorm - estou longe disso. No entanto, tenho usado Cairngorm em vários grandes projetos (tanto no Georgia Tech e no meu próprio negócio). Estou certamente aberto a correções, caso você veja que cometi algum erro neste projeto. Se você quiser que “os peritos” check out: Steven Webster, Alistair McLeod, Alex Uhlmann, e Peter Martin.

Nota: Os rapazes no Adobe Consulting (que desenvolveu Cairngorm) estão investigando algumas coisas novas com o quadro como um todo. É possível (na verdade provável), que algumas dessas coisas vão mudar no futuro. Uma das áreas muito específicas da mudança é o Model Locator.

Parte 1 – Usando um Model Locator

O Model Locator pattern é utilizado em Cairngorm, mas você não tem que ter uma plena implementação do Cairngorm para usar o pattern. Primeiro, vamos cobrir aquilo que você recebe de benefícios ao utilizar um modelo Locator.

Um Modelo Locator é um repositório centralizado de todos os dados que é necessário em toda a sua aplicação. Seus dados irão existir dentro de uma “Classe Singleton”. Esta “classe” pode ter apenas um exemplo de si mesmo. Por que isso é importante? Deixe-me dar-lhe um exemplo.

Temos grandes mini-notepads no trabalho que eu uso para anotar dados enquanto eu trabalho. No entanto, por vezes, eu perco um bloco - obtenho um novo e, em seguida, localizo o antigo. Depois de tanto ter sido largamente utilizados - é realmente difícil descobrir qual bloco eu estava usado para anotar um pedaço de informação de uma semana atrás. Esse é um exemplo simples - mas imagina se eu tivesse 20 blocos? Isto poderia deixar vocês loucos.

Da mesma forma, você poderá ter uma “classe” que recebe “instanciado” 20 vezes dentro de sua aplicação (mesmo que você não quer dizer para ela o que fazer). A maneira mais fácil de eliminar este problema é usar um único “Singleton”. Um singleton é uma classe que nunca é “criada” na forma tradicional. Tem uma regra principal - não mais que um por si só pode existir, em qualquer momento. Como ele faz isso? Eu mostrarei no exemplo Model Locator.

Actionscript:

  1. package net.davidtucker.CairngormSample.model {
  2.     import com.adobe.cairngorm.model.IModelLocator;
  3.    
  4.     [Bindable]
  5.     public class ModelLocator implements IModelLocator {
  6.        
  7.         // Single Instance of Our ModelLocator
  8.         private static var instance:ModelLocator;
  9.         public function ModelLocator(enforcer:SingletonEnforcer) {
  10.         if (enforcer == null) {
  11.                 throw new Error( “You Can Only Have One ModelLocator” );
  12.             }
  13.         }
  14.         
  15.         // Returns the Single Instance
  16.         public static function getInstance() : ModelLocator {
  17.                
  18.             if (instance == null) {
  19.                 instance = new ModelLocator( new SingletonEnforcer );
  20.             }
  21.             return instance;
  22.         }
  23.        
  24.         //DEFINE YOUR VARIABLES HERE       
  25.        
  26.     }
  27. }

// Classe Utilitária para negar o acesso ao construtor

  1. class SingletonEnforcer {}

Este código pode parecer um pouco assustador no início, mas confiem em mim que não é tão difícil como pode parecer. Em primeiro lugar, temos o nosso pacote definição e nós importamos algumas classes. Neste momento sabemos que teremos o IModelLocator interface. Para utilizá-lo vai precisar do Cairngorm SWC que pode ser encontrado aqui: http://labs.adobe.com/wiki/index.php/Cairngorm:Cairngorm2.2:Download. Além disso, note - você pode construir um model Locator sem Cairngorm, e faço isso com freqüência em pequenos projectos (você acabou de deixar de fora os códigos “implements IModelLocator” e “import com.adobe.cairngorm.model.IModelLocator “ do Model Locator).

Actionscript:

  1. [Bindable]
  2. public class ModelLocator implements IModelLocator {
  3.        
  4.      // Single Instance of Our ModelLocator
  5.      private static var instance:ModelLocator;

Em seguida, temos a nossa definição da classe. É importante que você use o Bindable metatag diretamente acima de sua classe. Isso permitirá que todas as nossas variáveis que definimos dentro do Modelo Locator serão utilizadas para vinculação. Também irá avançar e criar uma variável. Ela será chamada de “instance” e será do tipo ModelLocator. Esta será a variável onde vamos guardar as instâncias das classes. Também será denotado como uma propriedade “static”. Se você não tem certeza o que é uma propriedade “static”, ok - vamos discutir na nossa próxima lição.

Actionscript:

  1. public function ModelLocator(enforcer:SingletonEnforcer) {
  2.      if (enforcer == null) {
  3.           throw new Error( “You Can Only Have One ModelLocator” );
  4.      }
  5. }

Este é seguido pelo construtor. O construtor assume argumento - “enforcer”. Você irá notar que esta “enforcer” tem um tipo “SingletonEnforcer”, que é definido logo após a nossa classe. Segue-se a lógica de que:

• Quando você coloca uma classe em um arquivo Actionscript abaixo da classe principal, ela só está disponível para essa classe. Muitas pessoas referem-se a estes como “utility classes” (embora muitas pessoas usam esse termo com um alcance muito mais amplo).
• Se o construtor exige este argumento - só então a nossa classe principal pode criar uma instância de si mesmo, porque não temos acesso a classe “SingletonEnforcer” - só a principal classe tem esse acesso.
• Não iremos acessar a nossa classe na forma normal, usando a declaração “new”, porque não se pode chamar o construtor (vou mostrar-lhe como vamos fazê-lo em um bit).

Assim que chegar dentro do construtor, temos algumas linhas certifique-se de que as coisas funcionem como planejadas. A declaração “if” garante que passamos um “enforcer” válido. Se não, haverá um Erro “Você Pode Ter Apenas Um ModelLocator”.

Actionscript:

  1. // Returns the Single Instance
  2. public static function getInstance() : ModelLocator {
  3.      if (instance == null) {
  4.           instance = new ModelLocator( new SingletonEnforcer );
  5.      }
  6.      return instance;
  7. }

A função “getInstance” é a forma como iremos acessar nosso ModelLocator do nosso pedido. Esta função apenas passa para trás o “exemplo” da classe. Se ela ainda não existe, ele irá criá-la. Podemos agora começar um ModelLocator usando o código a seguir

Actionscript:

var model:ModelLocator = ModelLocator.getInstance();

Tradução do original inglês: http://www.davidtucker.net